America has never said it wants to attack, change the government and own another nation; we don't want more territory- we just want wars there to stop.
Ah yes, the noble Americans ride in to stop the brutal war in Iraq. Oh wait..
While I agree with many of your points, the notion that the US just goes to war because of some altruistic need to stop wars in other places is laughable. There was no war in Afghanistan, there was no war in Iraq. Then the US showed up, and now there is war in both.
It's a mixed bag. Obviously it will work for some people, otherwise it would have never been released in the first place, but that doesn't make the people for whom it doesn't work liars. For them, Vista is pure garbage. The fact that it works for you has absolutely no bearing on that fact. Conversely, the fact that Vista is useless for them doesn't mean it can't work perfectly for you.
For me, Vista is completely useless, and I've had it on my laptop for the past 6 months, trying it every few weeks or so to download updates and see if it managed to not completely suck, but it still does.
Removed because GNOME swapped over to the FDO menu spec, breaking the old one, which replaced when manpower allowed. Not removed for reasons of simplicity or usability.
That reeks of poor project management. If switching to the FDO menu spec will remove a major feature, then why didn't they wait until it could be done properly?
Replaced with something that gasp, still manages windows, does so in a sane way by default and actually integrates with the desktop. In the end, no net loss of function as you can swap Metacity for Sawfish again (yes, it's configurable!).
Of course it still manages windows, but there are far less features, which was my point (whether you use those features or not is completely irrelevant). Your argument that you can swap Sawfish back is inane. Sure, I could also maintain my own branch of metacity, and code the features myself. That doesn't make it a realistic alternative. For 99% of users, all that functionality is gone.
Actually, it the saver itself is just as configurable as plain xscreensaver. No, savers are not configurable but if you read the bug report the developer is planning to implement this. It was replaced again for better integration with the desktop as JWZ wasn't willing to do/allow it. Most (all?) of the main configuration options that were lost were actually moved elsewhere (e.g. to the power manager).
"planning to implement this" being the key words here. That doesn't mean it will get done, and if it does, it will finally gain a feature that every desktop for 10 years has had.
And the reply clarifying GNOME's actual position - which is that features will be implemented if they are genuinely useful and a reasonable way of doing it can be found.
This is exactly the problem. If I want to print in draft mode, I don't give a flying fuck that there are plans to implement that feature, or no one has found the absolutely ideal way to present it in the GUI. I need that feature, and I need it NOW. Like Linus said, until you have a feature, you can't even talk about usability, you can only talk about UNusability. So even though the KDE print dialog might look messier than the Gnome one, the KDE dialog possesses at least some measure of usability, while the Gnome dialog is COMPLETELY UNUSABLE for any task that requires the missing feature.
Yes, of course, "everyone" knows it is true. I'd like, just once, even one example of this.
Yes and I would like, just once, an example of the common myth that water is wet.
Yet, I am loathe to let you wallow in your ignorance, so I've done a quick search for you. I follow gnome development only from a distance, so I'm sure I've missed a lot here.
If by "more features" you mean "checkboxes and radiobuttons", true.
That is configurability, not features. There is more configurability in KDE, and that allows features, but there are also more real features.
But I consider usability a feature.
Of course that can be considered a feature from a marketing point of view, but not from a code point of view. Usability does not cost resources (usually).
I tried to use k3b once, and I couldn't figure it out.
Wow. Sorry I don't want to come across as a jackass, but K3B is really simple to use. Open it, click the giant New Data CD button, then drag the files you want from the top to the bottom. Click the burn button. Comparing that to cdrecord is ludicrous. There might be simpler burning GUI's available, but none of them give you the power that K3B does (when you want to do more than just burn a couple files.
The question is not why Gnome takes more memory than KDE. The question is why KDE take more memory than the shell if it doesn't make things easier to use.
If (and I'm assuming it is not the case and if you wanted to you could use only QT) you must use the entire KDE framework to build an app, well that locks you in to using all of KDE's libraries doesn't it?
Yes you could use Qt only. And "only" is semantics here, Qt4 provides you with everything you need for most apps (far, far more than GTK). Since Qt4 came out, the kdelibs really don't have much in them anymore that an application developer would care about if they're not targetting KDE specifically. There is some stuff, but a lot of it is mostly useful because of the integration it brings with other apps. That doesn't mean you're locked in to anything though. With KDE 4, you'll even be able to link to the kdelibs and compile on Windows or OS X. You get all the features, and none of the porting.
Yelling at the GNOME guys because you need to include 5 libraries and 5 header files instead of one just tells me you're a lazy programmer.
Good programmers are lazy. That drives them to develop frameworks that allow you to do powerful things easily. If your framework isn't convenient to use (like, having to pull in 5 different libraries that have different api's and complicate the build and packaging process just to build a basic interface) makes developers invent their own thing, or do silly things like copying library code into their apps instead of linking to it. ( http://www.chipx86.com/blog/?p=205 )
And you're right, usability studies are generally qualitative in nature, but using mixed methods allows you generalise the qualitative data while still being able to look at individual differences.
No, I'm saying normal users are just fine with the desktop environments as they are today. There is room for improvement, but desktop usability is NOT a factor in why people don't use linux. See the last link for a study supporting this point.
And... bam! And there's the myth again, twice in one post. That has to be some sort of record. So go on, provide some references to back up these assertions.
*sigh* You can't argue that a lot of configurability has been removed from Gnome since the 1.4 days. These changes were done in the name of usability. Some of them justified, of course. I'm not going to dig through the mailing lists and bugzilla to find you references. You're a smart guy, you know this happened, and can find your own references. Good job nitpicking though and not actually answering the important parts of my post.
You mean, "they were added because a significant number of users who were motivated and willing to submit feature requests using the appropriate mechanism, who were technically competent enough to do so and knew that such a mechanism existed requested a particular feature". Which, of course is a flaming great classic example of response bias - the same thing that makes television and newspaper polls useless as an indicator for the actual value of a population parameter.
Yes, there is bias there, but not as bad as you would make it seem. Technical users make requests on behalf of less technical ones as well. And face it, the majority of Linux users are technical users. You can ignore this and not cater to them if you want, but you're targeting users that may never even use Linux. Usability tests have shown that user have just as easy a time doing tasks with KDE than Windows XP. The current desktop is not an impediment to user adoption. Less technical users don't use Linux because of hardware support, pre-installs of Windows, and lack of awareness. Sit down a normal user with Linux (KDE or Gnome) and they won't have more trouble with it than with Windows.
What you have is an bunch geeks and hobbyists - the very people to want extreme, nifty and mostly useless features - in control of functional requirements for KDE.
Face it, that is the majority of your user base. You can't neglect your primary user because of some mythical novice user. They are also extremely valuable, because technical users _contribute_ while novice users just use the software.
Also, what about removing useless features? Does that ever get voted on?
Yes, and features get removed from KDE regularly if they create real problems or can be replaced with a better system. Removing features just because someone is confused by them is not a valid reason. You have to think about it more critically than that.
despite the fact that major usability studies were run on GNOME in 2001 and 2005 and continue in part at betterdesktop.org
Please, Gnome are not the only ones thinking about usability. They are just suffering from the delusion that less features and less configurability makes for usability, when in fact the problem is much more complex than that. Making simple software usable is comparatively easy to do. The real challenge is making complex and flexible software usable without removing any of the power. KDE hasn't solved that problem, obviously, but they are working towards it without throwing out what makes KDE worth using over something like Windows.
People are the mostly same. Usability studies prove that.
Sounds like you've never conducted a usability study. Results from usability studies are almost always quite fuzzy. They don't "prove" things as such, they just provide evidence that one approach may be better than another. Aside from the overused Fitt's Law, most of usability is very qualitative and subjective.
The other problem is that usability studies are time consuming and expensive, so they are not carried out that often, and usually only measure the experience of new users. Things change once you've gotten over the initial learning curve, but measuring that is even more time consuming and expensive.
You take a 100 people, and tell them to do a particular task on the computer, then, 90 of them will flounder at the same set of problems. Go fix your U/I,
Sure, if it's overwhelming like that, then your UI is broken, but most interface decisions are not like that.
the developers didn't really think holistically about how the computer would be used.
That's because you can never anticipate how your users will use your software (apart from the basics), no matter how holistically you think about it. These features weren't added randomly to KDE, they were added because a significant number of users requested them.
There are UI design best practices, and some well known guidelines, but pretending that designing a good UI for complex software is a black and white issue is completely delusional.
For every feature you can find a set of people that are confused by it, and another set that love/depend on it. Removing said feature because of the first group is the wrong way to go, because if you look at all the features of a modern desktop, it is quite likely that most of your users are in the first group of some feature or other.
Of course, adding features willy nilly is not ideal either, but determining which ones to add is very difficult. But you have to listen to your users and see how large that second group is.
No, not at all. I'm saying it's better because the developers have put more effort into working out what really is the best behaviour, done that by default and provided prefs for only stuff that is really important.
Ah, but there's the rub. What is "really important"? You might not think that a feature to make any window always on top is important, or to change the button order on the titlebar, but I certainly do (and for very good usability reasons I might add). The problem is that the people determining what is "really important" are the developers, and most of their decisions are based on their own experience, and not on any hard and fast usability rule (which, aside from maybe Fitt's Law, don't exist by the way).
Yes, Gnome defaults are easier to understand for just about everyone, and that is something that KDE has been notoriously bad at, but the point here is that a desktop environment needs to allow room for users to grow and become more efficient. That is something I don't see in Gnome. Doing something the developers hadn't thought of is very difficult, because the options are not there.
They do this not by removing random features just to spite people, but by conducting usability studies to find out what actually works and doesn't work for people then doing the former by default and fixing the latter.
Well, that's partially true. A lot of UI decisions in Gnome are made on hunches and the developers "common sense", not usability tests. That's fine, it's certainly not feasible to test every little thing, but it also means that the interface is driven a lot on anecdotal experience. "My mom was confused by this", "no-one I know has ever needed this feature" etc.
Gnome is going the route of OS X. To make it simple so that most people can understand it from the get go. That's fine, for most people, but there will always be a certain percentage that feel limited by an environment like that. A UI that is easy to learn is not always the most efficient way to work once you've learned it. Every time I try Gnome again, I love the feel of it. It feels solid, and clean. But as soon as I get over the warm fuzzies and try do to work, I miss all the features of KDE that make me more productive. Some of those features required learning, some of them required fiddling with settings, but in the end they help me out. I realize that most people will never bother to look around enough to see those features, so using KDE gives them no advantage.
No one is saying Gnome is useless, but an amazing number of people also get a lot of work done with Windows, and DOS before that. That says nothing about how hard it is to accomplish certain tasks. Any action is possible in any operating system, but the amount of work required for it can vary.
I love the feeling of going on a long trip out in the wilderness, and knowing that half the world could have blown up in the meantime and you wouldn't have noticed.
They have to use the libraries, otherwise there is no integration either.
Well sure, you have to use some libraries either way, but in kde, when you open the standard "Open file" dialog, you get kioslave (network transparent file access) "for free". The file dialog supports it, and there is no extra work involved on the part of the application developer. Same with the toolbar, no KDE application developer would ever have to conciously think about whether they want to add support for editable toolbars, because the toolbar classes support it.
But that's not a problem of KDE vs. Gnome, that's a problem stemming from the fact that a lot of programmers only use a part of Gnome (GTK+) instead of using the whole environment.
Exactly. So the question is, why not? My theory is that the libraries are too fractured. GTK provides too little, so for basic features you need to pull in a bunch of external libraries. I can understand why some app developers just don't bother, because it's extra work, and they want to minimize the external dependencies. With KDE apps, you just need to link to kdelibs and you get pretty much everything. Of course that means that one standalone app will be heavier than it could be, but once you run the whole desktop, you end up using the same amount of resources, and each app gets all the features, so from a user experience point of view, it's more consistent.
Hopefully this will be addressed in GTK 3. I heard they are planning on merging a bunch of previously external libraries.
Sometimes (often, actually) when I switch over to a desktop with only one visible window in it, that window will take on the "inactive window" attributes, which in my case makes the window 50% transparent.
Ok, that makes more sense. I haven't seen it myself, but it sounds very similar to this bug: http://bugs.kde.org/show_bug.cgi?id=118062 Unfortunately you're out of luck on it, as it basically won't get fixed. KDE4 tossed that whole component, and transparency is done as one of the effects in the compositing KWin4 (more like Compiz). So hopefully it will work properly in KDE 4.0.
And the other complaint is that konqueror's icon view is really flickery when loading large folders
Yeah I agree with you there. Konqueror's file manager performance is not that great for bigger folders. ANd the flickering drivers me up the wall. It's not noticeable with a fast video card and proper driver, but on my laptop with the ati drivers, it's incredibly annoying. I think Gnome has fixed this, and KDE4 has as well, so hopefully it will be a thing of the past soon.
Gnome is pretty darn good about "developers, developers, developers".
Like how? Look at how much code reuse goes on in KDE vs Gnome. Every KDE app has the same spellchecking engine, every KDE app has the same text editor component, the same menu structure, the same shortcut configuration, the same widgets, dcop, etc, etc. Kontact, the KDE equivalent to Evolution, is just a small shell around all the individual components. KDE4 extends this even further, by making more powerful components available to developers. In a Gnome changelog, on the other hand, you see changes like "gedit gets editable toolbars" or "somegnomeapp gets gnomevfs support". You will never find something like that in a KDE changelog, because all the apps get all those features for free with the framework. I find it absolutely mindboggling that Gedit would have to manually add support for editable toolbars on gnomevfs, and then even find it worth mentioning in the release notes. It really shows that the libraries are not nearly as simple to use, or there is some kind of impediment to using them.
This kind of thing is evident when you look at resource usage between the desktops too. Why is it that KDE and Gnome use similar ammounts of memory when Gnome has so many less features (I'm not saying more features are better, but you can't deny that KDE has more features than Gnome). I'd be happy with a simple desktop like Gnome (it is much prettier after all) if it also was lighter on resources, but it isn't.
The thing is, I jump into KDE, and within a half hour I've found four things that don't work
Dunno what distro you're using, but you should complain, their KDE packages must suck. You do realize that your experience is atypical, don't you?
unresponsiveness In what way?
the crappy menu transparency
So you dug into the options, enabled a feature that is not enabled by default, and that Gnome doesn't have at all, and then you complain that it's not as good as it should be? Nice.
crappy window transparency, which isn't even consistent in itself
Window transparency works fine here. How can a transparent window be "crappy"? Transparency is transparency. Also another feature that is off by default and Gnome lacks. Why do you go around enabling features that you don't like?
Not only is most community-generated C++ terrible, it's very hard to make build across all of the dozens of "standard library" implementations.
That must be why KDE, an environment built with C++, on a toolkit written in C++, now runs on all the Unixes, Windows, and Linux, while Gnome only runs on the unixes, and even there it isn't at all easy to make it compile (witness Slackware dropping it for exactly that reason).
Of course, Qtopia has been around for a long time. From wikipedia: As of 2006, there were 11 different models of mobile phone, and 30 other devices, with several million devices running this software.
I bet you wanted to spend your time doing something else, like making out with your girlfriend (haha, just kidding, if you actually reading my opinion on OOXML you have no girlfriend to make out with).
Ah yes, the mark of a great speaker, a long winded post with little substance, followed by ad hominem attacks. Brilliant.
But for people like me, gentoo is god send. I want to run amarok cvs (btw, another strong point of gentoo - you can run a cvs build of most packages with complete and full support from the package manager) while using a stable version of xine-lib.
Yeah that I can recognize as an advantage. With debian I can only run cvs snapshots of stuff if they've been specifically packaged (for example, right now I'm running the RC of Xorg 7.3 and Openoffice 2.3, as well as some stuff like ffmpeg. But if I want to check out Amarok snapshots I have to bypass the package manager and compile myself.
Slashdot Mirror
America has never said it wants to attack, change the government and own another nation; we don't want more territory- we just want wars there to stop.
Ah yes, the noble Americans ride in to stop the brutal war in Iraq. Oh wait..
While I agree with many of your points, the notion that the US just goes to war because of some altruistic need to stop wars in other places is laughable. There was no war in Afghanistan, there was no war in Iraq. Then the US showed up, and now there is war in both.
It's a mixed bag. Obviously it will work for some people, otherwise it would have never been released in the first place, but that doesn't make the people for whom it doesn't work liars. For them, Vista is pure garbage. The fact that it works for you has absolutely no bearing on that fact. Conversely, the fact that Vista is useless for them doesn't mean it can't work perfectly for you.
For me, Vista is completely useless, and I've had it on my laptop for the past 6 months, trying it every few weeks or so to download updates and see if it managed to not completely suck, but it still does.
Why would I voluntarily give up or relinquish my hands?
Removed because GNOME swapped over to the FDO menu spec, breaking the old one, which replaced when manpower allowed. Not removed for reasons of simplicity or usability.
That reeks of poor project management. If switching to the FDO menu spec will remove a major feature, then why didn't they wait until it could be done properly?
Replaced with something that gasp, still manages windows, does so in a sane way by default and actually integrates with the desktop. In the end, no net loss of function as you can swap Metacity for Sawfish again (yes, it's configurable!).
Of course it still manages windows, but there are far less features, which was my point (whether you use those features or not is completely irrelevant). Your argument that you can swap Sawfish back is inane. Sure, I could also maintain my own branch of metacity, and code the features myself. That doesn't make it a realistic alternative. For 99% of users, all that functionality is gone.
Actually, it the saver itself is just as configurable as plain xscreensaver. No, savers are not configurable but if you read the bug report the developer is planning to implement this. It was replaced again for better integration with the desktop as JWZ wasn't willing to do/allow it. Most (all?) of the main configuration options that were lost were actually moved elsewhere (e.g. to the power manager).
"planning to implement this" being the key words here. That doesn't mean it will get done, and if it does, it will finally gain a feature that every desktop for 10 years has had.
And the reply clarifying GNOME's actual position - which is that features will be implemented if they are genuinely useful and a reasonable way of doing it can be found.
This is exactly the problem. If I want to print in draft mode, I don't give a flying fuck that there are plans to implement that feature, or no one has found the absolutely ideal way to present it in the GUI. I need that feature, and I need it NOW. Like Linus said, until you have a feature, you can't even talk about usability, you can only talk about UNusability. So even though the KDE print dialog might look messier than the Gnome one, the KDE dialog possesses at least some measure of usability, while the Gnome dialog is COMPLETELY UNUSABLE for any task that requires the missing feature.
Yes, of course, "everyone" knows it is true. I'd like, just once, even one example of this.
Yes and I would like, just once, an example of the common myth that water is wet.
Yet, I am loathe to let you wallow in your ignorance, so I've done a quick search for you. I follow gnome development only from a distance, so I'm sure I've missed a lot here.
The menu editor, removed somewhere in the 2.x cycle, not replaced until years later: http://www.linux.com/articles/57088
Sawfish replaced with Metacity, losing tons of features/configurability. http://mail.gnome.org/archives/usability/2002-December/msg00069.html
Galeon 1.2 replaced with Galeon 1.3, losing features, and then later replaced with Epiphany, losing more features.
http://wouterverhelst.livejournal.com/46098.html
xscreensaver replaced with gnome screensaver, which has no options at all https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/22007
And an example where important features are intentionally not implemented for usability reasons:
https://lists.linux-foundation.org/pipermail/desktop_architects/2005-December/001587.html
There are many more, this list was just the product of a quick google search
If by "more features" you mean "checkboxes and radiobuttons", true.
;)
That is configurability, not features. There is more configurability in KDE, and that allows features, but there are also more real features.
But I consider usability a feature.
Of course that can be considered a feature from a marketing point of view, but not from a code point of view. Usability does not cost resources (usually).
I tried to use k3b once, and I couldn't figure it out.
Wow. Sorry I don't want to come across as a jackass, but K3B is really simple to use. Open it, click the giant New Data CD button, then drag the files you want from the top to the bottom. Click the burn button. Comparing that to cdrecord is ludicrous.
There might be simpler burning GUI's available, but none of them give you the power that K3B does (when you want to do more than just burn a couple files.
The question is not why Gnome takes more memory than KDE. The question is why KDE take more memory than the shell if it doesn't make things easier to use.
Troll
If (and I'm assuming it is not the case and if you wanted to you could use only QT) you must use the entire KDE framework to build an app, well that locks you in to using all of KDE's libraries doesn't it?
Yes you could use Qt only. And "only" is semantics here, Qt4 provides you with everything you need for most apps (far, far more than GTK). Since Qt4 came out, the kdelibs really don't have much in them anymore that an application developer would care about if they're not targetting KDE specifically. There is some stuff, but a lot of it is mostly useful because of the integration it brings with other apps.
That doesn't mean you're locked in to anything though. With KDE 4, you'll even be able to link to the kdelibs and compile on Windows or OS X. You get all the features, and none of the porting.
Yelling at the GNOME guys because you need to include 5 libraries and 5 header files instead of one just tells me you're a lazy programmer.
Good programmers are lazy. That drives them to develop frameworks that allow you to do powerful things easily. If your framework isn't convenient to use (like, having to pull in 5 different libraries that have different api's and complicate the build and packaging process just to build a basic interface) makes developers invent their own thing, or do silly things like copying library code into their apps instead of linking to it. ( http://www.chipx86.com/blog/?p=205 )
And you're right, usability studies are generally qualitative in nature, but using mixed methods allows you generalise the qualitative data while still being able to look at individual differences.
No, I'm saying normal users are just fine with the desktop environments as they are today. There is room for improvement, but desktop usability is NOT a factor in why people don't use linux. See the last link for a study supporting this point.
And... bam! And there's the myth again, twice in one post. That has to be some sort of record. So go on, provide some references to back up these assertions.
*sigh* You can't argue that a lot of configurability has been removed from Gnome since the 1.4 days. These changes were done in the name of usability. Some of them justified, of course. I'm not going to dig through the mailing lists and bugzilla to find you references. You're a smart guy, you know this happened, and can find your own references. Good job nitpicking though and not actually answering the important parts of my post.
You mean, "they were added because a significant number of users who were motivated and willing to submit feature requests using the appropriate mechanism, who were technically competent enough to do so and knew that such a mechanism existed requested a particular feature". Which, of course is a flaming great classic example of response bias - the same thing that makes television and newspaper polls useless as an indicator for the actual value of a population parameter.
Yes, there is bias there, but not as bad as you would make it seem. Technical users make requests on behalf of less technical ones as well. And face it, the majority of Linux users are technical users. You can ignore this and not cater to them if you want, but you're targeting users that may never even use Linux. Usability tests have shown that user have just as easy a time doing tasks with KDE than Windows XP. The current desktop is not an impediment to user adoption. Less technical users don't use Linux because of hardware support, pre-installs of Windows, and lack of awareness. Sit down a normal user with Linux (KDE or Gnome) and they won't have more trouble with it than with Windows.
What you have is an bunch geeks and hobbyists - the very people to want extreme, nifty and mostly useless features - in control of functional requirements for KDE.
Face it, that is the majority of your user base. You can't neglect your primary user because of some mythical novice user. They are also extremely valuable, because technical users _contribute_ while novice users just use the software.
Also, what about removing useless features? Does that ever get voted on?
Yes, and features get removed from KDE regularly if they create real problems or can be replaced with a better system. Removing features just because someone is confused by them is not a valid reason. You have to think about it more critically than that.
despite the fact that major usability studies were run on GNOME in 2001 and 2005 and continue in part at betterdesktop.org
So? KDE has similar studies, on that site, as well as http://openusability.org/ and from the KDE usability team http://usability.kde.org/activity/testing/relevantive-kde3.2/index.php and independently http://www.linux-usability.de/download/linux_usability_report_en.pdf
Please, Gnome are not the only ones thinking about usability. They are just suffering from the delusion that less features and less configurability makes for usability, when in fact the problem is much more complex than that. Making simple software usable is comparatively easy to do. The real challenge is making complex and flexible software usable without removing any of the power. KDE hasn't solved that problem, obviously, but they are working towards it without throwing out what makes KDE worth using over something like Windows.
People are the mostly same. Usability studies prove that.
Sounds like you've never conducted a usability study. Results from usability studies are almost always quite fuzzy. They don't "prove" things as such, they just provide evidence that one approach may be better than another. Aside from the overused Fitt's Law, most of usability is very qualitative and subjective.
The other problem is that usability studies are time consuming and expensive, so they are not carried out that often, and usually only measure the experience of new users. Things change once you've gotten over the initial learning curve, but measuring that is even more time consuming and expensive.
You take a 100 people, and tell them to do a particular task on the computer, then, 90 of them will flounder at the same set of problems. Go fix your U/I,
Sure, if it's overwhelming like that, then your UI is broken, but most interface decisions are not like that.
the developers didn't really think holistically about how the computer would be used.
That's because you can never anticipate how your users will use your software (apart from the basics), no matter how holistically you think about it. These features weren't added randomly to KDE, they were added because a significant number of users requested them.
There are UI design best practices, and some well known guidelines, but pretending that designing a good UI for complex software is a black and white issue is completely delusional.
For every feature you can find a set of people that are confused by it, and another set that love/depend on it. Removing said feature because of the first group is the wrong way to go, because if you look at all the features of a modern desktop, it is quite likely that most of your users are in the first group of some feature or other.
Of course, adding features willy nilly is not ideal either, but determining which ones to add is very difficult. But you have to listen to your users and see how large that second group is.
No, not at all. I'm saying it's better because the developers have put more effort into working out what really is the best behaviour, done that by default and provided prefs for only stuff that is really important.
Ah, but there's the rub. What is "really important"? You might not think that a feature to make any window always on top is important, or to change the button order on the titlebar, but I certainly do (and for very good usability reasons I might add). The problem is that the people determining what is "really important" are the developers, and most of their decisions are based on their own experience, and not on any hard and fast usability rule (which, aside from maybe Fitt's Law, don't exist by the way).
Yes, Gnome defaults are easier to understand for just about everyone, and that is something that KDE has been notoriously bad at, but the point here is that a desktop environment needs to allow room for users to grow and become more efficient. That is something I don't see in Gnome. Doing something the developers hadn't thought of is very difficult, because the options are not there.
They do this not by removing random features just to spite people, but by conducting usability studies to find out what actually works and doesn't work for people then doing the former by default and fixing the latter.
Well, that's partially true. A lot of UI decisions in Gnome are made on hunches and the developers "common sense", not usability tests. That's fine, it's certainly not feasible to test every little thing, but it also means that the interface is driven a lot on anecdotal experience. "My mom was confused by this", "no-one I know has ever needed this feature" etc.
Gnome is going the route of OS X. To make it simple so that most people can understand it from the get go. That's fine, for most people, but there will always be a certain percentage that feel limited by an environment like that. A UI that is easy to learn is not always the most efficient way to work once you've learned it. Every time I try Gnome again, I love the feel of it. It feels solid, and clean. But as soon as I get over the warm fuzzies and try do to work, I miss all the features of KDE that make me more productive. Some of those features required learning, some of them required fiddling with settings, but in the end they help me out. I realize that most people will never bother to look around enough to see those features, so using KDE gives them no advantage.
No one is saying Gnome is useless, but an amazing number of people also get a lot of work done with Windows, and DOS before that. That says nothing about how hard it is to accomplish certain tasks. Any action is possible in any operating system, but the amount of work required for it can vary.
I love the feeling of going on a long trip out in the wilderness, and knowing that half the world could have blown up in the meantime and you wouldn't have noticed.
They have to use the libraries, otherwise there is no integration either.
Well sure, you have to use some libraries either way, but in kde, when you open the standard "Open file" dialog, you get kioslave (network transparent file access) "for free". The file dialog supports it, and there is no extra work involved on the part of the application developer. Same with the toolbar, no KDE application developer would ever have to conciously think about whether they want to add support for editable toolbars, because the toolbar classes support it.
But that's not a problem of KDE vs. Gnome, that's a problem stemming from the fact that a lot of programmers only use a part of Gnome (GTK+) instead of using the whole environment.
Exactly. So the question is, why not? My theory is that the libraries are too fractured. GTK provides too little, so for basic features you need to pull in a bunch of external libraries. I can understand why some app developers just don't bother, because it's extra work, and they want to minimize the external dependencies. With KDE apps, you just need to link to kdelibs and you get pretty much everything. Of course that means that one standalone app will be heavier than it could be, but once you run the whole desktop, you end up using the same amount of resources, and each app gets all the features, so from a user experience point of view, it's more consistent.
Hopefully this will be addressed in GTK 3. I heard they are planning on merging a bunch of previously external libraries.
Sometimes (often, actually) when I switch over to a desktop with only one visible window in it, that window will take on the "inactive window" attributes, which in my case makes the window 50% transparent.
Ok, that makes more sense. I haven't seen it myself, but it sounds very similar to this bug: http://bugs.kde.org/show_bug.cgi?id=118062 Unfortunately you're out of luck on it, as it basically won't get fixed. KDE4 tossed that whole component, and transparency is done as one of the effects in the compositing KWin4 (more like Compiz). So hopefully it will work properly in KDE 4.0.
And the other complaint is that konqueror's icon view is really flickery when loading large folders
Yeah I agree with you there. Konqueror's file manager performance is not that great for bigger folders. ANd the flickering drivers me up the wall. It's not noticeable with a fast video card and proper driver, but on my laptop with the ati drivers, it's incredibly annoying. I think Gnome has fixed this, and KDE4 has as well, so hopefully it will be a thing of the past soon.
Gnome is pretty darn good about "developers, developers, developers".
Like how? Look at how much code reuse goes on in KDE vs Gnome. Every KDE app has the same spellchecking engine, every KDE app has the same text editor component, the same menu structure, the same shortcut configuration, the same widgets, dcop, etc, etc. Kontact, the KDE equivalent to Evolution, is just a small shell around all the individual components. KDE4 extends this even further, by making more powerful components available to developers. In a Gnome changelog, on the other hand, you see changes like "gedit gets editable toolbars" or "somegnomeapp gets gnomevfs support". You will never find something like that in a KDE changelog, because all the apps get all those features for free with the framework. I find it absolutely mindboggling that Gedit would have to manually add support for editable toolbars on gnomevfs, and then even find it worth mentioning in the release notes. It really shows that the libraries are not nearly as simple to use, or there is some kind of impediment to using them.
This kind of thing is evident when you look at resource usage between the desktops too. Why is it that KDE and Gnome use similar ammounts of memory when Gnome has so many less features (I'm not saying more features are better, but you can't deny that KDE has more features than Gnome). I'd be happy with a simple desktop like Gnome (it is much prettier after all) if it also was lighter on resources, but it isn't.
The thing is, I jump into KDE, and within a half hour I've found four things that don't work
Dunno what distro you're using, but you should complain, their KDE packages must suck. You do realize that your experience is atypical, don't you?
unresponsiveness
In what way?
the crappy menu transparency
So you dug into the options, enabled a feature that is not enabled by default, and that Gnome doesn't have at all, and then you complain that it's not as good as it should be? Nice.
crappy window transparency, which isn't even consistent in itself
Window transparency works fine here. How can a transparent window be "crappy"? Transparency is transparency. Also another feature that is off by default and Gnome lacks. Why do you go around enabling features that you don't like?
Not only is most community-generated C++ terrible, it's very hard to make build across all of the dozens of "standard library" implementations.
That must be why KDE, an environment built with C++, on a toolkit written in C++, now runs on all the Unixes, Windows, and Linux, while Gnome only runs on the unixes, and even there it isn't at all easy to make it compile (witness Slackware dropping it for exactly that reason).
Of course, Qtopia has been around for a long time. From wikipedia: As of 2006, there were 11 different models of mobile phone, and 30 other devices, with several million devices running this software.
I bet you wanted to spend your time doing something else, like making out with your girlfriend (haha, just kidding, if you actually reading my opinion on OOXML you have no girlfriend to make out with).
Ah yes, the mark of a great speaker, a long winded post with little substance, followed by ad hominem attacks. Brilliant.
Or blend it..
But for people like me, gentoo is god send. I want to run amarok cvs (btw, another strong point of gentoo - you can run a cvs build of most packages with complete and full support from the package manager) while using a stable version of xine-lib.
Yeah that I can recognize as an advantage. With debian I can only run cvs snapshots of stuff if they've been specifically packaged (for example, right now I'm running the RC of Xorg 7.3 and Openoffice 2.3, as well as some stuff like ffmpeg. But if I want to check out Amarok snapshots I have to bypass the package manager and compile myself.