5 ms·

Analysis of the conflict among Canonical, GNOME, and KDE

69 points by sciurus 16y ago

gord 16y ago
These problems might take forever to solve [as the organisations are large]... In the meantime, I wouldn't be surprised if someone came up with a better technology model as a replacement. Id like to see a desktop development model more like modern web development - UI in HTML5/javascript/SVG, json data messaging, UI & system events coming from a port [eg. shinetech/eventserver], able to write small server-like plugins in Node.js / C / Ruby / lisp that can provide services and be remoted away from the UI. Would be nice if some of this was reusable across OSX/Win/Linux. Perhaps my desktop work should be done in the browser? The old unix guys might have approached it this way if they had the current web at hand to reuse/augment/embellish upon. Maybe this is more in the true spirit of unix than QT/GTK/Xwindows?
- sjs 16y ago
  OS-wide user scripts and bookmarklets? Sounds good to me.
- gord 16y ago
  Can anyone point me to a good architecture/dev overview of Gnome Shell and Unity ? I find it hard to sift out the marketing from the tech in what Ive seen.
  - sciurus 16y ago
    Unity is a plugin for the compiz window manager. https://lwn.net/Articles/430686/ https://lwn.net/Articles/430686/ https://wiki.ubuntu.com/Unity https://wiki.ubuntu.com/Unity https://wiki.ubuntu.com/Unity?action=AttachFile&do=get&target=Unity_Architecture.pdf https://wiki.ubuntu.com/Unity?action=AttachFile&do=get&#...
    - gord 16y ago
      thx, I do trust LWN to give us the gist.
  - beantree 16y ago
    GNOME Shell is the window manager (and some would argue a little bit more) for GNOME3. The GNOME wiki is a good place to start. A mostly up-to-date design overview is available at https://live.gnome.org/GnomeShell/Design/ https://live.gnome.org/GnomeShell/Design/ A technical overview can be found at Owen Taylor's blog http://blog.fishsoup.net/2008/10/22/implementing-the-next-gnome-shell/ http://blog.fishsoup.net/2008/10/22/implementing-the-next-gn... It's old, from when the shell was just being planned, but all the major architectural decisions are there.
- pavlov 16y ago
  Id like to see a desktop development model more like modern web development - UI in HTML5/javascript/SVG, json data messaging, UI & system events coming from a port [eg. shinetech/eventserver], able to write small server-like plugins in Node.js / C / Ruby / lisp that can provide services and be remoted away from the UI. Sounds a lot like HP webOS (originally developed by Palm). They even include Node.js for non-GUI services.
- drdaeman 16y ago
  > UI in HTML5/javascript/SVG I really hope this won't happen anytime soon. While everything's possible, HTML+CSS is a really horrible choice for UI description, and the whole webapp stuf is a kludge. Webapps are only done this way because there's no other choice. Developers are running away to more higher-level abstractions, which provide things that are completely missing in bare HTML+CSS. For example, there are so-called layout managers, which are at the core of every sane widget toolkit, but in HTML world, are only emulated with plugins like jQuery.UI.Layout (or implemented it pure HTML+CSS by re-inventing lots of boilerplate code). Cappuccino and SproutCore have a very good reason behind them.
  - gord 16y ago
    I [obviously] disagree.. while HTML DOM may be a mess, I think SVG + Javascript is a really nice way to do UI. The pain is almost all in the area of browser compatibility. I kind of agree with your point, in that I think there is a layer missing [ eg. to make resizable UI work well ]. But I think that layer is best implemented in Javascript upon SVG/DOM. As a comparison : I've used XCode's Interface Builder, and then thrown it away and written iOS UI Layouts by hand, and apparently Im not alone in this. Then I compare that to how much less code I'd need to write in Javascript for the same UI. [ I have implemented HTML5+js UI for iPad that looks like native Cocoa] Dont get me wrong, I think Cocoa is a good traditional API. But compared to SVG+js APIs such as Cocoa/QT/GTK feel incredibly verbose, slow to iterate and brittle, IMO.
    - drdaeman 16y ago
      > But I think that layer is best implemented in Javascript upon SVG/DOM. Could you, please, elaborate on this choice? Why not, for example, Tcl/Tk? For a simple example, take a look at http://www.tkdocs.com/tutorial/firstexample.html http://www.tkdocs.com/tutorial/firstexample.html. I doubt it would be simpler in any combination of HTML+CSS+SVG+JS (and, for example, it would be problematic to have system-wide look-and-feel)
- beantree 16y ago
  With GTK+3 and GNOME3, there is a push towards a development model like you've described. GNOME Shell's UI is written in Javascript, the core is written in C. Themes are done in a CSS-alike language. DBUS (a cross-desktop standard that works in both KDE and GNOME) provides data messaging and your "UI & system events coming from a port." This allows daemons (your "server-like plugins") to communicate across programs, share data, UI elements, and whatever else you feel like communicating between processes. One of the most important changes is the gobject-introspection work, which allows library authors to annotate their library's API in a way that allows bindings to be automatically created for any language. This is how GNOME Shell is able to use Javascript to call into GTK+3. Developers wanting to develop for GTK+ in their favorite language, be it Ruby, Python, Lisp, C#, D, or anything else, don't have to write bindings themselves or wait for someone else to write them. Many new GNOME applications and libraries are being written in Vala, a language with an object model based on GObject but a syntax like C#. It offers a modern language with garbage collection, and everything compiles down to C in the end. The same compiler can also compile a language called Genie, which is designed to have a syntax similar to Python (although, in my opinion, it hasn't done a great job at that yet, and I've seen no use of the language in the wild). It also compiles down to C. Tensions are high in the FOSS desktop world right now but that's nothing new. Flare ups like this come and go. Sometimes the problems are fixed and we find new ones to argue about a few years down the line. Sometimes the wounds fester, become gangrenous, and people leave for good. Most of us just want to write code we can use and have fun writing.
jdp23 16y ago
Great post. Excellent TL;DR summary, and well-articulated details on each point. Hard feelings and lack of communication between competing UNIX desktop environments ... where have I heard this before?
mycroftiv 16y ago
Posts like these really show the problems in the current free software development world; balkanization between different stakeholders and bizarre processes that alternate between bureaucracy and anarchy. Watching the tug-of-war between Red Hat and Canonical play itself out in the form of dysfunctional community development process is depressing. I'm aware that watching sausage being made never makes you very hungry, but as a user of free software, I don't feel my needs are served very well by the territorial and political battles being fought. What makes it even more frustrating to me is that not only are KDE, Gnome 3, and Unity all failing to cooperate successfully on shared resources, but they are all marching resolutely in the wrong direction, regardless of the pleas of the user community. So far as I can tell, everyone hates Gnome Shell, everyone hates Ubuntu Unity, and everyone thinks that KDE 4 has been a big mess compared to KDE 3. I see all of these projects as engaging in a slappy fight as they march together off the cliff of unusability and misguided redesigns.
- fingerprinter 16y ago
  I think to be fair to all three, you have to give them six months after they are actually released before we judge them. As is typical in OS Linux community, a very vocal minority is probably speaking up and "hating" all three. I would wager that the majority opinion is much different than what you hear from the vocal minority.
  - bobbyi 16y ago
    KDE 4 was released in January 2008.
- deleted 16y ago
  [deleted]
- joebananas 16y ago
  Free software have always been as much about drama as about making stuff. Emacs, XFree86 and NetBSD are just a few earlier examples.
- dman 16y ago
  Democracy is inefficient.
dillon 16y ago
It's so sad that such great ideas are just so dysfunctional.
- jpr 16y ago
  What is the great idea are you referring to? (not trolling, I honestly don't know what it is that you mean)
  - dillon 16y ago
    The idea of free software. It's a vision the Open Source community has that all software should be free.
- deleted 16y ago
  [deleted]
acabal 16y ago
I'm interested to see how this ends up being resolved (I use Ubuntu, don't like Unity, and Gnome Shell looks to be just as bad) but have only been half-following this drama. This is a really great summary post. I'm totally unsurprised that Shuttleworth's penchant for decision by fiat and Jobsian cargo-cultishness has driven a wedge between his company and others in the FOSS movement. (For example window controls, before windicators were announced: "Yesterday I decided to move window controls to the other side for our LTS. It's for a secret project. DO NOT ASK ME WHAT THE PROJECT IS."). But I'm also unsurprised that disorganization and what also appears to be at least a little ego and maybe even jealousy has warped things on the other side as well.
tytso 16y ago
The key problem is that the desktop community desperately needs one or more architects who can act as a sheepdog and keep the sheep marching in roughly the same direction. It's far more critical in the Desktop world than in the Linux kernel because in the kernel, there is enough development in the kernel that there is strong incentive to develop in the upstream sources, and not behind distribution-specific source trees. In addition, the Linux kernel releases on a regular 3 month cycle. So even if we don't have formal design documents, it's a lot easier for collaboration between key kernel subsystem developers, because our patches have to come together and _work_ every three months when we push out a release. (In practice, they had better mostly work by the end of the two week merge window, or there will be hell to pay, and Linus, as the great benevolent dictator, will yell at people, and Make a Decision --- which will usually involve reverting the change which broke things functionally.) In contrast, the Desktop world has a much harder problem, because (a) not everything lives in one source tree, (b) the kernel largely doesn't have a UI, and there are objective measures of "does it work", and "did the benchmark results go up or down", that either don't exist or aren't as important in the UI world. Questions of whether a UI is "good" or "better" than some other UI choice is a question which can't be easily answered objectively. And that, more than any thing else, is probably why we have three major design centers for desktop development: GNOME, KDE, and Canonical. One of the things that worries me is that all too often, people look at the way things are done in the Linux kernel, and assume that it will port over to their project. In most cases, the Linux kernel is a much larger and more complex project, and things which we do in the Linux kernel world probably aren't needed in other projects. But in the Desktop world, I think the reverse problem is true. It's a much larger and more complicated ecosystem than what we have in the Linux kernel, and so decisions such as allowing the major subsystem developers to negotiate major technical changes organically and informally might work for Linux, but not in the desktop world. (For example, in the storage stack, there are less than a half-dozen people I would need to consult with in order to come consensus about some change to accomodate PCI-attached flash, and we have multiple opportunities a year to get together and work things out). Hence in the desktop world, hiring a full-time architect who did nothing else but talk to the different stakeholders and try to come to consensus on a common vision is probably something which is necessary, even though we haven't found the need to have someone in that role in the Linux development community.
fingerprinter 16y ago
"My understanding of GNOME is this: GNOME does not have technical leadership – it hasn’t had clear technical leadership since, as I understand it, the creation of the GNOME Foundation (at which point, by design, the board was given a mandate to build and define GNOME, and then soon afterwards removed that mandate from itself). The foundation does not now dictate any vision or direction for GNOME." This is a huge problem, as I see it. Even in OSS, where you have very capable people, someone needs to provide direction. I'm reminded of a military story, which I will paraphrase. Single most important thing in warfare is to have a known objective. That way if the person in charge is killed, as is the second in charge, the troops still know they need to take that hill or everyone dies. I take the same approach to software and it has worked my entire career. If Gnome doesn't have a stated vision/objective, it is no wonder it looks like chaos to someone outside! Someone from Gnome _should_ step-up and provide some leadership, some technical direction, some market direction or some general foresight that things are going in the right direction. I hope the author is wrong and there is someone already doing this, but if not...
mpyne 16y ago
As a KDE developer myself, I have to admit to being very disappointed by the very first section regarding the development of the StatusNotifier specification. Dave complains that there was no problem statement, points out a quote relating to D-Bus, and somehow still entirely misses the point even after claiming to have read through the threads relating to the proposed spec. The problem statement is easy: Have a way of separating notification items and applications, such that the notification item is part of the desktop and not part of the application. In other words, XEmbed sucks as a way to have notification items in a system tray. Anyone who has ever used e.g. GAIM in a KDE 3.5 desktop with a pixmap background knows exactly what I'm talking about, as GAIM's icon would show up as an ugly box with an icon inside, while the KDE application's would have a notification item with a properly transparent icon drawn. Claiming that the entire idea was merely to hook up notifications into D-Bus is so far afield that it mystifies me completely, and claiming that no one has ever had issues because of this is patently false. In fact, the VERY EMAIL [1] that Dave quotes has an actual problem statement directly before it: <quote> In the past few months in KDE we worked on a new way to represent the systemtray icons to overcome the following limitations: -lack of communication between the systemtray area and the items, that mean we don't know about their status, their importance of if they are being used or not -the xembed process is quite slow and doesn't give control to the systray on the paining -it's not possible to have more than one systray (useful in multi monitor setups) </quote> I know this because I actually bothered to use GTK+ and GNOME software even with my KDE desktop, but now I wonder if Dave has ever tried the opposite. I also was passively watching the threads as they happened back in the day, and stating that there was disagreement due simply to lack of a problem statement would be flatly false. Dave then goes on to accuse Aaron Seigo and Marco Martin of being obstinate in their positions by that point, which simply does not mesh at all with my memory of things. For instance, A GNOME Panel hacker named Frederic Peters mentioned that it would be nice to be able to merge launchers with notification icons [2], an idea that was warmly received, not thrown out [3]. In addition, given that the implementation changed several times during just the KDE implementation period, there would have been no major problems with even incompatible changes to fix problems. For instance Aaron Seigo in reply to Dan Winship recommending a different way to send notification signals over D-Bus mentioned: "yes, this is a nice idea for limiting the bus traffic. would require an incompatible change to the spec, but it is doable." [4] I'll read the rest of the article, but if this is the kind of "uncontroversial" fact stating that's going to be going on then I'll probably just unsubscribe from the xdg list and get on with my KDE developing life... [1] http://lists.freedesktop.org/archives/xdg/2009-September/011038.html http://lists.freedesktop.org/archives/xdg/2009-September/011... [2] http://lists.freedesktop.org/archives/xdg/2009-September/011072.html http://lists.freedesktop.org/archives/xdg/2009-September/011... [3] http://lists.freedesktop.org/archives/xdg/2009-September/011073.html http://lists.freedesktop.org/archives/xdg/2009-September/011... [4] http://lists.freedesktop.org/archives/xdg/2010-January/011229.html http://lists.freedesktop.org/archives/xdg/2010-January/01122...
cgranade 16y ago
I'm surprised that no one here has yet pointed out that posts like this are a part of the self-correction mechanism present in transparent communities. Sure, it may be drama in the short term, but I think the fact that we know about these altercations is an important thing in and of itself. I would be highly surprised if this kind of drama didn't occur in the proprietary software world, but we don't get to see it and learn from it.

69 points by sciurus 16y ago

gord 16y ago

These problems might take forever to solve [as the organisations are large]... In the meantime, I wouldn't be surprised if someone came up with a better technology model as a replacement. Id like to see a desktop development model more like modern web development - UI in HTML5/javascript/SVG, json data messaging, UI & system events coming from a port [eg. shinetech/eventserver], able to write small server-like plugins in Node.js / C / Ruby / lisp that can provide services and be remoted away from the UI. Would be nice if some of this was reusable across OSX/Win/Linux. Perhaps my desktop work should be done in the browser? The old unix guys might have approached it this way if they had the current web at hand to reuse/augment/embellish upon. Maybe this is more in the true spirit of unix than QT/GTK/Xwindows?

sjs 16y ago
OS-wide user scripts and bookmarklets? Sounds good to me.
gord 16y ago
Can anyone point me to a good architecture/dev overview of Gnome Shell and Unity ? I find it hard to sift out the marketing from the tech in what Ive seen.
- sciurus 16y ago
  Unity is a plugin for the compiz window manager. https://lwn.net/Articles/430686/ https://lwn.net/Articles/430686/ https://wiki.ubuntu.com/Unity https://wiki.ubuntu.com/Unity https://wiki.ubuntu.com/Unity?action=AttachFile&do=get&target=Unity_Architecture.pdf https://wiki.ubuntu.com/Unity?action=AttachFile&do=get&#...
  - gord 16y ago
    thx, I do trust LWN to give us the gist.
- beantree 16y ago
  GNOME Shell is the window manager (and some would argue a little bit more) for GNOME3. The GNOME wiki is a good place to start. A mostly up-to-date design overview is available at https://live.gnome.org/GnomeShell/Design/ https://live.gnome.org/GnomeShell/Design/ A technical overview can be found at Owen Taylor's blog http://blog.fishsoup.net/2008/10/22/implementing-the-next-gnome-shell/ http://blog.fishsoup.net/2008/10/22/implementing-the-next-gn... It's old, from when the shell was just being planned, but all the major architectural decisions are there.
pavlov 16y ago
Id like to see a desktop development model more like modern web development - UI in HTML5/javascript/SVG, json data messaging, UI & system events coming from a port [eg. shinetech/eventserver], able to write small server-like plugins in Node.js / C / Ruby / lisp that can provide services and be remoted away from the UI. Sounds a lot like HP webOS (originally developed by Palm). They even include Node.js for non-GUI services.
drdaeman 16y ago
> UI in HTML5/javascript/SVG I really hope this won't happen anytime soon. While everything's possible, HTML+CSS is a really horrible choice for UI description, and the whole webapp stuf is a kludge. Webapps are only done this way because there's no other choice. Developers are running away to more higher-level abstractions, which provide things that are completely missing in bare HTML+CSS. For example, there are so-called layout managers, which are at the core of every sane widget toolkit, but in HTML world, are only emulated with plugins like jQuery.UI.Layout (or implemented it pure HTML+CSS by re-inventing lots of boilerplate code). Cappuccino and SproutCore have a very good reason behind them.
- gord 16y ago
  I [obviously] disagree.. while HTML DOM may be a mess, I think SVG + Javascript is a really nice way to do UI. The pain is almost all in the area of browser compatibility. I kind of agree with your point, in that I think there is a layer missing [ eg. to make resizable UI work well ]. But I think that layer is best implemented in Javascript upon SVG/DOM. As a comparison : I've used XCode's Interface Builder, and then thrown it away and written iOS UI Layouts by hand, and apparently Im not alone in this. Then I compare that to how much less code I'd need to write in Javascript for the same UI. [ I have implemented HTML5+js UI for iPad that looks like native Cocoa] Dont get me wrong, I think Cocoa is a good traditional API. But compared to SVG+js APIs such as Cocoa/QT/GTK feel incredibly verbose, slow to iterate and brittle, IMO.
  - drdaeman 16y ago
    > But I think that layer is best implemented in Javascript upon SVG/DOM. Could you, please, elaborate on this choice? Why not, for example, Tcl/Tk? For a simple example, take a look at http://www.tkdocs.com/tutorial/firstexample.html http://www.tkdocs.com/tutorial/firstexample.html. I doubt it would be simpler in any combination of HTML+CSS+SVG+JS (and, for example, it would be problematic to have system-wide look-and-feel)
beantree 16y ago
With GTK+3 and GNOME3, there is a push towards a development model like you've described. GNOME Shell's UI is written in Javascript, the core is written in C. Themes are done in a CSS-alike language. DBUS (a cross-desktop standard that works in both KDE and GNOME) provides data messaging and your "UI & system events coming from a port." This allows daemons (your "server-like plugins") to communicate across programs, share data, UI elements, and whatever else you feel like communicating between processes. One of the most important changes is the gobject-introspection work, which allows library authors to annotate their library's API in a way that allows bindings to be automatically created for any language. This is how GNOME Shell is able to use Javascript to call into GTK+3. Developers wanting to develop for GTK+ in their favorite language, be it Ruby, Python, Lisp, C#, D, or anything else, don't have to write bindings themselves or wait for someone else to write them. Many new GNOME applications and libraries are being written in Vala, a language with an object model based on GObject but a syntax like C#. It offers a modern language with garbage collection, and everything compiles down to C in the end. The same compiler can also compile a language called Genie, which is designed to have a syntax similar to Python (although, in my opinion, it hasn't done a great job at that yet, and I've seen no use of the language in the wild). It also compiles down to C. Tensions are high in the FOSS desktop world right now but that's nothing new. Flare ups like this come and go. Sometimes the problems are fixed and we find new ones to argue about a few years down the line. Sometimes the wounds fester, become gangrenous, and people leave for good. Most of us just want to write code we can use and have fun writing.

jdp23 16y ago

Great post. Excellent TL;DR summary, and well-articulated details on each point. Hard feelings and lack of communication between competing UNIX desktop environments ... where have I heard this before?

mycroftiv 16y ago

Posts like these really show the problems in the current free software development world; balkanization between different stakeholders and bizarre processes that alternate between bureaucracy and anarchy. Watching the tug-of-war between Red Hat and Canonical play itself out in the form of dysfunctional community development process is depressing. I'm aware that watching sausage being made never makes you very hungry, but as a user of free software, I don't feel my needs are served very well by the territorial and political battles being fought. What makes it even more frustrating to me is that not only are KDE, Gnome 3, and Unity all failing to cooperate successfully on shared resources, but they are all marching resolutely in the wrong direction, regardless of the pleas of the user community. So far as I can tell, everyone hates Gnome Shell, everyone hates Ubuntu Unity, and everyone thinks that KDE 4 has been a big mess compared to KDE 3. I see all of these projects as engaging in a slappy fight as they march together off the cliff of unusability and misguided redesigns.

fingerprinter 16y ago
I think to be fair to all three, you have to give them six months after they are actually released before we judge them. As is typical in OS Linux community, a very vocal minority is probably speaking up and "hating" all three. I would wager that the majority opinion is much different than what you hear from the vocal minority.
- bobbyi 16y ago
  KDE 4 was released in January 2008.
deleted 16y ago
[deleted]
joebananas 16y ago
Free software have always been as much about drama as about making stuff. Emacs, XFree86 and NetBSD are just a few earlier examples.
dman 16y ago
Democracy is inefficient.

dillon 16y ago

It's so sad that such great ideas are just so dysfunctional.

jpr 16y ago
What is the great idea are you referring to? (not trolling, I honestly don't know what it is that you mean)
- dillon 16y ago
  The idea of free software. It's a vision the Open Source community has that all software should be free.
deleted 16y ago
[deleted]

acabal 16y ago

I'm interested to see how this ends up being resolved (I use Ubuntu, don't like Unity, and Gnome Shell looks to be just as bad) but have only been half-following this drama. This is a really great summary post. I'm totally unsurprised that Shuttleworth's penchant for decision by fiat and Jobsian cargo-cultishness has driven a wedge between his company and others in the FOSS movement. (For example window controls, before windicators were announced: "Yesterday I decided to move window controls to the other side for our LTS. It's for a secret project. DO NOT ASK ME WHAT THE PROJECT IS."). But I'm also unsurprised that disorganization and what also appears to be at least a little ego and maybe even jealousy has warped things on the other side as well.

tytso 16y ago

The key problem is that the desktop community desperately needs one or more architects who can act as a sheepdog and keep the sheep marching in roughly the same direction. It's far more critical in the Desktop world than in the Linux kernel because in the kernel, there is enough development in the kernel that there is strong incentive to develop in the upstream sources, and not behind distribution-specific source trees. In addition, the Linux kernel releases on a regular 3 month cycle. So even if we don't have formal design documents, it's a lot easier for collaboration between key kernel subsystem developers, because our patches have to come together and _work_ every three months when we push out a release. (In practice, they had better mostly work by the end of the two week merge window, or there will be hell to pay, and Linus, as the great benevolent dictator, will yell at people, and Make a Decision --- which will usually involve reverting the change which broke things functionally.) In contrast, the Desktop world has a much harder problem, because (a) not everything lives in one source tree, (b) the kernel largely doesn't have a UI, and there are objective measures of "does it work", and "did the benchmark results go up or down", that either don't exist or aren't as important in the UI world. Questions of whether a UI is "good" or "better" than some other UI choice is a question which can't be easily answered objectively. And that, more than any thing else, is probably why we have three major design centers for desktop development: GNOME, KDE, and Canonical. One of the things that worries me is that all too often, people look at the way things are done in the Linux kernel, and assume that it will port over to their project. In most cases, the Linux kernel is a much larger and more complex project, and things which we do in the Linux kernel world probably aren't needed in other projects. But in the Desktop world, I think the reverse problem is true. It's a much larger and more complicated ecosystem than what we have in the Linux kernel, and so decisions such as allowing the major subsystem developers to negotiate major technical changes organically and informally might work for Linux, but not in the desktop world. (For example, in the storage stack, there are less than a half-dozen people I would need to consult with in order to come consensus about some change to accomodate PCI-attached flash, and we have multiple opportunities a year to get together and work things out). Hence in the desktop world, hiring a full-time architect who did nothing else but talk to the different stakeholders and try to come to consensus on a common vision is probably something which is necessary, even though we haven't found the need to have someone in that role in the Linux development community.

fingerprinter 16y ago

"My understanding of GNOME is this: GNOME does not have technical leadership – it hasn’t had clear technical leadership since, as I understand it, the creation of the GNOME Foundation (at which point, by design, the board was given a mandate to build and define GNOME, and then soon afterwards removed that mandate from itself). The foundation does not now dictate any vision or direction for GNOME." This is a huge problem, as I see it. Even in OSS, where you have very capable people, someone needs to provide direction. I'm reminded of a military story, which I will paraphrase. Single most important thing in warfare is to have a known objective. That way if the person in charge is killed, as is the second in charge, the troops still know they need to take that hill or everyone dies. I take the same approach to software and it has worked my entire career. If Gnome doesn't have a stated vision/objective, it is no wonder it looks like chaos to someone outside! Someone from Gnome _should_ step-up and provide some leadership, some technical direction, some market direction or some general foresight that things are going in the right direction. I hope the author is wrong and there is someone already doing this, but if not...

mpyne 16y ago

As a KDE developer myself, I have to admit to being very disappointed by the very first section regarding the development of the StatusNotifier specification. Dave complains that there was no problem statement, points out a quote relating to D-Bus, and somehow still entirely misses the point even after claiming to have read through the threads relating to the proposed spec. The problem statement is easy: Have a way of separating notification items and applications, such that the notification item is part of the desktop and not part of the application. In other words, XEmbed sucks as a way to have notification items in a system tray. Anyone who has ever used e.g. GAIM in a KDE 3.5 desktop with a pixmap background knows exactly what I'm talking about, as GAIM's icon would show up as an ugly box with an icon inside, while the KDE application's would have a notification item with a properly transparent icon drawn. Claiming that the entire idea was merely to hook up notifications into D-Bus is so far afield that it mystifies me completely, and claiming that no one has ever had issues because of this is patently false. In fact, the VERY EMAIL [1] that Dave quotes has an actual problem statement directly before it: <quote> In the past few months in KDE we worked on a new way to represent the systemtray icons to overcome the following limitations: -lack of communication between the systemtray area and the items, that mean we don't know about their status, their importance of if they are being used or not -the xembed process is quite slow and doesn't give control to the systray on the paining -it's not possible to have more than one systray (useful in multi monitor setups) </quote> I know this because I actually bothered to use GTK+ and GNOME software even with my KDE desktop, but now I wonder if Dave has ever tried the opposite. I also was passively watching the threads as they happened back in the day, and stating that there was disagreement due simply to lack of a problem statement would be flatly false. Dave then goes on to accuse Aaron Seigo and Marco Martin of being obstinate in their positions by that point, which simply does not mesh at all with my memory of things. For instance, A GNOME Panel hacker named Frederic Peters mentioned that it would be nice to be able to merge launchers with notification icons [2], an idea that was warmly received, not thrown out [3]. In addition, given that the implementation changed several times during just the KDE implementation period, there would have been no major problems with even incompatible changes to fix problems. For instance Aaron Seigo in reply to Dan Winship recommending a different way to send notification signals over D-Bus mentioned: "yes, this is a nice idea for limiting the bus traffic. would require an incompatible change to the spec, but it is doable." [4] I'll read the rest of the article, but if this is the kind of "uncontroversial" fact stating that's going to be going on then I'll probably just unsubscribe from the xdg list and get on with my KDE developing life... [1] http://lists.freedesktop.org/archives/xdg/2009-September/011038.html http://lists.freedesktop.org/archives/xdg/2009-September/011... [2] http://lists.freedesktop.org/archives/xdg/2009-September/011072.html http://lists.freedesktop.org/archives/xdg/2009-September/011... [3] http://lists.freedesktop.org/archives/xdg/2009-September/011073.html http://lists.freedesktop.org/archives/xdg/2009-September/011... [4] http://lists.freedesktop.org/archives/xdg/2010-January/011229.html http://lists.freedesktop.org/archives/xdg/2010-January/01122...

cgranade 16y ago

I'm surprised that no one here has yet pointed out that posts like this are a part of the self-correction mechanism present in transparent communities. Sure, it may be drama in the short term, but I think the fact that we know about these altercations is an important thing in and of itself. I would be highly surprised if this kind of drama didn't occur in the proprietary software world, but we don't get to see it and learn from it.