Submitted by The K Desktop Environment was pleased to see its users recently at the LinuxWorld Conference and Expo. Users were excited to learn about KDE 4.0, some of the hot new stuff in KDE 3.5, and thousands of Linux users got out of the house for a change.
The K Desktop Environment was pleased to see its users recently at the LinuxWorld Conference and Expo. Users were excited to learn about KDE 4.0, some of the hot new stuff in KDE 3.5, and thousands of Linux users got out of the house for a change.
Such news is fine for a KDE community news site, but I fail to see the relevance for such a site as OSnews.
…you’re joking, right?
We might as well skip the GUI in Windows and only discuss DOS too
and i just got 3.4.2 installed
heh, you can’t keep up with the Jones’s.
I really like the new homes:/ locatation in KDE 3.5. If it works like I think it does, the full names of the users is presented to the user, not some folder name like in gnome.
This is a good example of seeing things from a user perspective rather than from a technical file browsing perspective. It is much more natural to think of collegues by their real names than by their home folder name, that may or may not be the same as their login name. In this specific case KDE 3.5 blows Gnome 2.12 out of the water with respect to usability.
Using locations like homes:/, trash:/,… is a step away from the traditional Unix hierachial filesystem view that works so well in CLI environments but sort of looses its strengts in modern GUI systems. Back in the days when the unix directory structure with disks mounted in one tree it was a great simplification to the user as he did not need to keep track of actual physical storage devices.
In the desktop methaphore documents can be thaught of as stored in a file cabinet. However some all things doesn’t really fit into that file cabinet without stretching the metaphore. I.e. we wouldn’t normally store trash in a physical file cabinet. Neither would we store our collegues there. By creating locations like homes:/ we get starting points for new specialized hierachis that maps well onto the most users perception of the world.
Very well done, this is miles ahead of Gnome 2.12 as it acknoleges that most users need to cooperate and share files with fellow workers. In the homes:/ location the folders will act as some sort of conceptual proxy for the real user. However that makes the icons a bit out of place. The icon should probably relate more to people than to various types of houses.
“However that makes the icons a bit out of place. The icon should probably relate more to people than to various types of houses.”
Yeah, this is a very good point, I think you should directly contact Kévin Ottens (the home:/ author) or fill a bug in bugs.kde.org to share this idea, that IMO should be implemented.
“However that makes the icons a bit out of place. The icon should probably relate more to people than to various types of houses.”
Yeah, this is a very good point, I think you should directly contact Kévin Ottens (the home:/ author) or fill a bug in bugs.kde.org to share this idea, that IMO should be implemented.
Done! You can now cast your bug vote on it at:
http://bugs.kde.org/show_bug.cgi?id=111350
There’s a proliferation of IOSlaves going on at the moment, like media:, homes:, system:, settings:, … .
I get the feeling that that might come back to bite them, because it isn’t terribly scalable and it conflicts with the actual concept of URLs: the bit before the colon should denote a protocol, not just some kind of filesystem shortcut.
Here’s one example. Say Joe User looks at his home directory in Konqueror:
homes:/Joe_User
Yet if he clicks on a zip file in there the address turns into something like this:
zip:/home/joe/file.zip
Is that confusing or what?
Well, considering that in Nautilus he wouldn’t even *have* a visible address, I don’t see why this is any worse.
And no, it doesn’t change that way.
I don’t care much about Gnome, I was talking about KDE.
It just seems there are too many different things being squeezed into the IOSlave concept, e.g.:
– protocols: file, http, ftp, fish
– things that should be filters: zip, tar, gzip
– disk access: media, drives, audiocd
– pseudo filesystems: system, settings, applications, homes
It just seems there are too many different things being squeezed into the IOSlave concept
Actually it’s quite consistent with the unix philosophy if you ask me. “Everything is a file” vs. “Everything is a ioslave”.
Now, the trick is to keep track of what ioslaves there is, and integrating them in your workflow in an optimal way. I’m still looking into that one, I guess it’s because I don’t do things the way they are supposed to be done, as usual.
Here’s one example. Say Joe User looks at his home directory in Konqueror:
homes:/Joe_User
Yet if he clicks on a zip file in there the address turns into something like this:
zip:/home/joe/file.zip
Is that confusing or what?
It is, but the current KDE 3.4 situation is worse. People usually refer to each other by name and have done so for thousands of years. They should be able to do so in their OS environment as well.
Besides I think that most people will see the zip archive as an artefact of its own, just like they realize that trash:/ or for that matter homes:/ is a hierachies of their own. If he doesn’t, he is in trouble just the same as the zip:/ “directory” will behave differently than his ordinay directories and that will confuse him too. The solution to that would be not to open zip files directly in konqueror, but I
think most people would think that would be a bad idea.
BTW: When the user decide to unpack it he would still be able to specify the desired location in termes of homes:/Some Person.
LOL :
http://ktown.kde.org/~charles/lwce2005/p8090010.jpg
Looks good,finally kicker got some new jacket too.
“So, with that all said what has been accomplished so far? Kdelibs builds and kdebase can be made to build if you tell make to ignore errors.”
It compiles, ship it!
I agree that putting more functionality isnt a bad thing, but I too struggle to keep up with what IOSlaves exist and in what ways they are best used.
KDE should get better support for HAL as it dont mount drives, gnome has gnome volume manager which is much better for controlling media. Konqueror has major fuctionally over Nautilus but Nautilus is simple like OSX.
Also KDE needs to get Kompmgr stable with most themes because it logs you out after a couple of konqueror openings. Baghira is stable with kompmgr but other themes are not, including the default plastik. Gnome on the other hand is perfectly stable.
Get KDE 3.4 built with HAL support, and go to media:/
Get KDE 3.4 built with HAL support, and go to media:/
Or whitout, it will function nearly identical. As KDE is very portable and has a bunch of nice helper scripts, giving nearly the same functionality whitout the Linuxism of HAL.
I have KDE 3.4.2-with HAL but it’s doesn’t auto mount drives like gnome volume manager does. It has issues with unmounting.