Linked by Thom Holwerda on Thu 10th Mar 2011 12:59 UTC
Talk, Rumors, X Versus Y If you were, you know, living your lives, you've probably missed it, but old fires are burning brightly once again: there's somewhat of a falling-out going on between KDE and GNOME, with Canonical siding squarely with... KDE. The issue seems to revolve around GNOME's lack of collaboration, as explained by KDE's Aaron Seigo.
Thread beginning with comment 465714
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: lack... of... caring...
by molnarcs on Fri 11th Mar 2011 04:46 UTC in reply to "lack... of... caring..."
Member since:

I don't like Canonical, Unity, Appindicators or KDE and I don't care about anything they do.

In the end the desktop choices made by GNOME have suited me better than what everyone else has to offer.

Which has nothing to do with the issue at hand. UI design decisions (what you describe as "desktop choices" are NOT included in the spec. The only goal here is to make it easier for developers of ANY platform (QT, GTK, etc.) and every application to integrate into the YOUR DE of choice. Canonical/Unity, Compiz-dock and KDE adopted this spec (and GNOME was invited to do so) so that an app written in GTK would easily integrate into KDE, or a KDE app would behave like a native GNOME app (when it comes to notifications) on your GNOME desktop. It makes a lot of sense to cooperate on low-level APIs while keeping the presentation separate. A good example for such cooperation is KDE's adaptation of DBUS, even though their own DCOP framework was more advanced/mature at the time. Thanks to that, we get more consistent behaviour across applications written in various toolkits. This kind of collaboration is good for the overall F/LOSS ecosystem - it makes users as well as developers happy. The issue here is that GNOME dev's chronic NIH syndrome in the past few years sabotaged such attempts, diminishing the importance of, for example.

Again, this is not about design choices of individual desktops, this is about consistency among applications. Consistency here does not mean that applications will behave the same way across all desktops. We don't really want that now do we? You like GNOME and the way the GNOME desktop is designed, yes? Consistency here is within a particular desktop regardless of the framework used to develop the application. In case you ever need something written in QT or KDE, you don't want it to be an eyesore on your beautiful GNOME desktop - you want it to behave like any other GNOME application. That is precisely the goal of these low-level specs - make it easier for developers to separate data from its presentation, allowing better integration of apps written different frameworks.

Edited 2011-03-11 04:47 UTC

Reply Parent Score: 7