In this month’s KDE: From the Source George Staikos details what is to be expected from the upcoming 3.4 version of KDE. an Alpha release is due any minute so you might as well know what you’re in for if you’re a loyal K head. Some changes include major rework within KHTML & Konqueror, Subversion support, and Apple’s Rendezvous.
Preview of KDE 3.4
About The Author
Adam Scheinberg
Vice President, Information Technology at Massey Services, Inc • President, Board Member, The Mockingbird Foundation • All Things Web, Umphrey’s McGee • Web Developer • Father • Foodie • Music Snob • OS enthusiast
Follow me on Twitter @sethadam1
finally I will get support for the FN+F5, F6, F7, etc for brightness and volume controls on my ASUS laptop.. but I’m sad that in order to get that I will have to let go of my ubuntu installation… maybe gnome has similar plans for the near future..
You already have it in GNOME since 2.6 at least. Go to preferences and ‘Keyboard shortcuts’. It lets you program all the extra keys as you wish, including the multimedia keys for instance.
most about khtml and kmail. i prefer mozilla anyway, i think they should focus on other things IMHO.
but hey, KDE still rocks for me 🙂
It’s nice to see that they’re enhancing the wifi manager; now if the wireless companies would just release enough info that all the cards could be fully supported…
It’ll also be interesting to see what they mean by “Major Kicker panel reworking” and “Numerous window manager enhancements”.
The Kicker stuff is mostly in the realm of refactoring, done by Aaron Seigo. Code simplification, performance improvements and a ton of bugfixes – making Kicker ready for the future. The biggest new feature is probably systray icon hiding.
Too bad; I usually turn off systray icon hiding when I’m forced to use an XP machine (I have a dual-boot at work for testing, etc.). I keep my systray clean, so there’s no reason to hide anything.
Hey, you’re forgetting rounded icon corners in konqueror, and… and… no flickering anymore !!!
YAY!
*You* define what entries to hide. If you don’t want any hidden, just don’t do it. 🙂
…like in Gnome 2.8?
This one great feature of Gnome, which KDE doesn’t have…
What do they do? I’ve played with Gnome 2.8 and honestly, if HAL and DBUS are supported, they can’t do much that is extraordinary, at least i can’t see that they do.
Ok DBUS seems to be inter process communications…like DCOP. But it’s not even finalized. I also see that KDE plans to work with the fd.o people to get it in KDE, but I fail to see the greatness in it. KDE has DCOP, which works really really well with other KDE apps, it’s fully scriptable, has bindings for C++, Perl, Python, even shell scripts. What does the user do with any of these?
maybe you’re a power user, but saying KDE is lacking because they don’t support a non finalized ipc is rather rash…
DBUS and what depends on it will only be introduced in KDE4.
Here’s an okay outline on what ‘Project Utopia’ is about http://kerneltrap.org/node/view/3450
Last time i read its gonna be supported in the next big KDE release which was either 3.4 or 4.0. Remember, its DE / TK independent but the first implementation is partly for GNOME / GTK. So i assume its still 3.4 or 4.0.
> DBUS … it’s not even finalized
Exactly. I remember with fun the troll posts that “KDE tends to include ‘immature’ technologies” (eg arts, kpart<>corba discussion) – and now GNOME is doing exactly this for a while (dbus, gstreamer, …). 🙂
DBUS is heavily inspired by KDE’s DCOP system, which has been put to good use for many years now. Standardization between the DEs is a worthy goal, but KDE is not going to replace a proven piece of technology on a whim. It will be done when it’s ready.
Depends what you mean by “supported” – you can run HAL + DBUS on any system. If you add ivman too, it’ll automount cd’s etc for you (which is the key feature of them).
The only problem there is KDE isn’t aware of it. There’s a KDE volume manager in CVS (kdenonbeta/kvm) but it’s far from complete yet.
I wish they’d get on with this to be honest – the current implementation isn’t nice at all.
3.4 will be good, but it looks a bit like 3.3 to me; ie. not terribly different to the previous version. Which isn’t all bad; one assumes the big changes are being saved for 4.0, so that’s something to look forward to 😉
yeah, big changes are coming in form of breaking binary compatibility. great! *beurk* kde is getting worse imho. bloated like hell and the last couple of times they threw it out to the public with serious bugs. i think i am done with kde as long as they do not provide a less bug-ridden and less bloated desktop.
It’s ridiculous to think KDE has become bloated. In fact they’ve been working on improving performance and are trimming the fat. Bugs are always there and they’re being chased down, 3.3.1 did a lot of work in that department, not to mention better performance.
On this SuSE box alone I’ve gone from 3.2 -> 3.3 -> 3.3.1 and each time the improvements are apparent.
As for breaking binary compatibility, that’s fine, it was expected far in advance, considering Qt 4.0 is bringing a lot to the table which will mean a significant improvement in applications across the board. Not to mention it’s a good force function for cleaning up code. Do you work on KDE applications or are you a user complaining about a toolkit they’ll never have to use or really worry about?
The new media kio slave has a backend for using hal and dbus so long as the Dbus, qt-dbus bindings, and HAL are installed. If they aren’t it will just read the fstab.
Konqueror as a file manager is still not being fixed I see, due to maintainers who like 50 different sidebars of the same view >:(
Care to elaborate?
maybe you’re a power user, but saying KDE is lacking because they don’t support a non finalized ipc is rather rash…
DCOP is fine, but it is only useful to KDE apps.
What’s needed is something that is toolkit agnostic.
This is why everybody is kicking and screeming for D-BUS
The time when developers can ignore other desktop environments than their own favorite is long gone. If you want to make money you need to be able to support them all.
Hey, you’re forgetting rounded icon corners in konqueror, and… and… no flickering anymore !!!
Speeking of icons, I am amazed the Gnome, KDE, XFCE,… doesn’t cooperate on creating a standard for what icons should look like. Runnable stuff should look one way, documents should have another look e.t.c. In the old MacOS days runnable things like Applications had rombic form, documents looked like documents with one folded corner. Other than that the artist was free to design something nice for each application and their documents.
If there had been a common high level standard for icon look of the free desktop, the work of all the good artists out there could come to much better use.
I think a standard SVG format for display would be nice so that gnome kde and xfce etc… could use the same icons and they would scale nicely to the interface. I hope the new KDE kicker is SVG so it will scale nicely and support super high resolutions. Are SVG fonts possible?
Speeking of icons, I am amazed the Gnome, KDE, XFCE,… doesn’t cooperate on creating a standard for what icons should look like. Runnable stuff should look one way, documents should have another look e.t.c.
—–
http://www.freedesktop.org/Standards/icon-theme-spec
these dont solve the integration issues with kio slaves and gnome vfs and such framework stuff but if you want just a common look and feel, this is the base to work upon
Care to elaborate?
I wasn’t the original poster but, I can tell you some things that is bad in it.
It is just too much. You have 15 shortcut buttons in the default toolbar konfiguration. E.g. how many people use the toolbar for cut & past? Most people would use ctrl-x, ctrl-v.
Is printing really used that often that it should be in the toolbar. I think the KDE team should reduce the number of butons to the five or so most used. I’m not saying that the others should be removed from KDE, they should just not be in the default configuration.
The same thing goes for the vertical toolbar between the tree and the main panel. All the tools consists of icons with no names (exept for the selected one that have its name written sideways). Most people don’t understand what they do , so I suggest they were hidden in default configuration.
Then we have the drag and drop problem. When you drag a file and hold it over the drop target, a rubberband marker is showed arround the drop target to indicate that you can drop the file. This marker is too invisible, they should do something like change the colors or highlight the droptarget.
Another problem releated to drag & drop is the popup menu that occurs when you drop a file over a folder. The menu asks if you want to “Move here”, “Copy here”, “Link here” or “Cancel”. First of all this is an inconsistent behaviour. No other menus have a cancel button, why should this need one.
Second in most cases the action the user wants to perform when dropping a file over a folder is to “Move” the file. This is what happens on your real life desktop and it is what most users would expect to happen. The popup interupts this natural process and ask the user if he wants to do something else.
To make it even worse, a novice user might not even know what “Link here” means, and the advanced user miss the alternative “Hard link here”. So it would probably be better if the “Copy here” and “Link here” ended up in the context menu or they was associated with the right mousebutton drag. That way the user wouldn’t constantly be interupted with a question that ususally is answered in the same way (“Move”).
The menu also have another problem. It makesthe link behavior is hidden. If you put KDE in front of a user that never used KDE and ask him to create a link he will look in application menu, and in context menus but far from all tries to drag the file to the location where the wan’t the link as dragging to most people is associated with moving. The menu makes things like sorting images from your digital camera very teadious.
Another thing make doulble click the default way to activate things applications. Two reasons: 1) It makes it easier for users to distinguish between selection and activation. 2) Many new potential users comes from environments that use double click in this way. Why not make use of their previous knowledge. The downside would be that double click could be harder for old or motorically challanged people or that it could increase the risk of carpal tunnel syndrome. However I haven’t heard that this is a main problem in e.g. the windows world so it would probably not be a problem for KDE users either.
Changeing singleclick to double click as default behavior is also very common when KDE appears packaged in customized form by Linux distributers.
This was just some complaints. Konqueror is an application with a lot of extremely good functionality but very poor usability.
http://www.freedesktop.org/Standards/icon-theme-spec
these dont solve the integration issues with kio slaves and gnome vfs and such framework stuff but if you want just a common look and feel, this is the base to work upon
Not quite what I ment. If I remember correctly that spec specifies the technichal stuff like file names etc. What I want a standard for is the actual look of the icons. E.g. you should be able to see if the icon represents an application, a document, a folder,… by looking at the icon. That high level look should be the same whatever icon theme you use. This migh limit the artistic freedom somewhat but it makes wonders for the consistency of the desktop.
”
Not quite what I ment. If I remember correctly that spec specifies the technichal stuff like file names etc. What I want a standard for is the actual look of the icon”
if they both use the same path, they will get the same icons and will look just the same..
“if they both use the same path, they will get the same icons and will look just the same..”
Yes, but it is not enought to look the same.
There need to be some common understanding of what each high level look mean. E.g. rombic icons could mean runnable programs or another example themes originally built for Gnome usually put the mime typ on a label sticking out slightly from the right side of the document shape, while icon themes originally created for KDE usually have the same information at the bottom of the document icon shape.
What I’m talking about is not guidlines for programmers, as you pointed out we allready have such. What I’m talking about is common guidlines for artists.
”
What I’m talking about is not guidlines for programmers, as you pointed out we allready have such. What I’m talking about is common guidlines for artists.
”
oh ok. that makes it much more clear. so you want a artistic guideline common to freedesktop.org. well I dont think fd.o has gone beyond framework specifications into look and feel that much. you will have to get the framework working right for these guys to think beyond that. If you have the skills or know people interested in this you should ask them to start a discussion in xdg list on fd.o. I am sure its more than welcome
can anyone here recommend a well supported *nix card? if there is one thing I hate most about having switched to wifi, is that I miss the simplicity of plain ol’ NICs. the days when all I had to do was install the OS and it’d configure my NIC. blah. anyone have a recommendation for wifi cards? (currently using Linksys WMP54GS, i wouldnt mind giving up the extra ‘speed’ for more compatability’)
Actually, by saying rounded icon colors I meant the “selection with antialiased corners like in Gnome or OsX”. They look much better now, but apps’ status bar still needs some polish IMHO.
There are wonderful projects fixing these issues on KDE-look.org.
Actually, by saying rounded icon colors I meant the “selection with antialiased corners like in Gnome or OsX”. They look much better now, but apps’ status bar still needs some polish IMHO.
Are you sure that this has gone into cvs? Last time I checked only some parts of the “Improving KDE” patchset were accepted into cvs, and roundend icon selection wasn’t. Many of them were still buggy.
it always bothers me to see the X Icon in the corner of a window. it’s seems like something obvious that got missed. throw some sort of icon in there. i’m sure tis improves usability as it allows collapsed windows to be identified more readily. it also has the obvious astetic value.
not that i mind the X logo per se… it’s not you shouldn’t leavea generic default: http://osdir.com/images/passwords.png
>>Care to elaborate?
> I wasn’t the original poster but, I can tell you some >things that is bad in it.
> It is just too much. You have 15 shortcut buttons in the >default toolbar konfiguration. E.g. how many people use >the toolbar for cut & past? Most people would use ctrl-x, >ctrl-v.
I agree with you here. there are some efforts so set some standards for this, tough. I just hope they get this in time for kde 3.4
> The same thing goes for the vertical toolbar between the >tree and the main panel. All the tools consists of icons >with no names (exept for the selected one that have its >name written sideways). Most people don’t understand what >they do , so I suggest they were hidden in default >configuration.
work is being done on this, too – but there is some debate about it. the nice thing with these icons is that clicking the ‘open’ icon makes the bar (almost) disappear while still available. so its very space-efficient. the alternative is like the one used in the latest k3b. uses more space, but looks better and is easier to get used to. quite a typical dilemma
>then we have the drag and drop problem. When you drag a >file and hold it over the drop target, a rubberband >marker is showed arround the drop target to indicate that >you can drop the file. This marker is too invisible, they >should do something like change the colors or highlight >the droptarget.
agreed
> Another problem releated to drag & drop is the popup >menu that occurs when you drop a file over a folder. The >menu asks if you want to “Move here”, “Copy here”, “Link >here” or “Cancel”. First of all this is an inconsistent >behaviour. No other menus have a cancel button, why >should this need one.
I whoulnt want to remove the cancel, because this way you can simply stop the copying/moving/etc.
> Second in most cases the action the user wants to >perform when dropping a file over a folder is to “Move” >the file. This is what happens on your real life desktop >and it is what most users would expect to happen. The >popup interupts this natural process and ask the user if >he wants to do something else.
all newbies I showed this were really happy with this, no-one knew they could do that with the shift/ctrl/alt keys. this menu is one of the best things in KDE, imho. its really usefull. and you can still use shift/ctrl/alt so its good for ‘experts’ too…
> To make it even worse, a novice user might not even know >what “Link here” means, and the advanced user miss the >alternative “Hard link here”. So it would probably be >better if the “Copy here” and “Link here” ended up in the >context menu or they was associated with the right >mousebutton drag. That way the user wouldn’t constantly >be interupted with a question that ususally is answered >in the same way (“Move”).
maybe they dont know, but they can try. and most do know what a shortcut is, so I dont think its sso strange. removing this menu whould remove something that makes KDE much more usable for newbies.
>the menu also have another problem. It makes the link >behavior is hidden. If you put KDE in front of a user >that never used KDE and ask him to create a link he will >look in application menu, and in context menus but far >from all tries to drag the file to the location where the >wan’t the link as dragging to most people is associated >with moving. The menu makes things like sorting images >from your digital camera very teadious.
Maybe the menu should make the shift/ctrl/alt things more clear, but apart from that… its nice, imho.
> This was just some complaints. Konqueror is an >application with a lot of extremely good functionality >but very poor usability.
well, agreed on this
The netgear MA311 is one of the best-supported wifi cards for GNUlinux; I’ve got one at home and it works beautifully.
For desktops, you can have that simplicity back
. Buy a wireless bridge! You can get them as cheap as wireless PCI cards. Good, cheap ones are often sold in electronics stores as ‘wireless gaming adapters’ intended for consoles, but they’re really just plain wired-ethernet-to-wireless bridges. Buy one, plug it into a spare Windows PC to set it up (one-time step), then dangle it off your desktop’s ethernet port and you’re done. As far as the OS is concerned, it’s just a good ol’ wired ethernet connection. Nice, no?
I whoulnt want to remove the cancel, because this way you can simply stop the copying/moving/etc.
According to that logic, we would need cancel buttons on all other menus as well. I think that would look very strange though.
Another problem with the “Cancel” menu item is that it is colored brightly red. This will give it too much attention. My guess is that the first thing the user reads when the menu pops is “Cancel”. This is not good since “Cancel” hopefully would be one of the least used choises in the menu.
> Second in most cases the action the user wants to >perform when dropping a file over a folder is to “Move” >the file. This is what happens on your real life desktop >and it is what most users would expect to happen. The >popup interupts this natural process and ask the user if >he wants to do something else.
all newbies I showed this were really happy with this, no-one knew they could do that with the shift/ctrl/alt keys. this menu is one of the best things in KDE, imho. its really usefull. and you can still use shift/ctrl/alt so its good for ‘experts’ too…
I don’t doubt for a minute that newbies you showed it to liked it. The problem is that having it shown to you and to work with it is two very different things. This could fool even moderately experienced HCI experts. Send your users out in the field with a digital camera, then when they get back ask them to sort the images into a couple of folders or send them e-mails with attachments to place in some folder somewhere. Then you will find that the number of newbies wholikes this menu will decrease rapidly. This breaks the normal flow in their work and doing that is normally not a good idea.
The popup would have been very good if all the alternatives was equally probable, but they are not. I looked at my disk, and found that of all existing files there only 0.4% was links. Most of them was probably created by scripts or by the sysadmin. In fact I would even think that the “Cancel” item is more frequently used than “Link here”.
And I am also not surprised that they didn’t find shif/ctrl/alt keys. This is to be expected. So if the popup is removed “Copy here” and “Link here” can’t rely on these keys. These functions have to go elsewhere. In fact the “Copy here” menuitem could be done from the file menu using normal “copy” and “paste”. This would also be consistent with how to duplicate things in other applications.
But we still have to consider what to do with “Link here”. Given that link is extremely seldom used, users should not be asked if they want to link every time they do something they do quite often (like move a file). Secondly ewbies should not be asked about things they likely don’t know what it is (like links)
One alternative would be to add a “Paste as link” to the File menu. The user could then use “Copy” followed by “Paste as link” to create links.
> To make it even worse, a novice user might not even know >what “Link here” means, and the advanced user miss the >alternative “Hard link here”. So it would probably be >better if the “Copy here” and “Link here” ended up in the >context menu or they was associated with the right >mousebutton drag. That way the user wouldn’t constantly
>be interupted with a question that ususally is answered
>in the same way (“Move”).
maybe they dont know, but they can try. and most do know what a shortcut is, so I dont think its sso strange. removing this menu whould remove something that makes KDE much more usable for newbies.
Well, I’m sure a newbie knows what a shortcut is, but then you have to call it “Shortcut here” and not “Link here”.
This would however confuse the not so newbie Unix user. In fact even “Link here” is confusing to the latter category that will ask themselves is it a soft or a hard link.
A different way to solve this would be to assign “Move” to left button drag, “Copy” to right button drag and “Link” to the middle button. This would probably mean that the context menu had to be activated on mouse up instead of mouse down. But this works well in windows so there is reason to believe it would work in KDE as well.
Maybe the menu should make the shift/ctrl/alt things more clear, but apart from that… its nice, imho.
The shift/ctrl/alt should not be involved in copy or link. It is too confusing as they also are used to expand selections, somethings you often do just before you move.
Try to use these shortcuts and expand or shrink selection before you do the shift/ctrl drag operation. I almost gurantee you get it wrong.
Finally, you say that this popup menu is good for newbies. Lets for a moment assume that this is true. Then lets ask ourselves how much else in KDE in newbie friendly. Not that much in my oppinion. Besides, how long does a newbie stay newbie. The whole interface seam to target intermediate to advanced users, so why should we have a newbie friendly popupmenu that most likely annoys the targeted audience more than it helps. If we decide that this menu is good, then we must also make the rest just as newbie friendly. This would probably mean removing a lot of the configurability that advanced and intermediate users like, and we would end up with something similar to GNOME.
>>E.g. how many people use the toolbar for cut & paste?
Many people from windows converts.
>>Most people would use ctrl-x, ctrl-v.
Not true.
I had considered that after seeing this product by Linksys http://www.linksys.com/products/product.asp?grid=33&scid=35&prid=61… but its currently over $120 from what I’ve seen online. Do you know of any cheaper models and where to get them? Thanks!
Many people from windows converts.
>>Most people would use ctrl-x, ctrl-v.
Not true.
Well, I have lots of videotaped userinteraction to prove you wrong. One of the reasons to this might be that the icons are not understood by the users. Perhaps they understand the cut icon, but the copy and paste icon is totaly incomprehencible at least here in Europe. New users usually use the edit menu the first times and, as they get more experienced, they then change behavor to use ctrl-x, ctrl-v. To use the toolbar is very rare.
The problems with icons is that it is very hard to get icons that have a clear meaning in all cultures. E.g. one would think that a house would be a very good and universal symbol for your home directory, but what if your home folder is called “Persönlishe Ordner” in your language? Menu items is much easier to internationalize.
>>New users usually use the edit menu the first times and, as they get more experienced, they then change behavor to use ctrl-x, ctrl-v.
Not true. Most of them use right click mouse to cut and paste or use the toolbar as the icon stands out and when highlighted says what it’ll do.
That’s why I suggested the gaming-branded ones – they do the same thing but are sold cheaper
. Amazon.com, for instance, have a Linksys 802.11g version for $89 (search on linksys wireless gaming), and they’re certainly not the cheapest seller of this kind of thing, I expect you can find it cheaper somewhere.