yes, they are highly convenient for KDE applications. you can use kioslaves with fuse, which is rather cool, but being separate entities allows for these things to work everywhere KDE does. it also makes for extremely easy development of apps that use that API.
so unsurprisingly, kio is really designed make life easy for KDE apps with an eye to portability. it would be nice if every OS out there offered a standard interface as coherent and cogent as kioslaves, but they don't.
if you go to either of those two URLs above, you'll see that your assertion that GNOME is where is where "all the OpenOffice" integration work is being done is less than accurate.
> BUT IT DEPENDED ON QT WHICH MADE THE WHOLE > FUCKING THING GPL
screaming doesn't make you less wrong. the original assertion was that webcore "killing" khtml would result in a better licensing situation. and what i was pointing out was that it wouldn't. see, khtml is, was and likely always will be LGPL. popping webcore in there instead and using it against Qt results in the same licensing scenario. IOW, no change. it isn't the webcore/khtml code that is of interest in regards to licensing, it's the toolkit you compile it against.
if the original poster had said, "if KDE devs would stop linking KHTML to Qt then it would result in a cheaper licensing situation for closed source devel" i would've agreed. because, well, they would've been right. =)
what is untrue about your message is the assertion that there isn't a lot of code shared between KDE and other projects, including code that originated within KDE itself.
what is also untrue is that more widespread sharing of KDE code has a lot less to do with Qt licensing than it does with other issues, such as language preferences, integration issues, NIH, industry politics and us not having promoted the platform as much as we probably could have in the past.
that's what i meant by "simplistic". you try and paint it as a one dimensional issue, but it's not. often times, Qt licensing costs never really come into the play.
not just there, but also in their project lead's email to kfm-devel.
> ask Apple how many man-months it took them to > sort out KHTML
few enough that it was worth passing up every other option in front of them.
> your usual standards
oh, you're one of those people who follow me around, reading what i write only to get all pissy about it afterwards? now i'm doubly curious as to who the (wo)man behind the mask is.
> nonsensical assertions about Red Hat's position > with GNOME being the same as TrollTech
analogous, which is what i was implying, isn't equivalent to "the same". i was offering a familiar frame of reference for comparison.
> and a, frankly, bizarre mention of Microsoft.
the mention of MS was to remind you who the competition on the desktop truly is, and who benefits from people such as yourself sowing baseless dissent.
> I might have been a bit harsh on the KDE people =)
i appreciate this clarification =) yeah, plan9 has a number of great ideas, and there are several things in KDE that are directly inspired by them. taj has said publicly more than once that KStandardDirs was directly inspired by plan9, for instance.
> It's poorly engineered, and most of its code is > shockingly badly written
which is exactly the opposite of what Nokia just said about KDE code in this article. good job!
> KDE is totally dependent on TrollTech, it's > health as a company and goodwill
we benefit from the health and goodwill of Trolltech. GNOME benefits from the health and goodwill of Red Hat. we could add a number of such entities to each project's roster, and that's a good thing.
but KDE is not dependant on Trolltech. at least not in the way the dictionary defines "dependant". in fact, KDE isn't dependant on any single entity though we benefit from the involvement of many, and that's one of our strengths as a project.
> one wonders how you've remained unmodded down > by the KDE zealots
likely because it's more amusing to watch what new sillyness you people can come up with than to mod you down. you may expect those who care about KDE to try and supress alternative viewpoints, but that's not generally how we try and do things.
> don't bother mentioning the FreeQt agreements, > they aren't worth the bandwidth used to email > them
i suppose you should let the lawyers who worked on the most recent version of the agreement know then. unless, of course, they might just understand it a lot better than you.
> KDE is being badly left behind by GNOME.
ah, the bias emerges. =) you are entitled to your opinion, of course. i feel you're completely out to lunch on this one, in part due to my own research into both platforms and in part due to listening to people evaluating Open Source desktops for real world deployments.
all the same, regardless of whether i'm right or you're right or we're both right, don't you think there are more productive ways of approaching this issue? you know, ones that don't make Microsoft chuckle in glee.
> Now do you see why hardly any KDE code gets > re-used outside the KDE project
it's due at least in part to people such as yourself who go around playing the Anonymous Ignoramus spreading lies, half truths and other misinformation.
it'd be nice to discuss the real issues like grown ups so that things like the Qt license can be put into proper perspective, as opposed to the overly simplistic and vitriolic position you have taken here. but that would require an informed, mature, non-anonymous person on the other side of that discussion. when you find one willing to play that part let me know and we can find an appropriate venue.
i'm sure (s)he did read the "first fucking sentence". equally sure, you seem to be unable to understand how licensing works. and fair enough, it's a complex and tricky topic that legal professionals spend stupid amounts of time on. hm. maybe that's WHY it's complex and tricky; but anyways....
if webkit were to "kill off" khtml, which doesn't actually make any sense since they are all collaborating on this thing together, that wouldn't change khtml's license or webkit's license. no license change would happen for those using khtml, either in webkit or "straight from KDE's svn repository" versions. it's the LGPL either way. what matters is the rendering toolkit used beneath it, but that isn't a unique privilege of webkit over "vanilla" khtml.
how do you think "everything is a file" works, exactly?
and trying to blame KDE for the GIMP sucking is a bit unfair. it's like blaming Linus for problems in FreeBSD, or vice versa.
KDE comes along and solves a long standing issue on the UNIX desktop in a very UNIX-y way (a standard interface to file I/O, regardless of access mechanism, e.g. "everything is a file") and you try and turn that success into a sign of failure because not everyone else got on the bandwagon.
if it wasn't for the fact that this is slashdot, i'd be amazed.
and this is actually the result of working in coordination with the KHTML people. so this isn't just a PR move, but a coordinated effort between Apple and KDE.
this isn't the end, nor even a beginning, but rather a positive step in a long journey we're taking together.
that was kind of the whole point, now wasn't it? we WANT a happy collective of projects each furthering their own goals and helping each other in their respective journeys as far as that is possible and makes sense.
when someone points out that a process isn't working well, don't blame the messenger.
when that message results in good things, hail the improvement.
the webcore people are simply working like animals and this slipped off their radar. a little priority reevaluation later and things are rapidly improving. i hope to see some of the details of how these conclusions were arrived at to be published at some point in the near future.
wonderful logic there. khtml continues to improve at a nice clip, even getting acid2 compliance before gecko does, and yet it might be a sign that all is not well?
please, go spread your fear, uncertainty and doubt elsewhere. the project is doing well and as a whole is growing day by day.
if you are truly concerned, you could of course help out. if you aren't a developer, there's documentation, bug triage and so much more! you could even help find new developers by making sure more people are aware of KDE and it's development framework.
i wasn't referring to the people who do the actual work, who i would agree do pay a lot of attention to these things. i was talking about the "enthusiasts", which was a nice way of saying "very loud users";)
> It was one of the main pieces of improvement in OS-X
and it shows. =)
> It was a centerpiece of one of the recent GNOME releases.
and unfortunately i still groan every time i'm faced with it =/
> that's the sort of system you'll be seeing in the future
i remember the screenshots and the discussion on kde-usability, and i've still got that site bookmarked. and yes, i do plan on coming back to it for KDE4. i really liked a number of the concepts there, though i'm still of the opinion that there are waaaay too many configuration options in that design =)
btw, most of the thumbnails there now link to images that have 404'd...
you'll find various mailing lists we use to collaborate at http://www.kde.org/mailinglists/
look for ones about usability.
> Did you notice that finding the right > communication channel in a Open Source project > website is often an impossible task?
not usually. first i look for links named "mailing list[s]" or "developers" or, if that fails, "documentation". it's usually right there on the main page. there's a "mailing lists" link on kde.org for instance =)
perhaps the user fanbase is. but the developers seem pretty focused elsewhere. i think, within KDE at least, we realize that Microsoft currently has 90%+ of the desktop market and that they define the bar (for better or worse) which means they are the ones to "compete" with. everyone else represents mostly friendly rivalry and cooperative efforts.
> I really think it's getting bad now
you weren't around 3-5 years ago, were you?;) its gotten a lot better, and the next year or two promises to shove us ahead at least as far again.
> The division of effort and uncertainty on the > layer underneath
the division of effort is not as big an issue as you might think. this has been covered time and time again previously, so i'll save everyone else's bandwidth here. but you may want to go out and do some reading on the matter.
> I don't think either of these systems have even > caught up with current offerings
in terms of sheer number of applications, you're correct. that's mostly a function of user base, however.
otherwise, we're coming along pretty well. X.org is pushing our graphics capabilities forward nicely, Freedesktop.org is serving as a cooperative zone, and KDE is making good strides forward both on the core technologies as well as the apps (c.f. kpdf in 3.4, or amaroK 1.2 or Scribus as just three examples)
again, compare where we were 5 years ago when Win2000 and MacOS X came out. see where we were in relationship. now compare again against their current offerings on a cutting edge, properly set-up Linux/KDE/X.org system. now imagine us making the same amount of progress over the next 5 years and it becomes fairly apparent that Open Source desktops will over take closed source desktops in most metrics.
especially if we maintain the current rate of development effort growth.
> The only remaining hurdle is IPC, which itself > is covered by scheme/MIME
no, that's covered by whatever will end up being DCOP+1, which currently seems to be a future version of DBUS.
XML is generally too slow and is unnecessary for most IPC. for the cases where it does make sense, we already have RFCs for that such as XMLRPC and SOAP.
> will let the traditional unix "small tool that > does one thing right" philosophy drive the > complex apps that use it
we've been doing this in KDE for several years now. look at Kontact: it's the binding together of a handful of applications using IPC (DBUS, in specific) and an extensible plugin system. or look at Konqueror: it uses KParts to load embedded viewers for most common file types based on mimetype relationships to applications.
the more that other Open Source desktops adopt KDE technologies and techniques, the faster this will spread elsewhere. in the meantime, KDE works pretty well and we'll continue to blaze these trails further.
erm. who said anything about a registry? i appreciate your distaste for a registry, but KDE neither has one nor is planning making such a thing a central point of configuration. so... yeah. chill =)
> Desktop interop is important for the community > so we can have a critical mass of software > consumers for our community of software > developers
i couldn't agree more. which is why when creating new "standards" we need to do so in a way that makes it as straight forward as possible to get the implemented. the mimetype spec really dropped the ball on that one. this is not a KDE problem, but it was a bit of a learning experience between all the software projects involved in perhaps how not to create specs.
you said earlier that it's not about perfection, it's about pragmatism. and i'd agree.
if the mimetype spec had been pragmatic, it would've documented the existing working systems, of which KDE probably was the definitive example of such a thing. instead, it was written as a new development concept. this may make something better, but it takes longer. if you value pragmatism over perfection (personally, i'd like to see a dash of both;) then you'd realize how we kind of cocked up with the mimetype spec.
it'll get sorted out eventually, and i think we're all learning from that experience.
it requires striking a ballance. QA is dead simple if there are no options and few features. but then you have software almost nobody will want to, or even be able to use in the real world. so you add some features, some configuration... at the cost of QA overhead. but you get useful software.
ballance.
it's similar with the other items you list (bug fixing, integration, etc), though QA is hit harder than them. the "finding the options" problem is more a limitation of how we enforce hierarchical navigation of these things more than having a sane number of options. because even a sane number of options quickly spirals out of range of these mechanisms.
so... we're engaged in an ongoing search to find that ballance in KDE, and i think we're finally getting some good formulas together. KDE 3.x is used by enough people who really enjoy it that i don't think it's fair to call it "unusable", but it can be improved upon (it always can;). and so we continue to make new releases.....
in his FOSDEM interview, Matthias Ettrich (the project's founder) was asked what three things he'd like to focus on in KDE 4 and he said: usability, usability, usability. good answer.
of course, usability is about a LOT more than ensuring there are only N options in an app, or that the menus are correctly arranged. those are important steps, but let's not get obsessive over details that are only part of the picture, something i see a lot of people do, sadly.
for instance, i find it interesting that for being such a central piece of UI, the file dialog is rarely considered by usability "enthusiasts". take the KDE file dialog and compare it to other Open Source toolkit file dialogs.... personally, i'd take a file dialog like KDE's even if it meant having to put up with some annoying config dialogs elsewhere. it's items like file dialogs which provide most of the "usability" in a desktop.
but then... i use my systems to get real world work done and so these sorts of things actually matter to me. =)
Slashdot Mirror
yes, they are highly convenient for KDE applications. you can use kioslaves with fuse, which is rather cool, but being separate entities allows for these things to work everywhere KDE does. it also makes for extremely easy development of apps that use that API.
so unsurprisingly, kio is really designed make life easy for KDE apps with an eye to portability. it would be nice if every OS out there offered a standard interface as coherent and cogent as kioslaves, but they don't.
http://kde.openoffice.org/
http://artax.karlin.mff.cuni.cz/~kendy/blog/
if you go to either of those two URLs above, you'll see that your assertion that GNOME is where is where "all the OpenOffice" integration work is being done is less than accurate.
> You really are a moron, aren't you?
my, what fine social skills you have.
> BUT IT DEPENDED ON QT WHICH MADE THE WHOLE
> FUCKING THING GPL
screaming doesn't make you less wrong. the original assertion was that webcore "killing" khtml would result in a better licensing situation. and what i was pointing out was that it wouldn't. see, khtml is, was and likely always will be LGPL. popping webcore in there instead and using it against Qt results in the same licensing scenario. IOW, no change. it isn't the webcore/khtml code that is of interest in regards to licensing, it's the toolkit you compile it against.
if the original poster had said, "if KDE devs would stop linking KHTML to Qt then it would result in a cheaper licensing situation for closed source devel" i would've agreed. because, well, they would've been right. =)
what is untrue about your message is the assertion that there isn't a lot of code shared between KDE and other projects, including code that originated within KDE itself.
what is also untrue is that more widespread sharing of KDE code has a lot less to do with Qt licensing than it does with other issues, such as language preferences, integration issues, NIH, industry politics and us not having promoted the platform as much as we probably could have in the past.
that's what i meant by "simplistic". you try and paint it as a one dimensional issue, but it's not. often times, Qt licensing costs never really come into the play.
> in the PUBLIC RELATIONS release
not just there, but also in their project lead's email to kfm-devel.
> ask Apple how many man-months it took them to
> sort out KHTML
few enough that it was worth passing up every other option in front of them.
> your usual standards
oh, you're one of those people who follow me around, reading what i write only to get all pissy about it afterwards? now i'm doubly curious as to who the (wo)man behind the mask is.
> nonsensical assertions about Red Hat's position
> with GNOME being the same as TrollTech
analogous, which is what i was implying, isn't equivalent to "the same". i was offering a familiar frame of reference for comparison.
> and a, frankly, bizarre mention of Microsoft.
the mention of MS was to remind you who the competition on the desktop truly is, and who benefits from people such as yourself sowing baseless dissent.
apologies for showing you up in public.
> I might have been a bit harsh on the KDE people =)
i appreciate this clarification =) yeah, plan9 has a number of great ideas, and there are several things in KDE that are directly inspired by them. taj has said publicly more than once that KStandardDirs was directly inspired by plan9, for instance.
> This way the three groups, Nokia, KDE, and
> Apple, will be working on making one browser
> engine perfect
this would be purpose and point of http://khtml.info/ =)
> It's poorly engineered, and most of its code is
> shockingly badly written
which is exactly the opposite of what Nokia just said about KDE code in this article. good job!
> KDE is totally dependent on TrollTech, it's
> health as a company and goodwill
we benefit from the health and goodwill of Trolltech. GNOME benefits from the health and goodwill of Red Hat. we could add a number of such entities to each project's roster, and that's a good thing.
but KDE is not dependant on Trolltech. at least not in the way the dictionary defines "dependant". in fact, KDE isn't dependant on any single entity though we benefit from the involvement of many, and that's one of our strengths as a project.
> one wonders how you've remained unmodded down
> by the KDE zealots
likely because it's more amusing to watch what new sillyness you people can come up with than to mod you down. you may expect those who care about KDE to try and supress alternative viewpoints, but that's not generally how we try and do things.
> don't bother mentioning the FreeQt agreements,
> they aren't worth the bandwidth used to email
> them
i suppose you should let the lawyers who worked on the most recent version of the agreement know then. unless, of course, they might just understand it a lot better than you.
> KDE is being badly left behind by GNOME.
ah, the bias emerges. =) you are entitled to your opinion, of course. i feel you're completely out to lunch on this one, in part due to my own research into both platforms and in part due to listening to people evaluating Open Source desktops for real world deployments.
all the same, regardless of whether i'm right or you're right or we're both right, don't you think there are more productive ways of approaching this issue? you know, ones that don't make Microsoft chuckle in glee.
> Now do you see why hardly any KDE code gets
> re-used outside the KDE project
it's due at least in part to people such as yourself who go around playing the Anonymous Ignoramus spreading lies, half truths and other misinformation.
it'd be nice to discuss the real issues like grown ups so that things like the Qt license can be put into proper perspective, as opposed to the overly simplistic and vitriolic position you have taken here. but that would require an informed, mature, non-anonymous person on the other side of that discussion. when you find one willing to play that part let me know and we can find an appropriate venue.
i'm sure (s)he did read the "first fucking sentence". equally sure, you seem to be unable to understand how licensing works. and fair enough, it's a complex and tricky topic that legal professionals spend stupid amounts of time on. hm. maybe that's WHY it's complex and tricky; but anyways....
if webkit were to "kill off" khtml, which doesn't actually make any sense since they are all collaborating on this thing together, that wouldn't change khtml's license or webkit's license. no license change would happen for those using khtml, either in webkit or "straight from KDE's svn repository" versions. it's the LGPL either way. what matters is the rendering toolkit used beneath it, but that isn't a unique privilege of webkit over "vanilla" khtml.
how do you think "everything is a file" works, exactly?
and trying to blame KDE for the GIMP sucking is a bit unfair. it's like blaming Linus for problems in FreeBSD, or vice versa.
KDE comes along and solves a long standing issue on the UNIX desktop in a very UNIX-y way (a standard interface to file I/O, regardless of access mechanism, e.g. "everything is a file") and you try and turn that success into a sign of failure because not everyone else got on the bandwagon.
if it wasn't for the fact that this is slashdot, i'd be amazed.
yes, it's a GREAT thing =)
and this is actually the result of working in coordination with the KHTML people. so this isn't just a PR move, but a coordinated effort between Apple and KDE.
this isn't the end, nor even a beginning, but rather a positive step in a long journey we're taking together.
we don't need, nor want, "bad guys".
that was kind of the whole point, now wasn't it? we WANT a happy collective of projects each furthering their own goals and helping each other in their respective journeys as far as that is possible and makes sense.
when someone points out that a process isn't working well, don't blame the messenger.
when that message results in good things, hail the improvement.
actually i DO know that this wasn't planned.
the webcore people are simply working like animals and this slipped off their radar. a little priority reevaluation later and things are rapidly improving. i hope to see some of the details of how these conclusions were arrived at to be published at some point in the near future.
in any case, kudos to everyone involved.
wonderful logic there. khtml continues to improve at a nice clip, even getting acid2 compliance before gecko does, and yet it might be a sign that all is not well?
please, go spread your fear, uncertainty and doubt elsewhere. the project is doing well and as a whole is growing day by day.
if you are truly concerned, you could of course help out. if you aren't a developer, there's documentation, bug triage and so much more! you could even help find new developers by making sure more people are aware of KDE and it's development framework.
FSFS
hahaha.. oh man. please don't read my blog then. it's a well known fact that i can't spell. (thank the goddess for editors!)
;-P
rumour has it that it may be linked to my odd inability to use the shift key.
> The file dialog gets tons of attention
;)
i wasn't referring to the people who do the actual work, who i would agree do pay a lot of attention to these things. i was talking about the "enthusiasts", which was a nice way of saying "very loud users"
> It was one of the main pieces of improvement in OS-X
and it shows. =)
> It was a centerpiece of one of the recent GNOME releases.
and unfortunately i still groan every time i'm faced with it =/
> that's the sort of system you'll be seeing in the future
i remember the screenshots and the discussion on kde-usability, and i've still got that site bookmarked. and yes, i do plan on coming back to it for KDE4. i really liked a number of the concepts there, though i'm still of the opinion that there are waaaay too many configuration options in that design =)
btw, most of the thumbnails there now link to images that have 404'd...
you'll find various mailing lists we use to collaborate at http://www.kde.org/mailinglists/
look for ones about usability.
> Did you notice that finding the right
> communication channel in a Open Source project
> website is often an impossible task?
not usually. first i look for links named "mailing list[s]" or "developers" or, if that fails, "documentation". it's usually right there on the main page. there's a "mailing lists" link on kde.org for instance =)
> just means attention and effort is deflected
;) its gotten a lot better, and the next year or two promises to shove us ahead at least as far again.
perhaps the user fanbase is. but the developers seem pretty focused elsewhere. i think, within KDE at least, we realize that Microsoft currently has 90%+ of the desktop market and that they define the bar (for better or worse) which means they are the ones to "compete" with. everyone else represents mostly friendly rivalry and cooperative efforts.
> I really think it's getting bad now
you weren't around 3-5 years ago, were you?
> The division of effort and uncertainty on the
> layer underneath
the division of effort is not as big an issue as you might think. this has been covered time and time again previously, so i'll save everyone else's bandwidth here. but you may want to go out and do some reading on the matter.
> I don't think either of these systems have even
> caught up with current offerings
in terms of sheer number of applications, you're correct. that's mostly a function of user base, however.
otherwise, we're coming along pretty well. X.org is pushing our graphics capabilities forward nicely, Freedesktop.org is serving as a cooperative zone, and KDE is making good strides forward both on the core technologies as well as the apps (c.f. kpdf in 3.4, or amaroK 1.2 or Scribus as just three examples)
again, compare where we were 5 years ago when Win2000 and MacOS X came out. see where we were in relationship. now compare again against their current offerings on a cutting edge, properly set-up Linux/KDE/X.org system. now imagine us making the same amount of progress over the next 5 years and it becomes fairly apparent that Open Source desktops will over take closed source desktops in most metrics.
especially if we maintain the current rate of development effort growth.
> The only remaining hurdle is IPC, which itself
> is covered by scheme/MIME
no, that's covered by whatever will end up being DCOP+1, which currently seems to be a future version of DBUS.
XML is generally too slow and is unnecessary for most IPC. for the cases where it does make sense, we already have RFCs for that such as XMLRPC and SOAP.
> ipc://mozilla@localhost/javascript:%20resizeTo(20 0,400)
dcop konqueror konqueror-mainwindow#1 resize 200 400
> will let the traditional unix "small tool that
> does one thing right" philosophy drive the
> complex apps that use it
we've been doing this in KDE for several years now. look at Kontact: it's the binding together of a handful of applications using IPC (DBUS, in specific) and an extensible plugin system. or look at Konqueror: it uses KParts to load embedded viewers for most common file types based on mimetype relationships to applications.
the more that other Open Source desktops adopt KDE technologies and techniques, the faster this will spread elsewhere. in the meantime, KDE works pretty well and we'll continue to blaze these trails further.
erm. who said anything about a registry? i appreciate your distaste for a registry, but KDE neither has one nor is planning making such a thing a central point of configuration. so... yeah. chill =)
> Desktop interop is important for the community
;) then you'd realize how we kind of cocked up with the mimetype spec.
> so we can have a critical mass of software
> consumers for our community of software
> developers
i couldn't agree more. which is why when creating new "standards" we need to do so in a way that makes it as straight forward as possible to get the implemented. the mimetype spec really dropped the ball on that one. this is not a KDE problem, but it was a bit of a learning experience between all the software projects involved in perhaps how not to create specs.
you said earlier that it's not about perfection, it's about pragmatism. and i'd agree.
if the mimetype spec had been pragmatic, it would've documented the existing working systems, of which KDE probably was the definitive example of such a thing. instead, it was written as a new development concept. this may make something better, but it takes longer. if you value pragmatism over perfection (personally, i'd like to see a dash of both
it'll get sorted out eventually, and i think we're all learning from that experience.
lol .. the "quantity over quality" stand. hehe.
> Interesting discussion on dot.kde.org, by the way
anything in particular there that caught your interest?
it requires striking a ballance. QA is dead simple if there are no options and few features. but then you have software almost nobody will want to, or even be able to use in the real world. so you add some features, some configuration ... at the cost of QA overhead. but you get useful software.
... we're engaged in an ongoing search to find that ballance in KDE, and i think we're finally getting some good formulas together. KDE 3.x is used by enough people who really enjoy it that i don't think it's fair to call it "unusable", but it can be improved upon (it always can ;). and so we continue to make new releases.....
.... personally, i'd take a file dialog like KDE's even if it meant having to put up with some annoying config dialogs elsewhere. it's items like file dialogs which provide most of the "usability" in a desktop.
ballance.
it's similar with the other items you list (bug fixing, integration, etc), though QA is hit harder than them. the "finding the options" problem is more a limitation of how we enforce hierarchical navigation of these things more than having a sane number of options. because even a sane number of options quickly spirals out of range of these mechanisms.
so
in his FOSDEM interview, Matthias Ettrich (the project's founder) was asked what three things he'd like to focus on in KDE 4 and he said: usability, usability, usability. good answer.
of course, usability is about a LOT more than ensuring there are only N options in an app, or that the menus are correctly arranged. those are important steps, but let's not get obsessive over details that are only part of the picture, something i see a lot of people do, sadly.
for instance, i find it interesting that for being such a central piece of UI, the file dialog is rarely considered by usability "enthusiasts". take the KDE file dialog and compare it to other Open Source toolkit file dialogs
but then... i use my systems to get real world work done and so these sorts of things actually matter to me. =)