To read all comments associated with this story, please click here.
> stuff like OK dialog button order
there actually was a de facto standard for this before GNOME pulled a switch-a-roo for no measurable benefit other than to create a new area of inconsistency.
that said, KDE4 and Qt4 appications adapt their button order to the platform: KDE, Windows, Mac or GNOME. a technical solution to the problem, for sure, but it proves that its not only possible it works pretty well.
> The Linux Foundation should really work on these things.
as long as they work with the rest of the community. i'm a little concerne with this announcement that Shuttleworth is tap dancing to work but all by himself and to a tune he's not letting others listen to.
organizations like LF an Canonical can provide a lot of value, but if it's done without working with the rest of the community it's value wasted.
people working on the Linux kernel and other server side bits tend to understand that ... why it gets lost as soon as we hit the desktop? well, i have thoughts on that, but i'll keep them to myself for now =)
> And there is soo much tech duplication and NIH in Gnome and
> KDE.
there is a lot *less* "NIH" in kde4 than there was in kde3. in part this is because the rest of the ecosystem is maturing and gives us more options, in part its because the KDE project recognizes the value in using what is available.
as for strigi, we actually tend to go through Nepomuk these days and when strigi popped around there really weren't any good alternatives. "building what needs to be built" is not NIH.
moreover, Strigi is not tied to KDE in any way. (which actually makes things a bit harder for us at times..)
> Don't wait and hope the Guadec/Akademy double event next
> year will fix all those issues!
it won't. it's a step further down the right path, but it won't be a silver bullet event.
Thanks for the insightfull answer, Aaron.
there actually was a de facto standard for this before GNOME pulled a switch-a-roo for no measurable benefit other than to create a new area of inconsistency.
Yeah, I remember. And I wasn't blaming KDE
that said, KDE4 and Qt4 appications adapt their button order to the platform: KDE, Windows, Mac or GNOME. a technical solution to the problem, for sure, but it proves that its not only possible it works pretty well.
Yeah, that is probably the way to go. KDE adapts, because Gnome cannot/or is not willing to ;(
But in the end it will be a testament to KDE that they can swallow a little pride and do what is best for the free desktop, although they had most of the technologies first.
> The Linux Foundation should really work on these things.
as long as they work with the rest of the community. i'm a little concerne with this announcement that Shuttleworth is tap dancing to work but all by himself and to a tune he's not letting others listen to.
organizations like LF an Canonical can provide a lot of value, but if it's done without working with the rest of the community it's value wasted.
people working on the Linux kernel and other server side bits tend to understand that ... why it gets lost as soon as we hit the desktop? well, i have thoughts on that, but i'll keep them to myself for now =)
I think it is because Gnome has a lot of corporate people with an agenda working on it .. way more than KDE.
> And there is soo much tech duplication and NIH in Gnome and
> KDE.
there is a lot *less* "NIH" in kde4 than there was in kde3. in part this is because the rest of the ecosystem is maturing and gives us more options, in part its because the KDE project recognizes the value in using what is available.
as for strigi, we actually tend to go through Nepomuk these days and when strigi popped around there really weren't any good alternatives. "building what needs to be built" is not NIH.
moreover, Strigi is not tied to KDE in any way. (which actually makes things a bit harder for us at times..)
OK. I probably did not pick the best examples, but it just feels like there are lots of things that might work for both desktops.
At Guadec2008 someone promoted C++ for Gnome development. Maybe if they would adopt that it would keep them from reimplementing a lot of things KDE already did in C.
> Don't wait and hope the Guadec/Akademy double event next
> year will fix all those issues!
it won't. it's a step further down the right path, but it won't be a silver bullet event.
That would be sad ;(
But how? First, people have pointed out that Freedesktop.org is "just a website", not a standards body. To define a button order, both camps will have to come to an agreement. But both thinks that they're right and the other is wrong. What do you do then in such a situation?
By the way, GNOME's just following the Mac button order. And they've actually moved away from "Yes-No-Cancel" buttons a long time ago. GNOME apps usually use action verb buttons, e.g. "Cancel - Don't Save - Save", where the order doesn't matter as much. Usability studies have also shown that people scan the right bottom area of a dialog first, which is why they've chosen to put the most appropriate button there.
Just as an additional note on this topic:
the GNOME Keyring maintainer and the KWallet maintainer have already started to work on a unified solution, see https://bugs.freedesktop.org/show_bug.cgi?id=16581
The Linux Foundation should really work on these things.
The Linux Foundation could probably employ one or more of the Freedesktop.org sysadmins so they have the time to actually respond Free Software desktop developer needs within reasonable time.
Right now the latency between responses is measured in months, e.g. have a look at the link above
Not their fault, this is what their members are most interested in. Once more desktop oriented members join up, this will very likely shift.






Member since:
2006-01-04
.. what I would like to see is way more colaboration. Freedesktop should define stuff like OK dialog button order and password stores (Gnome has its keyring, KDE Kwallet and Mozilla has its own ;( ) etc.
And there is soo much tech duplication and NIH in Gnome and KDE. (Beagle, Tracker, Strigi etc .. the list goes on for ages)
The Linux Foundation should really work on these things. They seem really kernel fixated.
Don't wait and hope the Guadec/Akademy double event next year will fix all those issues!
But the recent advancements in Xorg development and this make the future a little bit brighter I guess.
Thanks Mark.