Linked by Thom Holwerda on Mon 14th Apr 2008 21:09 UTC, submitted by irbis
KDE "After three weeks of using KDE 4 on my laptop, I continue to find new features and changes. I am aware of the dictionary of special names that make up the back end of the new KDE - Oxygen, Plasma, Phonon, and the rest - but just as often as the major features, it's the little items that I find welcome as much as the large ones. Increasingly, I'm looking at KDE 4 as a statement about what a desktop should be, and contrasting it with my own ideas on the subject."
Order by: Score:
Trunk in 4.1
by leos on Mon 14th Apr 2008 22:00 UTC
leos
Member since:
2005-09-21

The debian KDE packagers have decided not to bother with the 4.0.x releases anymore and have gone straight to packaging svn snapshots from trunk (what will become 4.1 in a couple months). Lots of new features, and overall I'd say as or more stable than 4.0 (which for me, has been quite stable). The switchover to Qt 4.4RC has also improved painting performance immensely, so it's worth it just for that.

Edited 2008-04-14 22:00 UTC

Reply Score: 7

RE: Trunk in 4.1
by _txf_ on Tue 15th Apr 2008 00:46 UTC in reply to "Trunk in 4.1"
_txf_ Member since:
2008-03-17

The switchover to Qt 4.4RC has also improved painting performance immensely, so it's worth it just for that.


I agree, but scrolling in the terminal is still hideously lumpy for me and selecting items in dolphin is slower under trunk than it is under 4.0.x (I'm guessing its those gradient shaded highlights...maybe I should file it as a bug).

Reply Score: 3

RE[2]: Trunk in 4.1
by leos on Tue 15th Apr 2008 02:29 UTC in reply to "RE: Trunk in 4.1"
leos Member since:
2005-09-21

I agree, but scrolling in the terminal is still hideously lumpy for me and selecting items in dolphin is slower under trunk than it is under 4.0.x (I'm guessing its those gradient shaded highlights...maybe I should file it as a bug).


Really? What card/driver do you have? I have a truly terrible Ati Xpress 200m in my laptop, an EeePC with an intel 810, and a NVidia at work, and I've never had any issues with scrolling in Konsole or selecting in Dolphin. KDE 4.0.x was really sluggish scrolling in dolphin, but trunk fixed that for the most part.

Reply Score: 3

RE[3]: Trunk in 4.1
by _txf_ on Tue 15th Apr 2008 02:46 UTC in reply to "RE[2]: Trunk in 4.1"
_txf_ Member since:
2008-03-17

I'm using a nvidia 8600m gt (8/9 series have had several complaints of problematic behaviour, in gtk as well as qt). I wonder how much an effect the debug symbols have on performance. Qt takes forever to compile and I can't be bothered atm.

I guess I'll give it another go once plasma is in a more fixed state as it's fairly borked atm.

Reply Score: 2

RE[4]: Trunk in 4.1
by leos on Tue 15th Apr 2008 04:02 UTC in reply to "RE[3]: Trunk in 4.1"
leos Member since:
2005-09-21

I'm using a nvidia 8600m gt (8/9 series have had several complaints of problematic behaviour, in gtk as well as qt). I wonder how much an effect the debug symbols have on performance.


Oh yeah, those cards have no end of driver issues. Just saw the post on the planet about it. Although I heard that the next driver release (17x) should fix that.
In my experience the debug symbols make much of a difference. Your painting performance is gonna overwhelm any small difference they make.

Reply Score: 5

RE[4]: Trunk in 4.1
by gilboa on Fri 18th Apr 2008 18:24 UTC in reply to "RE[3]: Trunk in 4.1"
gilboa Member since:
2005-07-06

I'm using a nvidia 8600m gt (8/9 series have had several complaints of problematic behaviour, in gtk as well as qt). I wonder how much an effect the debug symbols have on performance. Qt takes forever to compile and I can't be bothered atm.

I guess I'll give it another go once plasma is in a more fixed state as it's fairly borked atm.


Driver issue.
nVidia 16x.x has a nasty 2D bug/slowdown that mostly affects 8 and 9 series cards.
Even the mach64 chipset on my 12 y/o laptop (PII366, CentOS5, custom DRI) has a faster 2D...

- Gilboa

Reply Score: 2

RE[2]: Trunk in 4.1
by ppenz on Tue 15th Apr 2008 08:14 UTC in reply to "RE: Trunk in 4.1"
ppenz Member since:
2007-02-20

and selecting items in dolphin is slower under trunk than it is under 4.0.x (I'm guessing its those gradient shaded highlights...maybe I should file it as a bug).


This is because of Nepomuk, we'll improve this until KDE 4.1 is released.

Reply Score: 5

Default Applications
by superstoned on Tue 15th Apr 2008 05:35 UTC
superstoned
Member since:
2005-07-07

Funny how he proves how the old Control Center didn't help him to find some settings - Default Applications Settings has been there for years, but he apparently never discovered it and claims it's new ;-)

Reply Score: 6

RE: Default Applications
by kolmyo on Tue 15th Apr 2008 06:39 UTC in reply to "Default Applications"
kolmyo Member since:
2005-07-11

"Active corners" and classic menu item settings have also been there as long as I can remember.

Reply Score: 4

RE: Default Applications
by sbergman27 on Wed 16th Apr 2008 14:47 UTC in reply to "Default Applications"
sbergman27 Member since:
2005-07-24

Default Applications Settings has been there for years, but he apparently never discovered it and claims it's new ;-)

The fact that it was there for five years still went unnoticed says a lot about KDE's traditional interface "design". Isn't this exactly the problem that critics have been pointing to for years? Thanks for pointing it out so clearly.

Reply Score: 3

RE[2]: Default Applications
by _txf_ on Wed 16th Apr 2008 22:51 UTC in reply to "RE: Default Applications"
_txf_ Member since:
2008-03-17

I fail to see how much more clear one can be about this short of gaudy flashing icons and annoying popup tutorials. In Gnome it is not immediately obvious how to change mime types.

It's not like kde has a monopoly of obscure configuration interfaces (hello gconf). KDE 3 series made it difficult to find options because there were lots and were badly organised at the same time gnome was shoving all these options into gconf. Each is valid enough, just a matter of preference.

Reply Score: 1

RE[3]: Default Applications
by sbergman27 on Thu 17th Apr 2008 12:38 UTC in reply to "RE[2]: Default Applications"
sbergman27 Member since:
2005-07-24

I fail to see how much more clear one can be about this short of gaudy flashing icons and annoying popup tutorials.

Suffice it to say that I'm not surprised.

Reply Score: 2

WTH?
by JMcCarthy on Tue 15th Apr 2008 06:47 UTC
JMcCarthy
Member since:
2005-08-12

Is his point of comparison KDE 3.0? Most of the stuff he mentions as new has been there for years.

Edited 2008-04-15 06:47 UTC

Reply Score: 7

Not enough
by unoengborg on Tue 15th Apr 2008 22:00 UTC
unoengborg
Member since:
2005-07-06

Is KDE 4 beautiful? Oh yes very much so. Is it good technology? Oh yes, its excellent. Is it a good user inteface to Unix? Yes, very good.

Still I am disappointed at KDE, and most other modern desktop environments. The problem is that they make their very best job being an interface to computer technology that is irrelevant to most of their potential users. This makes them only a little better than a typewriter and a shelf of binders of 1920.

Computers are not for experts anymore. They are for ordinary people. People that are accountants, HR persones and so on, people who are not developers, who are not sysadmins. This is why we need to make the desktop environments speak their language. For instance why do these users need to know anything about the unix file hiearachy such as /etc, /proc, /dev, /bin, /sys, /lib, /bood,...

We use a desktop metaphore, with folders and documents, and I suppose that is OK. It is real world objects that most people should be able to relate to.
What amazes me, is that most modern desktop environmnets can't even seem to decide if the user is inside or outside the file cabinet. All in an attempt to be true to the technical reality of the file system, instead of the reality of the user.

If we spend a day at any office we hear people talk about people, about people we share information with, about people we keep information secret from, about people who share information with us.

When we refer to information we are much more likely to refer to it by contents, or by who created it, or for whom it was created than where it sits in a Unix filesystem. So why do most desktop systems KDE includeds make us do that.

The systems don't catch the intents of our actions. E.g. if I try to make a phonecall to a collegue and he doesn't answer, why doesn't the system suggest sending an e-mail once we hang up on our phone application.
Yes, computers are part of our communication equipment, so they must be able to interact with non computer commuication, such as ordinary phone calls.

The hierachies of interests to ordinary users,are more likely who we report to and who report to us, than the filesystem hierachy. These relations may change from project to project. So why are there no easy way to display such hierachies.

Reply Score: 1

RE: Not enough
by _txf_ on Tue 15th Apr 2008 23:11 UTC in reply to "Not enough"
_txf_ Member since:
2008-03-17

Name me a DE or OS that does this. The kde devs are taking great pains to make kde as user friendly as possible.

"When we refer to information we are much more likely to refer to it by contents, or by who created it, or for whom it was created than where it sits in a Unix filesystem. So why do most desktop systems KDE includeds make us do that."


Nepomuk should help achieve some if not all of that.


"The systems don't catch the intents of our actions. E.g. if I try to make a phonecall to a collegue and he doesn't answer, why doesn't the system suggest sending an e-mail once we hang up on our phone application.
Yes, computers are part of our communication equipment, so they must be able to interact with non computer commuication, such as ordinary phone calls."

Won't Decibel make these kind operations easier? I fail to see how a computer can interact with POTS short of making the phone computer controlled. Either way POTS is gonna die eventually.


You're free to design the interface of the future, it might even be revolutionary. However, count on many users not trying it out because they "don't understand", "it's not like windows/osx", "not like kde3/gnome" etc...

The problem with interfaces is that there will never be a revolution, only evolution because you always have to phase out the cruft or expectations of the users. Not to mention there still are limitations with regards to hardware (still bound by keyboard and mouse...most of us).

Reply Score: 2

RE: Not enough
by Morty on Wed 16th Apr 2008 12:03 UTC in reply to "Not enough"
Morty Member since:
2005-07-06

For instance why do these users need to know anything about the unix file hiearachy such as /etc, /proc, /dev, /bin, /sys, /lib, /bood,...


But they don't, neither KDE or any other Unix Desktop enviroment require the user to know anything about those directories.

All applications defaults to the users home directory or some subddirectory of it, like documnets. To get exposed to the unix file hierarcy you have to do one or more deliberate actions to get there, wich these users wont do. The only way they get there are by accident, and in those rare occasions my experience is that, they cancel the opperation and start over from default.

Basicly the constant harping about the problems of the unix file system hirarcy are just plain nonsens, and not a real world usablility problem. The user that would potentially have a problem with it, does not know it exist and are never exposed to it.

Reply Score: 3

RE[2]: Not enough
by unoengborg on Wed 16th Apr 2008 14:01 UTC in reply to "RE: Not enough"
unoengborg Member since:
2005-07-06

But they don't, neither KDE or any other Unix Desktop enviroment require the user to know anything about those directories.


So, if the user is not requred to know about them, why are they shown? The only reason I can think of so far is to make it possible for some of us to say "Hey, this is UNIX, I know this" like the little girl in Jurassic parc. To me that isn't a good enough reason.

These extra directories actually carry a cost each time an "accident" happens. At worst the cost will be a call to the support department, at best it will be increased time to for the user to find his way back to known territory.

Not even sysadmins need most of them. E.g. most of the files in /lib, /bin, /usr/bin, /usr/lib are created by some kind of package managers, make files. The bin files are accessed through the path. Second if you are a sysdmin and you actually need to see them there should be a way of unhide them for you, and you as a sysadmin should know how. Most sysadmin I know, myself included, would just fire up vi and edit them as usual, it so much faster than finding them in dolphin and then do it in Kate.

Besides, if you are a sysadmin, you know the name of the files you want to edit, and you will have no problem writing their name in an open dialog of an editor, and if that happens often are you sure this is not a sign that we need a better GUI for editing the thing you evidently can't change from the GUI, or that you should make a script.


All applications defaults to the users home directory or some subddirectory of it, like documnets. To get exposed to the unix file hierarcy you have to do one or more deliberate actions to get there, wich these users wont do. The only way they get there are by accident, and in those rare occasions my experience is that, they cancel the opperation and start over from default.


We don't build roads with dangerous traps for people that by accident happens to run off the road. Instead we make the environment as clean as possible to limit the consequences of an accident. The same should be true for desktop designers.


Basicly the constant harping about the problems of the unix file system hirarcy are just plain nonsens, and not a real world usablility problem. The user that would potentially have a problem with it, does not know it exist and are never exposed to it.


That may be true on your home desktop, but out in the business world there are a lot of companies where people cooperate to get a result. They need to share resorces and they also need some place to put these shared resorces.

Yes, you could make links from such shared resorces to within the home directory of each user, but how should that be done. In most cases you would have too many users to handle it manually, then what if the user allready have a file folder or link with the same name. This solution is not practial and doesn't scale well.

Another disadvantage is that it goes against common human concepts such as what is Mine, Yous, and Ours.
My home directory should typically contain my stuff.

I would say that most users would probably be much better served by a folder hierachy that corresponded to the business structure of their buisness, rather than the the structure of the physical storage of their computer.

Linux and other unixlike systems are already moving in this direction by hiding the actual physical disks in systems like LVM, why not hide, and name things in a way that it makes business sense, whenever it is technically possible.

BTW, Apple have managed to hide most of these folders to ordinary users, and I have never seen any review in the presss saing that MacOS-X is hard to use or manage because these directories are hidden to ordinary users.
So if Apple doesn't need them in MacOS-X, why do we need them in KDE and other desktop environments?

Reply Score: 2