Analysis of the conflict among Canonical, GNOME, and KDE

"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...

> 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.

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:

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)

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/011... [2] http://lists.freedesktop.org/archives/xdg/2009-September/011... [3] http://lists.freedesktop.org/archives/xdg/2009-September/011... [4] http://lists.freedesktop.org/archives/xdg/2010-January/01122...

Unity is a plugin for the compiz window manager.

https://lwn.net/Articles/430686/ https://wiki.ubuntu.com/Unity https://wiki.ubuntu.com/Unity?action=AttachFile&do=get&#...

thx, I do trust LWN to give us the gist.