There was a time when most everyone was really trying hard to close the interoperability gaps between different Free software stacks, and freedesktop.org was one place to achieve that. People were engaged in creating improvements for things that weren't as good as they should be and sharing the results between projects so that our users not only got improvements, but got to enjoy those improvements in all their Free software applications. Those days seem to be receding into the past however as GNOME seems increasingly content to "do their own thing". It's like they have lost sight of the goal of a coherent experience for users of Free software regardless of the applications they choose to use.
The decision by GNOME to not adopt what Canonical calls "appindicators" and what we (and the specification that was brought to freedesktop.org) refers to as "status notifiers" is a perfect demonstration of the problem. Sadly, it isn't the only one, but since Dave brought it up, let's examine this particular case.
The reason for creating status notifiers, and why Canonical built their appindicator library on top of that technology, was because, quite simply, the XEmbed based system tray icons were broken. They did not lend themselves to a modern presentation, failed to provide a compelling answer for mobile/tablet/netbook form factors and lacked any mechanism to communicate vital metadata to the host visualization. I won't go into all the technical details here (others have covered them elsewhere in the past), but suffice it to say that the old XEmbed system was increasingly becoming a blocker and status notifiers were a big step in a better direction. When we started work on them, it was our goal for the very start to make them attractive to and useful for others so that we didn't accidentally create a "separate silo" technology.
As a result of our work and outreach, Canonical agreed that there was value in the technology and picked up the technology, adding things like menus-via-D-Bus to it. Other projects such as GLX (previous Cairo) Dock followed suit and also added support for them.
In contrast, GNOME went in their own direction, even mentoring a Google Summer of Code project to create something unique to gnome-shell. Dave offers the following reasons for passing on libappindicator:
- "it doesn’t integrate with gnome-shell": this is a tautology; it doesn't integrate with gnome-shell because GNOME didn't pick up the technology. If GNOME had, gnome-shell would have gained support for it and it would have integrated with gnome-shell.
- "probably depends on GtkApplication, and would need integration in GTK+ itself": the answer to this one is simple: fix it. The core of the technology isn't "a GtkApplication dependent mechanism", so this should be addressable .. but again, would likely require GNOME identifying the value in and adopting the technology.
- "we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen": I can't speak for the GNOME / libappindicator dev collaboration efforts, but KDE Plasma devs have been working with libappindicator devs for some time now. We don't always agree, but we do tend to get things done and share efforts along the way. In addition, there was a lot of communication about Status Notifiers on the freedesktop.org xdg list where good feedback was offered and the specification improved significantly as a result. So communication really can't be to blame here, at least not communication by those outside of GNOME.
- "there’s nothing in GNOME needing it": this depends on how you define "need". It's true that one can certainly build a desktop application or a desktop shell without Status Notifiers / app indicators. One can even build one without a system tray / notification area at all! One doesn't need D-Bus either, or any other number of technologies. But they improve the user experience. In this case, it is a significant improve on what was there before. Also significant is that adopting the technology would draw together GNOME apps/shells and non-GNOME apps/shells to the betterment of all our users.
Other objections given in the past, such as "there's no mechanism for publishing menus using D-Bus" or specific nits about the StatusNotifier spec have been resolved one by one as those who adopted the technology worked together to improve it so it met all of our needs. Unfortunately, GNOME wasn't one of those participants and even as these issues have been sorted out they remain uninvolved and apparently uninterested.
Why do I care, or perhaps more importantly: why should you care? Well, this has become a pattern of behavior that we're seeing more often and it runs directly counter to the idea of a Free software desktop platform where applications are highly interoperable. It is indeed not incumbent upon any project, be it GNOME, KDE or any other to adopt every single technology on offer. However, it is in all our best interests to work together more rather than less and to share what makes sense, even if sometimes it means some short term compromise. KDE has made that decision many times even in recent times as we adopted various technologies such as D-Bus, shared mimetypes, shared icon theme definitions, etc. It's taken a lot of effort on our part and at times we've had to make some compromises, but our users have been reaping the benefits.
So while I personally think it is certainly acceptable for GNOME to elect not to get on board with Status Notifiers / appindicators (or other things, like a shared job D-Bus spec, or usage metadata for freedesktop.org specs, or ..), I do think it is unfortunate, particularly as this is not a recent development but an apparent longer term trend. Moreover, I don't buy the rationalizations offered in blogs such as Dave's and I don't think you should either. I feel that users of Free software should be aware of the decisions being made and the consequences of them with all the facts on the table.
If you, as a Free software user and/or contributor, care about a coherent experience in which applications, regardless of the toolkit or team behind them, not only merely work but work well together to provide a powerful and seamless experience, then you may want to be selective in which projects you support with your time, effort and usage. Supporting teams that are open and collaborative will ensure that the future of Free software is open and collaborative; supporting teams that are more intent on going it on their own will ensure a future with more fragmentation and wasteful duplication of effort. If projects lose support when they are less collaborative, that will be a strong incentive for such communities to reassess their priorities.
While diversity is great, incoherence is not. It's up to us to support the kind of future we want by voting with our feet.
(.. and yes, I am fully aware that the content of this blog entry is potentially incendiary; but it needs to be said and I've waited a long time for someone else to say it. In the end, I'd rather be flamed to death if free software benefits in the process rather than sit quietly in comfort while we pull the roof down upon our own heads.)