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.)
167 comments:
Hey Aaron,
do you think the Gnome my way or the high way attitude is connected to company agenda? (A lot of the Gnome3 decision makers work only for a very few companies)
BTW: Welcome to Europe!
@Tom: "do you think the Gnome my way or the high way attitude is connected to company agenda?"
i don't think so.
people involved with these f/oss projects tend to concentrate within specific companies, and that can give the illusion that corporate agenda plays a bigger role than it probably does.
but i've seen this attitude just as often with unaffiliated community contributors as with those employed by companies to work on the software.
it really seems to be something common to the culture of the project rather than the culture of the companies they work for.
Essentially to summarize your points; all the past work to get kde apps to work well in Gnome and vise versa, the Gnome folks are for the most part going to break all that.
If I am wrong on that it still seems as though the Gnome arena wants to erect walls around anything not Gnome.
Hmm. There's one thing that's been bugging me a lot in the past few years. As a user of both KDE and gnome apps, I run into the problem with file associations quite often. This is the most obvious break between KDE and gnome. Gnome apps love to use a vastly different set of apps for opening files. This *sucks*. No, I don't want to use a gtk based tag editor to open mp3 files from firefox. I want to open them in VLC. I don't want my pdf files to open in gimp. And my settings for opening files are never respected. What happened to xdg-open?
KDE has KIO, gnome has their own GVFS thing. Why? They do the same thing and only result is that opening files in gnome apps from dolphin is a multi-stage process where I have to copy things around, rename and find files squirreled away in temp folders.
Maybe one day, we'll have something sane. I'm not holding my breath though.
/rant
I actually read trough the freedesktop.org mailing list about this discussion after reading what Dave posted, and I think you were right in what you said there.
@Petr Mrázek: "I run into the problem with file associations quite often"
well, rejoice! as of quit recently, we now share a mimetype associations database so you can set these things once and _all_ apps respect those settings.
i know: about time, right? :)
"KDE has KIO, gnome has their own GVFS thing. Why?"
API. KIO and GVFS are quite honestly mutually uninteresting. as long as both respect and use common, standard URIs to point to files, then it doesn't matter one bit what library is used.
where this falls down in practice is the use of fancy access methods like fish:/ which are platform specific. standardizing those URLs would address that set of issues. it's a fairly niche concern, though, as most URIs are indeed the usual file:/, http://, ftp://, smb://, etc. sort.
Sadly, gnome developers are very close minded. Gnome is addressed for fanatics and fanboys not for typical users. The crap like gnome-shell, lack of minimize and close buttons etc. just proves this.
So Canonical isn't lying after all :-)
And who would that be? Oh wait it's obvious...
Hi Aaron,
Just to point out, I wasn't justifying the rejection - I was, in fact, copying & pasting directly from the release team decision. I realise now that wasn't clear, and have made it clearer.
I had hoped that the follow-on paragraph would make it clear that I thought there was some fault on both sides, and was disappointed none of the gnome-shell developers contributed to that discussion.
In fact, I found this article today, which summarises nicely the (public) happenings around libappindicator: http://www.advogato.org/person/mbanck/diary/48.html
Cheers,
Dave.
Well, GNOME adopts some specs and others they don't, depending on how things fit into the UX design they want to achieve. Much like KDE which adopts some specs and others they don't. If you list this notifier spec, then I can list you the sound theming/naming specs which KDE has shown no interest in. And that's fine. People have different priorities. And the same way I wouldn't complain about KDE not adopting the sound theming/naming specs you shouldn't be too upset about GNOME not caring too much about the notifier specs. There's really no essential difference in KDE's and GNOME's behaviour anywhere here.
@Dave Neary: yes, that wasn't completely clear indeed. thanks for the clarification. i do stand by what i wrote, however :)
@Lennart: "If you list this notifier spec, then I can list you the sound theming/naming specs which KDE has shown no interest in."
that's an incorrect comparison.
if we (KDE) had offered a bunch of critique on the sound theme spec, had someone come to us with an implementation in Qt and then still gone off and done our own thing instead, then it would be an adequate comparison. but that isn't what happened, is it? :)
we (KDE) simply haven't gotten around to implementing the sound theming spec. why? as you note, it's not a high priority for us. but i guarantee you that if someone stepped up to do some work on the event sounds infra in kdelibs, stop #1 would be that naming spec.
also, this is not an odd "oops, we just didn't get around to it" event on the part of GNOME: how's that job D-Bus implementation in GNOME 3 coming? you know, the one that needlessly duplicates the one KDE implements, which we actually designed with thought of cross-project use including getting some feedback from non-KDE devs? or how about the screensaver D-Bus API which we implemented specifically with collaboration with GNOME devs at SUSE, only later to have GNOME not implement it and then complain to us that it used the org.freedesktop namespace? or how about how GNOME devs specifically blocked the formation of a common git repository for fd.o specs, and then when there was finally agreement (after an in-person meeting) insist on implementing it themselves, ignoring that repo had already been started but by people with @kde.org email addresses, and then after taking months to eventually duplicate that effort not implement the most critical part of it: the metadata?
in contrast, we could see how KDE implemented support for the visual notificatons D-Bus protocol as implemented in GNOME, even though it has evident limitations and is a 100% subset of something we already have in the form of KNotify ... simply to provide compatibility. would GNOME devs do that today? doubtful, because our priorities, as you point out, are indeed different.
what GNOME needs is not more apologists making excuses for poor behavior but people who will stand up and take ownership of their actions.
Booom! Good luck GNOME/Red Hat!
Thanks for pointing out how the KDE community sees these issues. It's better to talk openly about it than mumble internally.
And let's try once more to fix these issues at Desktop Summit.
Thanks Aaron, it's a feeling I've had for a very long time but haven't felt qualified to comment on due to not being directly involved in the various efforts.
While we can easily tick off the things that KDE has compromised on for the sake of compatibility, I'm struggling to think of a single KDE originated technology or standard that Gnome has adopted. I know of a couple of shared efforts, but they very much seem to be down to individual devs getting on with it and not properly coordinated Gnome/KDE/fdo joint efforts. I can't recall the last time a Gnome dev approached the core KDE lists to discuss our requirements for some new desktop of system infrastructure they were working on, and reading back on the xdg list its been moribund for ages, yet we know Gnome are working on lots of this stuff in G3 and further down the stack.
One thing I've been concerned about for a while is how, while we strongly believe that we have have the best technology, we are so reluctant to push it onto other people. We create something great, then sit back and wait for people to appreciate and adopt it, only to see some inferior solution get adopted because they have pushier proponents. Perhaps it's time we stopped being the good guys, stopped compromising our vision and not only stand our ground but start aggressively pushing our platform.
You're criticising the reasons why libappindicator was not formally accepted into a GNOME release set in 2010, but mistaking them for reasons why GNOME developers did not engage in their development from 2008.
Knowing this won't change your conclusion substantially (being a belief you've held for some time), but it certainly does not support it.
@John: "Perhaps it's time we stopped being the good guys, stopped compromising our vision and not only stand our ground but start aggressively pushing our platform."
perhaps naively, i believe we can be "good guys" and spread our platform and technology. we do need to stand our ground a bit more and be less willing to accept mediocrity, but we can still be nice and good f/oss citizens while doing so :)
@Jeff Waugh: "You're criticising the reasons why libappindicator was not formally accepted into a GNOME release set in 2010, but mistaking them for reasons why GNOME developers did not engage in their development from 2008."
would you care to offer the reasons GHOME developers have not engaged, then?
"Knowing this won't change your conclusion substantially (being a belief you've held for some time),"
it's not a belief that GNOME has decided to not collaborate on this (and other) initiatives for no good reason: it's a fact. there is a demonstrated "if isn't invented here, it isn't used here" pattern of behavior.
and it's not something i realized at first, either, but only after quite a while. in fact, in this particular case i figured that Canonical providing a Gtk+ implementation and other projects adopting it would be a step in the right direction and was happily optimistic about having a widely adopted replacement for the old xembed systray icons.
so your assertion is wrong on both point:. i've been optimistic and GNOME has proven that optimism to be misplaced time and again with concrete actions that are publicly documented.
"but it certainly does not support it."
then offer substantive and meaningful insight that provides "the other side" to this story and i'm happy to alter my viewpoint.
i'm tired of apologetics, i'm sick of two-faced posturing and i don't have the patience for responses that lack content.
instead, offer some straight-shooting, reality based input and we will all be happy to move forward on these issues. it's what we, myself included, want.
would you care to offer the reasons GHOME developers have not engaged, then?
It was not relevant to GNOME in 2008. libappindicators was a Canonical adventure, and there was no interaction with upstream until 2010 when it was proposed for inclusion.
The reasons you list above were given two years after Canonical began their work in self-imposed isolation from GNOME.
The results of that approach to community engagement are hardly surprising.
How was it not relevant to gnome in 2008? There was an effort to make a new cross-desktop indicator specification, with the explicit goal that it would be used by all major lLnux desktop environments so they would be compatible with each other. I would think that would be very relevant to gnome.
How was it not relevant to gnome in 2008? There was an effort to make a new cross-desktop indicator specification
The KNotificationItem spec was first proposed in September 2009, then renamed and proposed again as the StatusNotifier spec in December 2009.
That said, there was a tiny discussion in September 2008 about a refreshed "Tray Icon" spec, based on a single post suggestion raised in March 2007. Both from GNOME developers, by the way.
@toddrme2178
I think important point is there is a 2 year gap of _discussion_ in the public record. 2 years with no public record..no back and forth..no feedback...and its going to be very difficult to synthesize any negative feelings constructive future.
It's really not unlike a marriage. If I held a grudge for two years against my spouse for not working in a consensus fashion with me over something important to both of us like say a major house renovation which was done in 2008...and I decided to stay silent about how I was treated until..2010 and then when I did speak I did so in an accusatory fashion. That is not be a healthy way for me to approach reconciliation with an eye towards strengthening the relationship moving forward. If anything it would only make things worse.
There are ways to bring up past actions and to express frustration objectively, but it must be done with care and a focus on bettering communication in the future when the relationship is valued.
@Jeff
"The reasons you list above were given two years after Canonical began their work in self-imposed isolation from GNOME."
Just a note - as far as we can see those are gnome developers who are isolating from FLOSS and even from its users. My favourite example is the new, crappy gnome shell. I remember when some of the gnome developers were criticizing Plasma, because it's too big change, it will confuse users etc. Now, the same people come up with the shit like gnome3 is which turned user experience by 180 degrees and cut off important functions to minimum. Some of you are even saying crap like this:
"It also makes me wonder if those complaining have ever tried GNOME Shell... As is adequately explained in this rationale, minimizing simply has no place in the concepts behind GNOME Shell. Period. And if you've tried GNOME Shell you would realize that."
There's some nice word which describes persons like this. And yes, many people already tried this, but you're deaf or close minded to hear or notice their complains.
@Jeff Waugh: the KDE Plasma team brought this spec to xdg@freedesktop.org and had open back-and-forth with GNOME devs. we patiently and collaboratively worked through input offered, including making requested changes to the spec, adding requested features, etc. to make it useful and workable for all, beyond just our own needs. we happily accepted improvements and additions from others, as well.
so the assertion that there was no interaction with upstream GNOME before 2010 is a half truth at best. it might describe the Canonical appindicator library implementation (i'll take your word for that), but it certainly doesn't address why GNOME has ignored the status notifier spec which was brought to GNOME via fd.o some time ago.
and as i've already noted, this is a pattern of behavior. we've witnessed it repeatedly in the last few years: if it doesn't come from within GNOME, good luck trying to get GNOME to adopt it. it doesn't matter if it is a better technology that addresses real shortcomings, if F/OSS users would benefit from the increased interoperability, etc.
as for being relevant in 2008, toddrme2178 hits that nail right on the head.
@Pawel: In my experience, actual GNOME contributors rarely talk about KDE at all, let alone publicly comment on KDE development strategy.
If anything, GNOME developers who experienced the 2.0 transition had an enormous amount of sympathy and understanding about the challenges the KDE team faced. Don't assume malice.
You may be confusing GNOME fans and users for developers, but that's an easy mistake to make on both sides.
GNOME is certainly a challenging project to work with, but it does not choose self-imposed isolation as a development strategy.
as for being relevant in 2008, toddrme2178 hits that nail right on the head.
Then you may wish to respond to (and perhaps contribute to) the timeline I offered in response.
@ Jef: That analogy would make sense if this was the first time these issues were brought up. But they aren't, this is just the most recent in a long line of such complaints.
This discussion reminded me how I miss dcop: controlling Amarok, popping up a notification over ssh to ask my sibling to kindly lower his bandwidth consumption, easy scripting..
Haven't done any of that since the switch to d-bus. Sure, there's probably a way to do all that and more, but dcop was easy and helpful, listing possible commands on the command line if prompted. And the commands were intuitive and short, nothing like d-bus. It was something I could use without having to google.
I've tried to keep track, but I can't name a single thing that GNOME has adopted from KDE that wasn't their own incompatible rewrite of an idea.
@toddrme2178: This issue is the basis for quite some friction in the GNOME community, and the basis for aseigo's public complaint. That he believes GNOME doesn't work well with KDE and fd.o in general is not news, but also not what I am responding to.
(And I don't fully agree or disagree with his charge... but then, I don't think GNOME's inability to satisfy aseigo's particular definition of cross-desktop collaboration is a dereliction of duty to the Free Software community, either.)
I hope all these problems could be solved in Berlin with the help of some beers :)
@Jeff Waugh: "Then you may wish to respond to (and perhaps contribute to) the timeline I offered in response. "
i did, specifically how my dev team brought the status notifier spec to xdg@fd.o and worked on it productively and in the open there with others.
GNOME may well pass on libappindicator, but it hardly provides any reason for passing on status notifiers as a whole. the reasons provided in Dave's blog just don't cut it.
@mongrelmuch: "This discussion reminded me how I miss dcop"
qdbus bridges the gap very nicely. it's a bit different from the dcop command line, but is easy enough to pick up and does essentially the same thing. i'd go nuts without it, for the same reasons you comment on :)
"I can't name a single thing that GNOME has adopted from KDE that wasn't their own incompatible rewrite of an idea. "
if we go back far enough to the early days of freedesktop.org, we can find a number of examples. but in the last 5-6 years (maybe longer by now?), what you describe is pretty accurate.
@toddrme2178
You know the drill... provide references to previous discussions.
There's been a lot of mumbling inside like-minded groups about other like-minded groups. I think Shuttleworth would call it..tribalism.
I am not discounting Aaron's frustration at all. Nor Shuttleworth's, nor anyone's.
I'm saying we are at the point were are at with the frustration level on all sides because people have been holding grudges for _too_ _long_ before confronting the specific behaviour they feel is problematic. Grudges have an expiration date as constructive motivation. After that point they are just sour, bitter recriminations.
How much of the current problems are past expiration grudges that have been propagated as memes via private communications among peers?
What is commonly understood to be true by many is not necessarily been expressed to those who need to hear when it was appropriate for it to be heard. If people really believe there is a culture of bad behaviour inside GNOME then those very same people need to start calling it out(respectively) as it happens so the specifics can be identified and addressed in the context of each particular instance.
bah
that should have been "respectfully" in my last post.
i did, specifically how my dev team brought the status notifier spec to xdg@fd.o and worked on it productively and in the open there with others.
In your previous reply, you did not reference the dates or links which would make your answer relevant to the timeline I provided.
Most relevant: At which point prior to 2008 did any of this happen?
@Aaron:
Thanks for the qdbus tip, I've just tried it, and had Amarok playing within a few commands, and without searching the docs!
Awesome. :D
@Jef Speleta: "I'm saying we are at the point were are at with the frustration level on all sides because people have been holding grudges for _too_ _long_ before confronting the specific behaviour they feel is problematic."
that may be true of some, but that really isn't my issue. i've been fairly consistently communicative about issues as they arise. if we wouldn't keep repeating the same patterns of behavior, i'd happily put it all in the past.
"If people really believe there is a culture of bad behaviour inside GNOME then those very same people need to start calling it out(respectively) as it happens so the specifics can be identified and addressed in the context of each particular instance."
and this is precisely what i have done here (and in the past on my blog, on xdg@, at f/oss conferences where i've had face time with GNOME devs, ...) and what Mark Shuttleworth has done on his blog as well.
so .. let's start fixing things :)
@Jeff Waugh: "you did not reference the dates or links which would make your answer relevant to the timeline I provided."
really, your objection is that i didn't provide dates? gah.. fine:
StatusNotifiers didn't exist until 2009. we brought them to xdg@ as soon as we had a working implementation that didn't have obvious issues with it.
as for GNOME devs suggesting changes to the systray spec, those were band-aides over the old spec and if we dig back even further we will find that i made suggestions about ditching xembed as the mechanism a couple years before those emails you link.
regardless, i don't think the point is "who said it in which month and year" but why collaboration isn't happening in general.
"Most relevant: At which point prior to 2008 did any of this happen?"
it's completely irrelevant, as this technology didn't exist in 2008. in fact, it was you who brought up the 2008 date as if it mattered somehow. but it doesn't. not one bit. this is 100% about events that start in the second half of 2009.
and the issue is not "timelines" but "collaboration", or rather the lack thereof.
oh, and your attempts to paint this as my personal issue and my definition of collaboration, etc. is similarly bunkum. i'm not the only one with this viewpoint of GNOME. it's actually fairly widespread.
you can continue to try to deflect by making it out to be an "aaron issue" or a "timeline discrepancy", but that doesn't address the issue at all.
and that approach to these kinds of real issues pretty much sums up the whole problem quite neatly.
It may surprise you, but I have not engaged with your criticism of GNOME in exactly the way you'd desire.
My initial reply was to correct your miscomprehension of the list in Dave Neary's post, for which the timeline (and 2008) is actually very important.
Criticise GNOME developers all you want (it sure ain't relevant to me), but if you want to opportunistically choose a controversial issue as a leaping off point so you can weasel KDE into the discussion, be prepared to be corrected on your assumptions and comprehension.
(For other readers: My replies don't represent GNOME, any GNOME developers or even constitute a response to the more general collaboration issue Seigo raised. He might not get that, but I hope you will.)
@ Jef Spaleta: Try clicking the "gnome" heading on the right of this blog. The first thing you will see is a post from August 2007 complaining about how gnome is developing tracker instead of going with the already-existing strigi. That is over 3 and a half years ago.
@Jeff: I have a very bad example on how broken the freedesktop.org standardization is from GNOME side.
Some time ago Sam Spillaz from Compiz/Unity fame proposed an addition to the NETWM specification at the relevant mailinglist to make it easier to switch desktop shells at runtime (replace Unity with GNOME Shell and vice versa). What do you think how many devs participated in that discussion? It is clearly only relevant to those shells that can be replaced at runtime, right? So you would assume that Mutter devs were participating, right?
Sorry, but I was the only dev responding to Sam's mail and trying to work with him on improving the idea. Althought it is of no relevance to our offerings here at Plasma.
I was seriously disappointed at the lack of any response from GNOME developers at it highlights the issue we see here: standardization through freedesktop.org with GNOME is not possible any more. My current approach to standardize in the land of window managment/compositors is to contact Compiz devs withs ideas before we start to implement it and keep it in a way to make it possible that Compiz can implement it.
Sorry if you think it's just Aaron thinking the process is broken. It's not just Aaron :-(
@aaron,
let me remind you that the indicators implementation was publicly announced in 2008.
http://bazaar.launchpad.net/~indicator-applet-developers/indicator-applet/applet/revision/1
So you may have a beef about the the spec discussion from 2009, you do have the timeline wrong concerning the indicators work. It appears you conflating issues to some degree and that is only going to serve.
I'm going to be very clear the parent discussion about the lack of engagement between Canonical and GNOME dates back to the GNOME Summit and UX Hackfest of 2008. That is not in dispute. Shuttleworth even cites those face-to-face meetings as the genesis for the miscommunication and feels Canonical was encouraged to explore the indicator idea based on conversations at those meetings.
The indicator work used as the prime example of a lack of engagement was officially started in 2008 as per the development record would indicate.
So please keep that in mind. You might not have seen 2008 as critical from your pov..but activity in 2008 is must definitely relevant to the original discussion and the original allegations levelled by Shuttleworth(with no public discussion evidence presented to date)
-jef
@Martin Graesslin:
Sorry if you think it's just Aaron thinking the process is broken. It's not just Aaron :-(
See the last part of my previous post: I have not responded to his general concern about collaboration, so please don't draw conclusions about my perspective on that. Thanks.
@toddrme2178: "GNOME" didn't develop Tracker. A developer in the broader GNOME community did. In fact, for much of it's early life, Tracker was not regarded particularly highly by many GNOME developers.
obvious & repetitive troll is obvious and repetitive.
@toddrme2178: It should be noted that other GNOME people had already do Beagle too when Tracker was developed.. But well, it is the worked on certain particular people. They had also managed to convince the Nokia people that Tracker was the future..
Speaking of working with the community, I noticed that Meego uses a lot of GNOME technology and nothing KDE even though it is Qt based.
Thanks for this post Aaron. I too have been waiting for a good post like this and avoiding wading into the endless arguing that seems to be defining the GNOME project. I've been an active GNOME developer for more than five years and all your points reflect my opinion of how GNOME has been going.
Looking forward to a productive Desktop Summit this year!
"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"
Go back and reread the xdg thread. Can you really look at that and then claim with a straight face that you were trying to collaborate and GNOME wasn't?
We wanted to use that spec. Why do you think we bothered reading it and analyzing it in such detail? But we (Matthias and I, the only two non-Ubuntu GNOME people who had read it at that point) both felt that it was completely unusable as cross-desktop protocol. And so we tried to collaborate on some changes to it. And you completely shot us down. And now you're surprised that we didn't come back later for another beating?
Collaboration, innovation, standardization are all hard enough to achieve in their own right, let alone combined.
I just read the discussion and I think this is one of the things that makes the Free Software community great; opinions and passionate discussion by do'ers :-)
I find after using a linux desktop for some 9 years, both KDE and Gnome are in great shape and (imho) doing better than ever so congrats to all y'all.
Yeah, in retrospect, this is one OT reply; Desktop linux ftw! :-)
@ Dan: I read the discussion, and yes that is exactly the conclusion I drew.
From my reading, your criticisms seem to fall into two categories:
1. Specific issues that Aaron seemed to be willing to fix
2. A disagreement over whether it is safe to assume that the people developing the visualizations won't behave in a stupid or malicious manner.
The gist of your complaints seem to be that since it is possible for visualization developers to do things that don't make any sense, the spec is broken. Aaron responded that the spec is assuming that visualization developers are going to try to make a working visualization. And then the conversation ended. This seems to be a valid point, but there is no response to it.
Aaron also drew comparisons to other aspects of interface design where application developers don't have complete control over the visualization, but there was no response to this either.
He also brought up that the spec needs to be flexible enough to deal with alternative visualizations, which you didn't respond to.
From my reading Aaron provided detailed and well-reasoned responses to your objections. You, on the other hand, just insisted over and over that application developers need to have control over the visualization without providing any evidence or arguments why they need this or any specific responses to Aaron's arguments.
You were asked repeatedly to provide specific examples. Eventually you provided an example that simply needed a hint for overlay locations, which Aaron offered to implement, and he got no response back on this.
So yes, Aaron seemed to be trying hard to be accommodating and to understand and address your objections, while you gave no indication of willingness to reciprocate, or to even give him the specifics he asked for so he could understand your position.
Keep stirring it up GNOME folks(excluding the good ones). I might be a troll because I am really a troll. Just so tired of those powers that be in GNOME trying so hard to make excuses. You've been exposed!
I think the discussion is revolving too much around the notifier spec, when the bigger question for GNOME devs is how much have you done to get fd.o going and healthy in the past 5 years?
I honestly believe it is a good time for them (GNOME devs and community in general) to look at themselves and see if there's something they can do better.
(PS: I speak as a former member of the GNOME community)
@Jeff
You say "It was not relevant to GNOME in 2008. libappindicators was a Canonical adventure, and there was no interaction with upstream until 2010 when it was proposed for inclusion."
That is entirely untrue, and I've told you as much privately. The work was disclosed to Shell designers and developers, and it was described exactly as it arrived - a gtk-friendly implementation of a cross-desktop standard based on icons and menus.
Defending GNOME when the facts don't support the position smacks of blind and misplaced loyalty. There are real lessons for GNOME here, which if embraced would make the project healthier and stronger.
@Lennart
You say "GNOME adopts some specs and others they don't, depending on how things fit into the UX design they want to achieve."
That's reasonable, but each decision is either pro-collaboration or makes collaboration more difficult.
In this case, the Shell designers were briefed at the very beginning that this work would be done, that it would be done in compliance with a cross-desktop spec, and the experience it would deliver. This was after the UX hackfest where no opinion was expressed about indicators other than "the panel needs to be cleaned up". They agreed, right at the beginning, that this would be a valuable approach.
When the work was actually delivered however, Shell designers chose not only to go back on their prior position that this approach and code would be welcome, but to take a different path which was at odds with what was now a widely implemented cross-desktop standard.
It's hard to argue that the product of their imagination is so good that it warrants such a dramatically uncollaborative approach - both in the ill will it created amongst Canonical deves, who had a nice contribution thrown back in their faces, but also in the flagrant failure to adopt a clean cross-desktop standard.
@Jef
You say "I think important point is there is a 2 year gap of _discussion_ in the public record. 2 years with no public record..no back and forth..no feedback...and its going to be very difficult to synthesize any negative feelings constructive future."
That misses the point. For that entire time, the Shell designers were aware of the work and the cross-desktop standard. What's relevant is that the Shell decision to "explore other ideas" came AFTER the standard was formalised and improved and the code was written.
@Dan
You say "But we (Matthias and I, the only two non-Ubuntu GNOME people who had read it at that point) both felt that it was completely unusable as cross-desktop protocol."
In this case, though, since many Gnome apps do in fact work very well with it on Unity and KDE, would you reconsider that position?
Now that the work has been done, it's tested well in UX, the app integration has gone smoothly and many upstreams have either added that capability (from multiple different desktops) or have patches available, the question of viability as a cross-desktop protocol is surely addressed?
@ Dan
I am currently reading that thread on xdg, how exactly have you been "completely shut off"? All I read is you (admittedly) being a bit harsh and Aaron either agreeing on some changes, or asking for actual use cases on the points where he disagrees...
Disclaimer, I am by no means a developper, so I can not say anything about the technicalities. I am however a happy KDE user, highly respectful of what GNOME does, and really annoyed when the obvious shared goals between the projects are getting sidelined by what seems to amount to pride and interpersonal conflicts (and I'm not directing it particularly at GNOME, KDE has its share, although seems to be more pro-active about it these days).
In short, this isn't really about the notifications spec, disagreement happens. It's the process, and the examples given by Aaron in a comment, is really worrying and frustrating, from a simple user point of view.
@Aaron, thanks for publicly addressing the issue. I hope you guys find a way to move things forward this summer. It's needed, badly.
@sabdfl At no time was I "briefed" or informed by you or any of your employees during or after the 2008 UX Hackfest on work that you may be considering or performing with respect to app indicators. Continuing to suggest this without providing any evidence is childish.
As far as I'm aware, the first time anyone heard about appindicators was years later on the mailing list. I and many others were initially very excited by the idea since it fit with the publicly discussed design goal of making the system status area more coherent. However, one part of the plan seemed strange to me: cross desktop support for status indicators that were desktop specific. That seemed like an odd design priority but on its own it wouldn't have precluded its adoption. Beyond those two points I had no part in any decision regarding appindicators. It is entirely a technical implementation decision and up to the domain experts. They reviewed the code and commented in public. I wasn't asked about it, I wasn't informed about it other than through the mail list, nor did I have any opinion on the matter beyond what I stated above. I thought the decision was unfortunate because it delayed satisfying a design goal and created more work. But that was the choice of the developers involved.
Your behavior and tabloid insinuations on this matter here and in your own blog have been unacceptable. Please, respectfully, cut it out. Let's get back to work.
@Dan Winship: "Can you really look at that and then claim with a straight face that you were trying to collaborate and GNOME wasn't?"
sorry, i wasn't clear enough in that sentence. what i was trying to say was that GNOME did not adopt it: "resolved one by one as those who adopted the technology [...] GNOME wasn't one of those participants."
"We wanted to use that spec."
well, if you'd wanted to you would have. really, there are multiple (i know of at least 3) implementations of it and it works well in each. :)
"both felt that it was completely unusable as cross-desktop protocol."
evidence by experience shows this is not the case.
what strikes me as most odd here is that many of the specs put forward by GNOME are lacking, and in much more obvious ways. there's really a double standard in terms of what is accepted, based on whether it emerges from within GNOME or from outside of it. and i understand the psychology behind that: something from within has a level of automatic trust and appreciation that comes from the teamwork based relationships that precede the work. this is sometimes referred to as "NIH syndrome".
it is indeed at the root of the problems.
"And so we tried to collaborate on some changes to it. And you completely shot us down."
completely? that's dramatic to the point of dishonest.
we made changes to the spec. not every change requested was made, and that's part of the practice of working with others, which sometimes involves compromise. sometimes people disagree, there's give and take, we try things out even if it isn't "perfect" in our personal eyes and see how it goes.
there are numerous things that i could offer (and have offered) as needing improvement on fd.o specs that we've implemented. not all of those requests for improvement get acted on. that's life. still, we've implemented them because interop is a higher priority that always getting our way down to the last detail. perfection, as they say, is often the enemy of good.
and let's try to keep the bigger picture in mind here as well: this is not a singular event, but a pattern of behavior, which is why it is concerning. one spec, one failed collaboration would be a non-event in my eyes; but when parties repeatedly demonstrate they can't work together, particularly when everyone else is generally managing to do so, then alarm bells start ringing.
to make my personal motivations crystal clear here: i want to find a way to have GNOME back to the table as a constructive, participative collaborator because that is what is best for all of our users.
@sabdfl:
The work was disclosed to Shell designers and developers, and it was described exactly as it arrived - a gtk-friendly implementation of a cross-desktop standard based on icons and menus.
Which cross-desktop standard did you intend to use (and thus describe to GNOME developers) when you disclosed this work in at the hackfest in 2008?
(When you say "disclose", are you suggesting that the work was already underway, or that you said to GNOME developers that Canonical would subsequently do the work?)
@Jeff
At the time of the UX hackfest, no code had been written, but we were interested in the idea of dbus-based indicators which resonated with conversations happening at KDE.
That is what was sketched out, and that is what became the XDG "status notifier" spec that Aaron's talking about.
@Jon
Ted Gould told me in Boston, at the conclusion of the UX hackfest, that he'd taken you through the panel / indicator work. He's consistently maintained that position, and I believe him.
This is also consistent with the timing of the first commits on what became the appindicator API.
The standardisation conversations took place on XDG with the involvement of GNOME people.
Your decision not to use those for Shell seems arbitrary in the face of what was then growing consensus around the standard, multiple implementations of the standard, and ample opportunity to participate in setting the standard.
The rejection of the API's as external dependencies appears to have been motivated substantially by a desire not to compete with new ideas you had then decided to develop. That misses the point of *external* dependencies substantially. You're fully entitled to pursue whatever design you want with Shell, but to argue against *external* dependencies because they compete with that design is an abuse of your position in Gnome, in my view.
It's also at the heart of Aaron's concern about Gnome's ambivalence to XDG work.
Hello everyone, let me just go over there and bang my head against a wall very hard.
OK, now I'm back, I'd just like to inform some of you that YOU ARE MISSING THE POINT ENTIRELY. The point isn't "We said it first!", the point is that both GNOME and KDE wanted to re-design the spec., KDE created a working implementation, then took the critisisms of GNOME and fixed them as well as implementing new features for the sole purpose of satisfying the GNOME developers and making a single, unified cross-platform system-tray specification and now, GNOME is doing their own thing.
The point is that KDE could have decided to completely ignore GNOME and implement a system tray specification that depended on KDE technology or was specific to the KDE workspace in some way, but they chose to talk to the GNOME developers and worked on the specification to fit their needs and now, GNOME is implementing their own, GNOME-specific technology that is incompatible. GNOME apps using the GNOME 3 system tray specification won't have consistent system tray behaviour in KDE, and KDE apps won't have consistent system tray behaviour in GNOME, for absolutely no reason except because GNOME doesn't want to use KDE's work, even after KDE designed the specification to GNOME's wishlist, for all intents and purposes.
This isn't about a system tray specification, this is about GNOME being uncooperative to the point of being a hinderance to free software WMs/DEs everywhere. You're not trying to prove that GNOME came up with an *idea* (rather than a *working implementation*) for a new system tray specification, you're trying to prove that GNOME is genuinely cooperating and collaborating with other DE developers to provide good, cross-DE applications. Given their attitude towards KDE's perfectly functional, featureful and already widely adopted system tray specification, your argument does not bode well.
@sabdfl
Though it wasn't the case a few weeks ago, I am now incredibly disappointed in you.
My disappointment is not the result of a blind faith in GNOME. I am well aware that GNOME, as a community and as individuals, can at times be terrifically difficult to work with.
You, however -- and I do not blame your staff! -- have not made a genuine attempt to collaborate... and now you are madly commenting on blogs, taking personal offence, chucking your toys at the wall, and attacking the GNOME community due to your failure to influence their development agenda.
I have yet to see any admission of fault on your side.
Aaron
well said, but sadly i have to say on kde there is the same problem even betweenn some applications
i have said the thing here
https://bugs.kde.org/show_bug.cgi?id=268041
This is bad for DE i mean if i want produce someting with kde i got several problems on printing side so office work can't be done fast.
to the end... kde can't be usefull to normal user if he can't produdce something for office..
i get the bug closed... when applications on kde and generally speaking into freedesktop system have not a standard print dialog
i guess kde leaker should write about standards on printing.
could you organize something about that ?
and yea i have read this ...
http://www.linuxfoundation.org/collaborate/workgroups/openprinting/commonprintingdialog
@nowardev
Such problems exist between gnome applications as well, but it's probably not related to discussion at all. Nobody from Konqueror, Aurora tries to trick the other side and then, show him a middle finger like gnome devs already did many times.
@sabdl
"Ted Gould told me in Boston, at the conclusion of the UX hackfest, that he'd taken you through the panel / indicator work."
Ted did not take me through any work during the 2008 UX Hackfest. Nor did anyone else on your staff. I'm sorry you're getting such bad information.
In any case, you wouldn't have needed to talk to me. Owen is the technical lead of the project and Ted was working on a technical spec not a design spec. However, as you know, the GNOME Shell only started some time after the hackfest. It was announced by Owen on his blog. I wasn't involved in an official capacity in the first 6 months or so. If you had a sincere desire to collaborate you or an assignee should have contacted Owen when it was announced - or *any time thereafter*. As far as I know, you did not.
"Your decision not to use those for Shell seems arbitrary in the face of what was then growing consensus around the standard, multiple implementations of the standard, and ample opportunity to participate in setting the standard."
As I stated above very clearly, I did not make any decision on this matter.
"The rejection of the API's as external dependencies appears to have been motivated substantially by a desire not to compete with new ideas you had then decided to develop. That misses the point of *external* dependencies substantially. You're fully entitled to pursue whatever design you want with Shell, but to argue against *external* dependencies because they compete with that design is an abuse of your position in Gnome, in my view."
First of all, I don't recall arguing against appindicators during any external dependency proposal. Secondly, I think you are entirely misunderstanding what external dependencies mean. Thirdly, it is not an abuse to take issue with an implementation that doesn't facilitate the design - it is the right thing to do.
Once again, please, stop these baseless attacks and let everyone get back to work.
@Jeff
This blog is about concrete decisions taken in Gnome to ignore cross-desktop standards with working gtk-friendly implementations.
Decisions taken by Gnome are both complicating the traditional Gnome-KDE axis, and also leading, inevitably, to the treatment of Unity as something other than a shell for Gnome. Focus on that, and you'll see what's at stake here.
You say I have not made a genuine attempt to collaborate. That's nonsense. We would not have participated in the original UX hackfest, and hosted subsequent ones, if we were not interested in collaboration. We would not have built Unity if we had any hope of getting serious design collaboration - hope that was dashed after just a short time of watching how Shell was handled. We welcomed participation around notifications - rejected - messaging - rejected - indicators - rejected. And we watched others experience the same thing. I recall also the strong arguments you made against my blogs inclusion on planet.gnome.org, hardly conducive to collaboration either.
You describe me as commenting madly on blogs. Also nonsense. I'm speaking firmly and clearly so that folk who are watching this debacle unfold understand both sides to the story. I'm tired of having Canonical be the whipping boy of folk who actively block attempts to collaborate.
As for abject failure to collaborate, I think the Ubuntu and Ayatana teams have done incredible work with many upstreams from across the range of Gnome and KDE. Perhaps being the outsider makes us more inclined to focus on what can get done, than how our position at the center of Gnome can be used to control the outcome.
"Ted did not take me through any work during the 2008 UX Hackfest. Nor did anyone else on your staff. I'm sorry you're getting such bad information."
I am sorry I can't help it but this sounds like a spoiled brat little girl.
Thanks everyone! Keep us informed ;-)
We welcomed participation around notifications - rejected - messaging - rejected - indicators - rejected.
You are relying on lies of omission, and aiming to confuse the community, Mark.
I'm speaking firmly and clearly so that folk who are watching this debacle unfold understand both sides to the story.
Seems like an odd thing to say, when you quite obviously have the biggest loudspeaker, and all the press so far has firmly represented your side of the story (aided, of course, but the surprise announcement).
@ Jeff: Care to provide specifics?
You asked a question. sabdfl provided what seemed like pretty specific answers to your questions. When he did you launched an extended but vague personal attack. He responded with more specifics. You respond with vague accusations of "lies by omission".
As best as I can tell sabdfl is trying to carry out a detailed and civil discussion about the issues Aaron brought up, while you are bringing up irrelevant nitpicks about the timeline, launching apparently unprovoked personal attacks without any specifics, and refusing to address or acknowledge the point people have been discussing.
I am sure there is a lot of backstory and history regarding this issue that you are basing your accusations off of, but not everyone reading this knows that backstory and history. Having come without having followed that discussion before I only see you attacking, throwing out unsupported accusations of misconduct, nitpicking irrelevant details, and consistently missing or dodging the point that people are trying to bring up. On the other hand I see sabdfl calmly providing extensive details supporting his assertions and calmly answering your questions. I also see Aaron, sabdfl and most everyone else trying to get you to deal with the actual issue at hand. Judging by other comments I do not seem to be the only one under this impressions
So it would be very helpful if you:
1. Provided some specifics that you feel support your accusations
2. Actually address the point that is being discussed here
Not everyone knows the details of the discussion up to this point, so it would be very helpful if you explained the reasons for your accusations. I also would be very interested in seeing your response to Aaron's more general point about collaboration with Gnome.
@toddrme2178
I think it just shows who they are. I really lost respect for them. Just look at how immature they respond... *sigh*
@toddrme2178:
I am writing at the moment about the history and backstory, and will post it on my blog soon.
Please remember that my response to this thread was about that backstory (not Aaron's broader concerns), and to correct the context Aaron missed from what he was quoting.
Although I have history with both GNOME and Canonical, I do not speak for or represent either.
@ Jeff: That is the whole problem. You posted irrelevant nitpicks while ignoring the actual substance of the discussion. It is off-topic and, judging by the number of posts that are trying to address you, it is derailing the conversation.
If you are going to make a separate blog post describing your allegations, can we drop that discussion here and continue with the original topic? I think it is an important one and worth discussing, and it judging by the comments it seems like a lot of other people agree.
Can you answer two simple questions:
1. Do you agree with Aaron's general point about collaboration involving Gnome
2. Why do you hold that position?
I think that question is slightly disingenuous. If Aaron is using incorrect or slanted supporting evidence to draw his conclusions, it's perfectly legitimate to challenge that supporting evidence. His conclusion may well stand regardless, but at least the record should be set straight. His assertion is (at this point) only his opinion, and other people have other opinions.
@toddrme2178
Irrelevancy is a matter of perspective.
There is a major inconsistency in the timeline of events and when what was said to whom and when with regard to Canonical's "commissioned" work on indicators.
Just in these blog comments alone Mark Shuttleworth relates information passed to him from Ted Gould about a face-to-face conversation with another person that Shuttleworth was not a part of. Shuttleworth took Ted's recitation of that conversation at face value. Now that the other person has been named, that person has spoken up and refuted that. A conversation from 2008..finally being verified in 2011.
At such a late date it is impossible as to who is misremembering and certainly no way of knowing what was actually said between Ted and the named GNOME project participant.
What is problematic for me is that there is no evidence in the public record inside any archived GNOME forum about the conversation. No "hey guys I'd like some feedback on this first implementation of the idea I discussed at the hackfest with you a couple of months ago" inside the scope of the GNOME channels in late 2008.
Keep the xdg discussion in perspective. As an outsider looking in, there is no public evidence from 2008 or 2009 that Canonical intended to inject this into the GNOME project. It looks like it was intended to to be external vendor specific work. I can't find any written evidence that Canonical desired indicators to be incorporated into GNOME until 2010.
When look at historic participation of events, you have to make sure you set the correct expectations as to what people could have and should have reasonably known. There is no publicly archived evidence at all that indicators were being built with the implicit understanding that it was going to be proposed for GNOME. There is no statement on record until 2010 that Canonical was going to submit it.
-jef
1. Do you agree with Aaron's general point about collaboration involving Gnome
2. Why do you hold that position?
You did catch the bit about my opinion on those things being completely irrelevant, right?
@ Jef: None of that explains why Gnome developers decided to make their own system when there was already a cross-desktop specification available that had been implemented by several other groups, or why this seems to be a consistent behavior on the part of Gnome developers.
@sabdfl
"You say I have not made a genuine attempt to collaborate. That's nonsense. We would not have participated in the original UX hackfest, and hosted subsequent ones, if we were not interested in collaboration. We would not have built Unity if we had any hope of getting serious design collaboration"
I appreciate your help and involved in GNOME. You, Canonical and Ubuntu are _very_ important in the GNOME ecosystem. However, we've been failing in getting the work together. I'm sure the GNOME side has made some mistakes in the past but I think there are mistakes on yours as well. Never is too late to get it right and find new common goals to work together. We need less "they" and more "we"
If I was asked what was wrong, I think we need to be sure that the communication channel between both project is working. We need to debate the future of GNOME in the same arena. Starting a project for inclusion in GNOME outside of GNOME is getting a high risk of not being accepted for different reasons.
Anyway, I don't think my opinion isn't particularly relevant. We need to get together relevant members of both projects and talk for a long time.
Just my two cent
@Todd
Let me quote someone whom I think you might respect:
"to all those people on the xdg list who behave like standardization is obviously the most important thing imaginable: not everyone is like you! and those who aren't, are not necessarily wrong! wow! diversity!"
--Aaron Seigo from his blog post entitled "The stupidity of dconf"
http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html
It's very easy to throw around NIH allegations. We need to get past that and recognize that the specification discussions happening in the context of freedesktop must get buy-in from those expected to adopt it.
If there is no outreach to establish buy-in from a particular party then there it is an unfounded expectation that the final specification will be picked up and used by that party.
Now on to specifics. Was there a communication breakdown concerning the indicators stuff. Yes absolutely. I will point to the Dconf discussion as a counter-example of an effort to attempt to get buy-in from all parties and set expectations as to what Dconf would have to achieve to be usable by KDE and GNOME. And inside the scope of all that discussion its not clear that Dconf succeeded in what it set out to do. But there is most definitely a public record as to expectations Dconf needed to fulfill from each project which was hoped to adopt it.
Back to indicators, there is no evidence in the public record that I can find that Canonical attempted to drive discussion about adoption of the proposed specification inside the GNOME project communication channels and get feedback from the people who needed to buy-in to the technical specifics.
If there was an assumption by some in the xdg discussion that Canonical was working on a gtk implementation with buy-in from GNOME and did less outreach than they would have otherwise done to attempt to establish buy-in... that is a real problem...a real problem caused by Canonical's continued characterization of their relationship with the GNOME project.
-jef
Enough.
This bickering is not helping anyone. We are a community - we should not be locked in a he-said-she-said game - we should be identifying solutions for the future.
There are lessons to be learned for *everyone* here, but it seems many participants in this debate are unwilling to be receptive to feedback. This unwillingness is causing a silo effect that is hampering our ability to work together to bring Free Software to everyone.
I don't believe we should be digging up the past, we should be focusing on the key take aways from this discussion and carving out a better future.
Aaron has raised some important issues, which I think many of us have faced, but the responses in the comments have also raised valuable points for focus too.
Sure, I am a public member of the Ubuntu community, but I joined the GNOME community well before I joined Canonical, and I was part of the KDE community well before that. Everyone in this discussion, Aaron, Mark, Jef, Jeff, Jon -- everyone has great intentions for Free Software -- but I am tired of the politics getting in the way of real contributions.
Let's be frank:
* GNOME - you do have a public perception of being difficult to collaborate with. Aaron's post raises real and valuable points.
* Canonical - you do have a public perception of developing things privately.
These are perceptions, and the evidence in many circumstances invalidate these perceptions, but our communities look to the leaders of these projects to solve these issues. So far I have only seen defensiveness and political interplay and not the kind of objective solutions-focused problem-solving I would expect.
Let's stop the bickering and let's get together with an agenda and solve these problems. GNOME is great for Free Software, Ubuntu is great for Free Software, KDE is great for Free Software.
Oops, that is what happens when I am logging into my Severed Fifth email and I post a comment from my Google Account - that was from me, folks. :-)
@jono/Severed: well said; everyone has things to learn and everyone can do better than they have done in the past.
(for the record, this is dcbw)
@Juanjo Marín
It is nice to see to a forward-looking effort at collaboration extended to Canonical and Ubuntu. Given that the significant context of this blog entry is the collaboration between KDE and GNOME, might the KDE community also be privileged to receive a similar extension of collaborative effort?
Starting a project for inclusion in GNOME outside of GNOME is getting a high risk of not being accepted for different reasons.
This... I struggle to see how KDE folks should interpret this as anything other than NIH...
It is genuinely difficult, at best, not to feel snubbed, at worst, not to feel thoroughly disrespected with this as yet another expression of the sentiment of folks with which the KDE community is to collaborate. Here's we have an blog entry that explicitly identifies the problem folks in the KDE community have collaborating with the GNOME project, and this response is to... Canonical/Ubuntu.
Honestly, I would rather an explicit "NO WE DON"T WANT TO COLLABORATE WITH YOU KDE" than this apparent talk-like-they-don't-exist/what's-relevant-is-what-we-choose-to-talk-about/nod-and-smile-to-make-them-go-away behavior towards the KDE community. My greater preference, of course, is that both communities honestly and constructively work together.
@Severed: Those who ignore the past are doomed to repeat it. And we have been failing for some time to understand the issues which people have working in fdo, or with GNOME, KDE or Canonical (you don't think people have had issues working with Canonical?)
Many of these issues come from personality issues, many of them come from community processes (or a lack of them), and many of them come from people treating GNOME as something it's not.
I remember getting very passionate with you in a taxi about this issue 2 year ago in Portland - you were telling me (volunteer board member on a board with no technical mandate) that I needed to step up & lead GNOME. I now realise that you had this idea of GNOME as a single thing - and so do others - and this has led to massive problems, because there *is* no neck to grab.
It's up to you to find the right people and work (ad hoc) on things that are important to you in GNOME. Treating GNOME as something it isn't will only lead to heartache.
There are issues - there are people who have positioned themselves as lynchpins for parts of the project who are hard to work with, and we've abandoned some of our best practices, sacrificed at the altar of expediency and Getting Things Done (so there isn't much public record of how we got here, which makes it that much harder to fix).
You say we should focus on the future - I agree. But we can't forget the past. We're like doctors, diagnosing a sick patient. We can't just say "perk up, you'll be fine tomorrow". We need to know what's wrong, and figure out how to fix it.
Dave.
@Jamboarder
"It is nice to see to a forward-looking effort at collaboration extended to Canonical and Ubuntu. Given that the significant context of this blog entry is the collaboration between KDE and GNOME, might the KDE community also be privileged to receive a similar extension of collaborative effort?"
A healthy collaboration between GNOME and Canonical is a step forward for the collaboration with KDE. If you read with attention you'll notice that maybe a good communication between Canonical and GNOME since the beginning could be resulted in a support of libappindicator in GNOME :)
I'm sure all the readers know that, but _we_ have a Desktop Summit in Berlin this year, so it will a great opportunity to resolve our freedesktop issues there.
This can be a step forward if we are able to create a good mood and find the space and time for collaboration apart from our "separated" events.
[Sorry for too-many posts from me, but I just want to help]
Few reading that little lot was a bit of a mission.
To add my 2cents.
Playing the blame game is both a tiring and largely pointless exercise, that unfortunately we as a community seem to be all to good at playing.
What's truly important here is to agree without the need for blame that;
a) There is indeed an issue surrounding inter community collaboration and more specifically an issue with interface duplication.
b) That it would benefit everyone involved if these issues were tackled sooner rather than later.
If everyone can at least agree that a problem exists here, then maybe a productive discussion can be had about trying address these issues instead of fighting about time lines and who said what?
Great post. The gnome attitude is one of the main non technical reasons I like KDE the most!
@Dave "Those who ignore the past are doomed to repeat it".
I agree, and I am not suggesting we ignore the past; I am suggesting we learn from our experience but then move on and forge new ways of working together and resolving these issues.
So far I have seen a lot of finger pointing and angry rhetoric, but little constructive effort put into finding solutions. I have also seen little acknowledgement from all sides that legitimate problems exist that need to be resolved.
Let's learn from the past, but not dwell on it.
@Jono Bacon
The solution in the context of Canonical and GNOME is easy.... mimic how CSD was communicated and developed and then incorporated into gtk+.
CSD development, development led by a Canonical staffer seems to have gone quite smoothly. If you want a way forward... let's stand up what went right with regard to the CSD development.
Things that stand out to me.
1) CSD was not a finished implementation...it was not code thrown over the wall. The person driving CSD got feedback from the existing gtk+ devs early enough in the process so the feedback with regard to technical specifics could be incorporated into the implementation without strategic pushback. Something that is nigh impossible to do once an implementation is deployed as part of a larger shipping product.
2) CSD development was done in the context of the GNOME infrastructure to make it easier for collaboration with existing GNOME devs in anticipation of needing it to be merged with mainline gtk+. The use of common project-wide infrastructure as part of a set of best practises which also include coding style greatly reduce collaborative friction and increase the chances that people will actually review the code in a timely manner.
3) No copyright assignment requirement. No politics wrt strategic ownership.
I truly appreciate the fact that if you use KDM, you can logout/reboot/shutdown in both GNOME and KDE. Plus KDM looks great too. The Gnome folks seem to make sure that KDE is treated second class where you cant perform a shutdown or reboot without exiting KDE to go back to GDM.
GDM seemed fine, then came GDM2 which is still butt ugly after 2 years.
KDE has always seemed to go that extra mile to play well with others. I have never gotten that impression from GNOME.
@Elder Geek,
I'm not sure I understand your criticism of GDM in this context.
Running Fedora 14 using GDM as the login manager interface I can just as easily log into KDE as well as GNOME sessions. GDM even remembers the last session I used whether it be KDE or GNOME so I don't have to keep asking for KDE. I only have to switch sessions in GDM when I want to change. I don't see any evidence of second class treatment there in terms of user interaction.
And GDM's system shutdown and reboot workforme. So do KDE's shutdown and reboot. So do GNOME's shutdown and reboot.
I'm just not seeing any of the integration issues you seem to be having. I'm not saying you aren't seeing these issues on your system. Can you please tell me which precompiled linux distribution release of GDM you are using locally?
-jef
From what I understand:
KDE saw the System Tray as being broken and worked on creating a cross-desktop standard. Canonical then decided to adopt this standard and created a GNOME implementation for it. It proposed it's in-house implementation for inclusion in GNOME, but GNOME not only rejected Canonical's libappindicator but also KDE's StatusNotifier spec and created an incompatible implementation. The question isn't really why GNOME rejected libappindicator, but why GNOME rejected what was being developed as a cross-platform standard. Did it have a valid reason, or is it really the NIH syndrome? And that's just for the specific example Aaron provided, but he claims that GNOME has a consistent history of rejecting standards that were proposed by other groups for at least the past 5 years. So the real question is whether GNOME really does have a NIH syndrome, or is there a valid reason in each case?
There are other examples of gnome being not cooperative with FLOSS - gnome foundation supported MS OOXML rather than ODF! It's a freaking joke... What I read here it seems Mark had problems with gnome planet, because some people from gnome didn't want his blog to appear there (while Icaza - MS employer, has a great time trolling about mono at gnome planet and it seems nobody protest). The truth is Gnome isn't dead yet thanks to Mark and Canonical.
There are other examples of gnome being not cooperative with FLOSS - gnome foundation supported MS OOXML rather than ODF!
No, that's entirely untrue.
The GNOME Foundation helped Jody Goldberg continue on the OOXML standards committee once he left Novell (because ECMA only recognises organisational membership), and the reason he was there was to hold Microsoft to account and try to ensure OOXML wasn't totally abysmal for everyone else. The Board's decision to do that was controversial even within the GNOME developer community, but was understood.
The GNOME Foundation and the GNOME community definitely did not "support" or prefer OOXML to ODF.
That's the kind of thing people only believe through hearsay and a willingness to believe the worst in another community.
@Jeff
Untrue, you say?
http://www.linux.com/archive/feed/121930
http://www.itwire.com/opinion-and-analysis/open-sauce/15738-kde-takes-stand-on-ooxml-gnome-dithers
Let me quote someone:
"The participation of GNOME in ECMA TC45’s apparent subversion of the standards process is a major disservice to FOSS and all in the community who have worked so hard for open platforms and open standards." From this position, what matters is loyalty -- and that, for many, seems to mean support only for ODF and a complete boycott of any efforts to make OOXML a standard.
And this:
http://mail.gnome.org/archives/foundation-list/2007-November/msg00114.html
"In http://dot.kde.org/1194021253/, major KDE developers announce their
rejection of OOXML. It would be a good thing for GNOME to make
announcement equally unhelpful to Microsoft's promotion of OOxXML.
GNOME and KDE should stand side-by-side in this."
Did gnome rejected MS OOXML?
So why do you guys think the Linux Desktop has not yet taken off?
Heaving read this whole thread, I think I know:
1. No leadership
2. No collaboration
3. Not invented by me syndrome
Compare you're pitty efforts with what MS and Apple and Google have produced and the time it took to produce it.
Open source should drive innovation. Apple is innovative (iPad), Google is (Android). Even MS is (Kinect). OSS isn't (anymore).
Did gnome rejected MS OOXML?
No, but not rejecting it does not imply that the GNOME community supported it above and beyond ODF. Jody's interest was to ensure that FLOSS products could implement it at all, so users had some hope of interoperability.
The press pieces you cite are not informed or reliable. :-)
But now you're just regurgitating a bunch of old, irrelevant crap that is unrelated either to Aaron's point or mine.
@Jeff
Your funny. Really, you're tickling me right through my bones :-)
@Jeff
In my feeling those press quotes are far more reliable than some persons from gnome. There's something that supports my feeling - Icaza's still lobbying at planet gnome. While he supports MS, MS OOXML, mono and writes about this at planet gnome then I'm not surprised if gnome foundation supports MS OOXML too. It's logical in this case that by not rejecting and by participating in ECMA is equal to supporting MS OOXML 'standard'. It's very strictly related to discussion, because it shows how gnome isolates from KDE and from FLOSS overall.
"No, but not rejecting it does not imply that the GNOME community supported it above and beyond ODF"
It means exactly that. Silently watching bullying or crime (or wrong doing) happening is accepting it to happend.
Taking stand against bad decisions and wrong doings is by telling own opinion. Especially when the subject is touching whole world and the goal what the whole open source community has being working for few decades.
That is one of the problems of GNOME community that they do not care about the big picture (C#/Mono, OOXML, OpenDesktop.org, Silverlight....) but only about them selfs. Just like what Canonical is doing.
ODF / OOXML is pretty far off topic... yes they are standards, but they aren't ones that have such an immediate impact like the fd.o standards like status notifier, icon / sound theme naming schemes etc.
The politics of supporting OOXML might be fun for flame wars but they aren't really useful in the immediate discussion of desktop interoperability, being at most highly tangential.
dang... missed words... "such an immediate impact" should read "such an immediate impact on desktop interoperability"
As an author of a non-kde and non-gtk/gnome application this makes it all very interesting. How many standards do we now have for implementing a simple tray icon? Counting 3 so far: Xembed, StatusNotifier and AppIndicator. No idea what gnome-shell uses, but I'm sure it will be very gnome specific and incompatible with the rest of non-gnome applications.
AppIndicator uses only part of the StatusNotifier spec (they dropped all the things they didn't like, like mouse wheel interaction), so that makes these two technologies pretty much incompatible. Which one does KDE use?
Ever since the GNOME folks started with the spatial nautilus thingie it's been a very steep downhill in terms of viable and thought out design decisions.
A lack of collaboration, is something I see as a means to an end to force ones own desires upon everyone. I'm well aware that anyone can go ahead and contribute, that's what f/oss is all about. However it doesn't quite work out to be that way in real life. One of the reasons being that one does not become a coder over night.
That being said, I'm impressed by the civil discussion expressed in the comments section of Aaron's blog. Regardless of ones own viewpoint :)
@sxj: AppIndicators are built on StatusNotifier and is compatible with it. StatusNotifier is designed so that the visualization controls how the indicator is displayed and how the user interacts with it, so for the visualization to decide not to allow mouse wheel interactions is something that is supported by the StatusNotifier spec.
Of course KDE uses StatusNotifier, as KDE are the ones who created it in the first place.
sxj,
I think the devil is in the details really and gets to the heart of some of the expressed criticism of the spec in question. What can application developer rely on in terms of expected user interaction via KDE's concept of indicators and Canonical's concept of indicators.
They use the same underlying "spec" in terms of communicating between the platform control UI elements and the application itself. But the platform provider has a lot more flexibility in saying what is allowed or disallowed to be expressed in the UI. And application writers have to prepare for a situation where different UI platforms express and expect different interaction behaviour from a user.
That may or may not cause problems for application developers who want to have their indicators used in specific ways for the multiple platforms making use of the underlying spec. At the end of the day even though the spec is in use, for an application writer they might have to make write code that is platform UI specific based on their understanding of how each platform's UI actually allows in terms of interaction.
Time will tell. I look forward to seeing more 3rd application writers talk about their experience concerning the amount of work needed to adapt application code to integrate well for both KDE and Ubuntu's indicator concepts even though they rely on the same underlying spec. I definitely want to see 3rd party application writers talk about the experience. It could be its trivial, it could be its hard. I'm not going to assume either.
-jef
As a user, I couldn't care less about the behind the scene issues you guys are talking about. I wish you guys could collaborate peacefully with one another, but at the end of the day, what matters is if Linux is able to provide a good user experience or not.
KDE has proven to be a usability mess time and again. Gnome has proven to take extreme care to what makes consistency and what doesn't (consistency being no.1 concern -IMHO- in usability for the desktop).
From all the comments here, I tend to believe the camp accusing the Gnome team of being infected by the NIH, but who cares if they can produce the best UX there is? You, the developers, care. We, the ordinary users, don't.
I tend to use Ubuntu as it has a goal I can trust (becoming a profitable endeavour for Canonical). Gnome has solid foundations for their design and they're right at not trusting too much what others want them to do, but Canonical does mostly the same. (Design doesn't work by listening to everyone out there, so I'm all for behind the doors small design teams.) RedHat is not about consumers, but enterprises, and has said they don't want to enter the desktop market. Good for them. I'm a desktop user. I don't care about RedHat then.
All that means that unless Unity is a disaster or GnomeShell is glorious, Canonical will stay on top and we users will get used to whatever they offer. And if both Unity and GnomeShell are a disaster, we can still use Gnome2 until someone understand the ordinary users' needs.
@Jef Spaleta: You wrote:
I'm not sure I understand your criticism of GDM in this context.
Running Fedora 14 using GDM as the login manager interface I can just as easily log into KDE as well as GNOME sessions. [...] And GDM's system shutdown and reboot workforme. So do KDE's shutdown and reboot. So do GNOME's shutdown and reboot.
Shutdown/reboot with GDM (actually ConsoleKit, GDM itself doesn't offer a shutdown service anymore, it also goes through ConsoleKit when you use the UI inside GDM) only works in Fedora's KDE because I wrote a Fedora-specific ck-shutdown patch to support it.
The good news is that starting from 4.6.0, this is now supported in upstream KDE. There's also support for GDM session switching in 4.6.x, which I backported to the current 4.5.x packages in Fedora.
But this stuff was broken for years, and still is in the distros which haven't adopted 4.6.x nor the backported patch (or my old one) yet.
@Kevin
Ah thanks, I try to be diligent with regard to following up on interaction issues.
So with what you said in mind. Would it be most correct to say that the underlying issue here is the disruption caused by the introduction of ConsoleKit as a freedesktop technology?
I take it this is the upstream patch reference:
http://svn.reviewboard.kde.org/r/5699/
Would this debian related patch request be related to the issue as well with regard to KDM specific suppport for ConsoleKit?
http://lists.debian.org/debian-qt-kde/2007/11/msg00107.html
And it seems other DEs are still working on integrating with ConsoleKit as well
http://lists.freedesktop.org/archives/consolekit/2010-September/000129.html
Thanks for the explanation and the integration work you put in.
-jef
@Jef Spaleta
I look forward to seeing more 3rd application writers talk about their experience concerning the amount of work needed to adapt application code to integrate well for both KDE and Ubuntu's indicator concepts even though they rely on the same underlying spec.
I'm an app developer and it is effortless. I only use KStatusNotifierItem in my KDE app. How wonderful to see my app show up in the GNOME systray in Ubuntu with appropriate-for-that-environment scrubbing GTK menus and tooltips. Of course in the KDE Plasma systray it looks like it should as a KDE app - with Plasma tooltips and Qt menus. It will cost me more effort to ensure it works well with GNOME Shell since I may need to write code specifically for that DE.
I don't particularly care that GNOME Shell folks rejected libappindicator. I just wanted them to implement a common spec so I don't have worry about DE-specific code. I'm guessing that Unity developers would be somewhat more satisfied knowing that apps written for the GNOME Shell systray/notification area would work fine in Unity even if the apps don't use libappindicator. Unfortunately, because of this failure of collaboration, app developers now have to make a decision about whether to write DE-specific code for systray/notification support across DEs... this is not progress. I hope there's enough motivation left to fix this...
Jamboarder,
That is good to hear. I very much want to encourage you as an application developer to write up your experience about using the KDE spec and the Ubuntu variant of the spec. I'd like to see as many application developers do that as possible.. in a dispassionate way and see if that helps build confidence that the spec is good enough to rely on.
Perfect is the enemy of good.
And this very well maybe an example of a situation where GNOME devs are endeavouring to build something perfect and overlooking the good. It happens to the best of us at times.
So please, application developers of all stripes, please try to accumulate some shared experiences with the spec in a venue that other DE implementers can read up on. Not just GNOME..there are other DEs out there that may want to write UI implementations around this spec that are different than what either KDE or Canonical has already implemented.
-jef
@Jef Spaleta:
> I take it this is the upstream patch reference:
> http://svn.reviewboard.kde.org/r/5699/
That's a followup to the GDM/ConsoleKit shutdown patch that was originally committed by ossi. The followup allows the Plasma workspace to shutdown using ConsoleKit even when no DM is in use at all, e.g. when it was started through startx. (ConsoleKit also supports that, so there's little point in not supporting it. My original patch also supported it.)
This is the reference for the original upstream patch: kde#186198. (AFAIK, Oswald "ossi" Buddenhagen looked at my patch when implementing the feature (it was linked in the bug report), but didn't like the way it was implemented and rewrote it from scratch.)
By the way, the GDM developers (William Jon McCann, mostly) didn't bother telling us about the interface change at all! We found out due to a user report, and I tracked down the GNOME patch which added support for this (which was a Fedora-specific patch too, that stuff wasn't even in upstream GNOME when it was rushed into Fedora) and made KDE use the same calls.
Kevin,
Again thank you the detailed record of interaction over the behaviour change.
-jef
Huh, what happened to my second part? (Only part 1 and 3 went through.) There it is:
> Would this debian related patch request be
> related to the issue as well with regard to
> KDM specific suppport for ConsoleKit?
> http://lists.debian.org/debian-qt-kde/
> 2007/11/msg00107.html
No, that's a different, basically unrelated issue. (The only common item in the 2 issues is ConsoleKit.)
This is about support for registering KDM sessions with ConsoleKit so ConsoleKit knows about the active session (see rh#228111), which came up as an issue when ConsoleKit was first introduced in Fedora 7. It is unrelated to using ConsoleKit for shutdown and restart, in fact, ConsoleKit didn't even support that feature originally, it was just a tool to track active sessions. (The ck-shutdown patch became needed in Fedora 10, see rh#475444.)
I also wrote a patch for that (on extremely short notice, just in time for Fedora 7), originally against KDE 3.5.6. There were several communication breakdowns: The ConsoleKit developers driving that change (David Zeuthen and William Jon McCann) filed a bug against KDM only after the switch to ConsoleKit had already been implemented, that was less than 4 months before the Fedora 7 release. That bug was filed as a clone of a bug filed against wdm, with a large copypasted discussion; it wasn't clear from the bug how urgent this was nor what exactly needed to be done, so Than Ngo didn't act on it, and as this was (just) before the Core/Extras Merge, the rest of KDE SIG didn't even see it. So over 2 months went by until (with only little over a month to the F7 release), it was finally pointed out (IIRC by David Zeuthen) how urgent this was, so I had to rush in a fix.
My initial patch didn't work at all (segfaulted), but S.Çağlar Onur from Pardus found the bug (a single typo/pasto) and we shipped the patch with his 1-line fix in Fedora 7. 3 months later, I ported the patch to the then-current development version of KDE 4 (3.91.0) and filed an upstream bug in the hope of getting the patch upstreamed into 4.0. In the meantime, some other distro folks came up with various fixes and improvements: Mandriva and Debian folks fixed some XDMCP-related crash bugs (the patch wasn't QA'd for all the uncommon use cases because there was no time for that, we were in a hurry for the F7 release), and fellow Fedora developer Patrice Dumas came up with a version of the patch using libck-connector instead of my copied/forked GPL code from GDM (the rest of the KDM backend is X11-licensed, and copied code also sucks for other reasons). (Note that I said "distro folks" there. No upstream KDE developer was involved, especially not the maintainer of the affected code, ossi.) After much back and forth (ossi nitpicking about some implementation details in my patch in an unfriendly and vague way, and Rex Dieter eventually managing to get him to tell me exactly what he didn't like and me to fix it), and over a year later, the patch finally got upstreamed into 4.2. At that point, almost every distro on the planet was shipping that patch (and sometimes an old buggy version of it).
Reposting part 3 to put things in order, sorry:
As you can see, I experienced bad communication and suboptimal cooperation from several camps: ConsoleKit (i.e. basically GNOME), KDE/KDM (in both instances, ConsoleKit developers were less than helpful announcing and documenting changes, and getting support for them merged into KDE was also an uphill fight), and also pre-Merge Fedora (community members weren't CCed on Core bugs even with the Merge being imminent). For the ck-shutdown patch, I also have to admit failure: I didn't even submit the patch upstream (myself, somebody else eventually did), for 2 reasons:
1. At the time, PolicyKit 0.9 was in use, which required the ConsoleKit client to do PolicyKit prompts when needed. I hadn't actually implemented this: If the policy was set to require authentication to shut down (e.g. if multiple users are logged in, ConsoleKit requires root authentication by default), the shutdown would just fail silently. (Thankfully, PolicyKit 1 fixed this, it's now no longer the application's job to bring up authentication dialogs for library policies, so that point is now moot.)
2. Along with the move to PolicyKit 1 (Fedora 12), ConsoleKit finally grew CanShutdown and CanReboot methods which were missing in the original interface, it took me some time to update my patch to make use of those, too. See rh#529644. (The absence of those methods in Fedora 10 and 11 sucked, I had to always show the Shutdown and Restart options when using ConsoleKit, with no way to know whether they'll actually work.) I didn't want to submit my patch without support for that, and once I had it, I wanted to make it support both old and new ConsoleKit and never got around it. (This is now also basically moot, nobody uses the old ConsoleKit anymore and the upstream patch also only supports the new one.)
3. It was also due to my bad experiences with the previous patch and to knowing the same maintainer was responsible. It turns out I wasn't entirely wrong, as ossi decided to rewrite the patch from scratch after somebody else submitted it.
Still, it's true that I didn't submit the patch upstream, so I failed, too.
Unrelated to the ConsoleKit stuff above, but still on topic:
About KDE and collaboration/integration:
1. Why does KApplication go out of its way to disable Qt's desktop integration?
QApplication::setDesktopSettingsAware( false );
I don't see any good reason to do this.
2. Why does KStyle::defaultStyle() always return "oxygen" on X11? The default style should be QGtkStyle when running in a GNOME session.
I don't use GNOME, but I do strongly believe KDE applications should try hard to integrate well into GNOME. After all, we KDE users and developers also want GNOME applications to integrate well into KDE/Plasma and write things like oxygen-gtk for that.
There are things which could be done to improve GNOME integration which are more work, e.g. respecting GNOME settings for things like icons on buttons when running in GNOME (QGtkStyle already takes cares of removing menu icons when they're disabled in GNOME and it's a GNOME session), but the above 2 points should be trivial and improve the situation a lot already.
I read the post with great interest. And I saw the names of people I came to respect for their work here from both major DEs and from Canonical. Being a developer (not contributing to any of the DEs however) myself, I am really tempted to get into a technical discussion. Yet, I will try to speak from the user aspect as it is certain from my own experience that it is most probable to expect different aspects on a subject, and best practices tend to be best practices when their my practices. Guys, for God's sake... I really think that everybody here should redefine what their goal is to some extend. I will not get into the politics stuff, politics happen because if they didn't happen, they wouldn't exist the first place. But really...
I am am a little more than average user being able to work at both 2 major DEs, willing to try Unity, and I read a flame like this, by people -I repeat- that I have learned to respect for their contributions. a)It's not a matter of whose fault it is, it is matter of what are the underlying goals, and whether in your agendas there is a common goal.
b)I spent a whole hour and a half carefully reading through all the posts and comments and unfortunately I came to start pondering about the future of Linux as a Desktop Experience. And it makes me think that it is becoming a matter of one for one and none for anyone. Dear all, how can one get tempted into using any DE when accusations fly from one DE dev to another (childish or not I really don't care, I always consider the truth to be in the middle to be honest) and trust that Linux will provide at some point an excellent experience to the end user. Think out of the box a little.. If I was a user getting software from someone and came to my attention that there was a quarrel between the devs (sharing more or less the same goal), would I trust this excellent piece of software to continue to be of the highest standard and quality?
I think it is all a matter of constructive rather than destructive conversation and IMHO what has been witnessed here to the average user is more destructive than productive to the goal behind OSS.
Kind regards
George Mamakis
@Jef Spaleta
CSD is really not a good example of how stuff development between Canonical and GNOME should work. I'm the person at Canonical who started CSD, but never finished it.
It started as just an experimental hack, and somehow got picked up as a "Canonical project". Once that happened my immediate manager told me to stop committing code to GNOME git and do any further work on it privately in bzr.
For me this made developing it further much more difficult, because it was an extremely large and intrusive change into GTK+ source code and my manager didn't want upstream developers to help me with at least peer code review.
I think participating with upstream developers is really important, not just writing code and throwing it at them and expecting them to take it. Before I joined Canonical, my previous employer allowed me to always work freely with upstream GTK+ people and I think it benefited me, my company, and upstream to work that way.
@Jef Spaleta:
"the Ubuntu variant of the spec" - You write as if libappindicator is a fork of StatusNotifier. It is not. libappindicator is a library for GNOME applications that will use the StatusNotifier DBus interface to display notification items, but will fall back to using traditional XEmbed System Tray if a StatusNotifierHost is not available (I hope I got the terminology right). This is why Canonical's app indicators display correctly in the KDE system tray as native StatusNotifiers and KDE's StatusNotifiers display correctly in Unity as the native AppIndicators. It is the same infrastructure with different visualizations and different libraries built on top of it.
bratsche,
thank you for relating that. I was really hoping CSD was a bright point. It is really unfortunate that your manager didn't let you work collaboratively.
-jef
@bratsche, @jono
> It started as just an experimental
> hack, and somehow got picked up as
> a "Canonical project". Once that
> happened my immediate manager told
> me to stop committing code to GNOME
> git and do any further work on it
> privately in bzr.
This is what you need to fix.
You said you wanted suggestions, consider
* Many Canonical projects require CA and all-but-require contribution and hacking to be on launchpad/bzr
* GNOME projects all-but-require code hosting to be on GNOME git, and all-but-require discussion to occur on the GNOME mailing lists.
Fair enough, that is reasonable. Each project sets boundaries and rules for contribution. But;
If you want to genuinely work with GNOME on technical matters then you *all-but-must do so under GNOME rules*. All I am asking for is consistency.
How does my proposal reflect on the Canonical patches for the nice shiny overlay scrollbars. Poorly.
Please fix that.
Client-side decorations (CSD) are also not a good example of cross-desktop collaboration, quite the opposite!
KWin developer Martin Gräßlin has pointed out several strong technical reasons why CSDs are an awfully bad idea: Why you should not use client-side window decorations, Follow up on client-side decorations, Open Letter: The issues with client-side window decorations, Technical limitations of client-side decorations. Yet GNOME and Canonical developers decided to push this through anyway, without really addressing any of the objections. (The only serious attempt to address them was this, and IMHO the arguments there weren't really convincing.) There also wasn't any discussion with KDE/KWin developers about this before it got implemented. KWin developers, on the other side, made it clear that they have no plans to support that specification in its current state (and will rely instead on the specification's backwards compatibility support, which makes GTK+ not show CSDs if the WM doesn't advertise support for it) and that they make no promises about it getting supported, ever.
"This is what you need to fix."
Dude, you don't think people know that? A number of people inside Canonical are aware of the problems, and for the last two years that I've been working at Canonical people have been discussing internally how to fix the problems. We don't exactly like that the rest of the development community hates us. But sadly, all that discussion of how to fix our relationship with upstreams seemed to only be discussion, and very little about the company's attitude towards upstream changed in those two years that I could detect. Now we're reading here about how everyone should learn from the past and move on, but how should everyone move on when there's no reason to expect things won't be any different? That seems like another way to say, "Let's not talk about this now since there is no real solution, let's just assume everything is cool until another issue comes up."
"If you want to genuinely work with GNOME on technical matters then you *all-but-must do so under GNOME rules*. All I am asking for is consistency."
You don't need to convince me of this. When I was first hired at Canonical, I expected that I would be doing this. In fact, I knew Canonical's reputation for not contributing code back to upstream projects and during my interview process I asked the manager who was interviewing me very explicitly, "Will I be working primarily upstream in git and Bugzilla in this role, or will I be working primarily in Launchpad and bzr?" He said something along the lines of, "You should expect *some* work in Launchpad and bzr, because it's a distro and all.. but for the role we're hiring you for, you'll be doing *most* of your work directly upstream in git and Bugzilla." Once I was hired, my contributions into upstream went to almost zero. Look at the commit logs. In retrospect I now realize that he was just trying to fill up his new team, and he was telling me exactly what he thought I wanted to hear. I suspect if I had asked Mark that same question he would have been much more straight-forward and truthful with me.
"Please fix that."
In general I don't think it's going to be fixed, but I would like to point out some instances where Canonical is doing the right thing. They've allowed Chase Douglas to work directly with the Xorg guys upstream for XInput 2.1 stuff, and I think the result will be a big win for everyone. I think part of this is that the multitouch team has a much better manager (Duncan) who understands what it takes to work with people outside the company and develop software in this type of world. He knew that the X expertise exists outside Canonical, and we should be working with the X community to get this done. Duncan didn't want that work to be done privately in bzr/Launchpad and then rammed down the throats of the Xorg upstream people. Hopefully more work is done that way, but I kind of doubt it. I hope to be proven wrong. :)
Anyway.. I'm no longer at Canonical (as of this week, actually), so I won't be involved in whatever change does or does not occur. But I certainly hope that everyone remaining does get to see some meaningful change, for their own sake, for the general desktop community's sake, and for Canonical's and Ubuntu's sake. I'd love if Canonical would work more with Gnome, the same way Chase has been able to work with Xorg.
@Kevin
"Client-side decorations (CSD) are also not a good example of cross-desktop collaboration, quite the opposite!"
That may be true, although I still don't agree with Martin on his reasons for disliking it.
But feel free to blame me for not engaging in the debate, even before my manager yanked the project into the private. As I described before, it started out as a totally experimental project. I think Martin or someone had already been complaining about it then, but I honestly didn't really care. I was just playing around, it wasn't any kind of official GNOME project in the beginning.
So definitely blame me for that not being a good cross-desktop discussion. Don't blame GNOME, and don't blame Canonical.
Here's my take on it:
http://www.binplay.com/2011/03/cripple-fight.html
@bratsche
Oops, sorry, I did not mean it to seem I was criticizing you. I was (poorly) referencing your post while replying to Jono re: suggestions
Sorry!
As a dev i only can say that i've quit Gnome since i saw Gnome 3 preview... Feeling like standarts of the old...
@bratsche
Thank you, thank you, thank you.
I have been hearing back-channel chatter along the lines of what you have stated in terms of internal corporate culture, but I could never get anyone to go on record, never found a way to have a starting point for a frank discussion of the influence of corporate culture on overall interaction. And I certainly never wanted to put anyone in jeopardy of losing their jobs in an effort to set the record straight.
So again, thank you.
I will endeavour to point to the Xorg work you refer to from now on as the best example available for Canonical doing collaboration right.
@sxj: "As an author of a non-kde and non-gtk/gnome application this makes it all very interesting. How many standards do we now have for implementing a simple tray icon? Counting 3 so far: Xembed, StatusNotifier and AppIndicator."
there are only two. AppIndicator is just a different visualization of StatusNotifiers. app developers should not, and indeed do not need to, care about the differences in presentation.
this is one of the key points of StatusNotifiers: app devs say "here is the relevant information for my application's entry" and the visualization takes care of it.
as for the 2 impementations that actually do exist: XEmbed and StatusNotifier, at least KDE supports both in the Plasma Destop Shell as well as in the class in KDE Platform, KStatusNotifierItem, that app devs use. this makes the XEmbed/StatusNotifier difference, from an app developer's point of view, an implementation detail.
it would be very nice for our users, however, to have only one method since then things would be more consistent and, in the case of StatusNotifers, a lot more powerful.
@Jef Spaleta: i was going to ignore your quote from a blog entry i wrote in early 2005 (yes, 6 years ago) but a few people have asked about it privately, so let me address that head on:
a) the dconf i wrote about then is not at all the dconf we have now.
b) the means being used at the time to make dconf a standard were exactly the same attitude as we're seeing here, only in reverse.
the flip side of "we aren't interested in what others do" is "we think everyone should simply adopt what we do".
there was no attempt at collaboration and examination of prior art or mutually acceptable approaches was missing.
instead, the idea was, "If we propose it on fd.o, then people have to accept it because otherwise they won't be cooperating with fd.o." this is completely different from trying to work with others and having those efforts ignored.
note that student working on the jobs d-bus GSoC project in GNOME was advices by his GNOME developer mentor to ignore KDE's dbus implementation and take the one he was working on to fd.o and use the org.freedesktop dbus name right away so as to "push it" into usage.
that was mid-2010, the early run at dconf was early 2005. this is why i call it a pattern of behavior.
it's the difference between a good citizen of a cooperative landscape, where differences are sure to arise and are ok, and a group intent on gaming the system as much as possible to their own ends. both are valid approaches in the sense we all have the freedom to choose between those avenues.
they do lead to different results, however, and i think our users and 3rd party app devs have a right to know how each party chooses to work with others so they can decide who to support and who not to.
@Kevin Koffler: yes, that really sucks about getting that kdm patch in.
however, it really was not about ConsoleKit and inter-project coop but a particular maintainer (/ human being) who is not the easiest to work with. trust me, i've gone through the process with a number of patches with ossi :)
i'd like us not to get confused between individual social graces (we can find highlight and lowlights of this in pretty much all the bigger projects) and the general mechanisms involved in collaborating on technology.
if ossi had had rejected it because it was ConsoleKit and that was dirty because it "wasn't KDE" then we'd have something to talk about here.
how to deal with snarky / unhelpful (even unintentionally) maintainers is an interesting topic, though. just one for another day perhaps :)
@Kevin Koffler: "Why does KApplication go out of its way to disable Qt's desktop integration?
QApplication::setDesktopSettingsAware( false );"
good question; seems that's quite an old commit and it should probably be tested without.
hardly malice at play, and nothing that a patch with some testing wouldn't fix.
"Why does KStyle::defaultStyle() always return "oxygen" on X11? The default style should be QGtkStyle when running in a GNOME session."
that should only be queried for the platform plugin or when there isn't one. ultimately it should just be a fallback.
that was, afaik, the theory for how it should be working already. is this broken, or did you just look at the code and surmise that it must be broken as a result?
@Kevin Koffler: "Why does KApplication go out of its way to disable Qt's desktop integration?
QApplication::setDesktopSettingsAware( false );"
so, looking at the code in qapplication_x11.cpp, the only place this is actually used, it appears that when it is set to true that it sets fonts and colors to the desktop defaults, which includes reading (or re-reading!) the defaults from e.g. KDE.
with platform plugins and the other code in libkdeui this looks to be duplication of effort and so not needed, which is almost certainly why it is turned off.
again, nothing supporting a "not playing with others" attitude.
@Jef Spaleta: "They use the same underlying "spec" in terms of communicating between the platform control UI elements and the application itself. But the platform provider has a lot more flexibility in saying what is allowed or disallowed to be expressed in the UI. And application writers have to prepare for a situation where different UI platforms express and expect different interaction behaviour from a user."
yes, that's really a primary point of StatusNotifiers: if the app dev should not care nor rely on any specifics as to how the representation works. why?
because those details may change over time or between implementations. so if your systray icon is doing something unique, it's going to stand out and ruin consistency.
when looking at what apps which had done such things were doing, it was _always_ to abuse the system tray area. there was not a single redeeming implementation of "doing something unique!" that we found, and we looked.
when the app dev only cares about the information being provided and reacting to interaction cues, rather than the actual specific look and feel (or interaction), then different implementations over time or between projects can maintain consistency. that includes being able to reliably offer things like non-gui representations or different interaction modes (mobile touch versus desktop mouse and keyboard, e.g.).
the user wins, the shell developer wins .. and ultimately the app dev does.
"That may or may not cause problems for application developers who want to have their indicators used in specific ways for the multiple platforms making use of the underlying spec. "
so far, with hundreds of apps using the new spec already, this has not been an issue. where valid use cases have arisen (in the early days as we were porting applications), we made adjustments as necessary. other than that to be expected initial growth, new use cases have not arisen that were unmet.
if you can provide specific use cases, then we can examine them. just as we have others.
hand waving that it "might not work" isn't useful. the decision to remove visualization decisions from the app developer is, however, very purposeful and based on a specific and well enunciated idea with stated benefit.
@sicofante: "As a user, I couldn't care less about the behind the scene issues you guys are talking about."
you don't care that you can drag and drop or copy and paste non-text items between apps?
or that you can log out, reboot, switch sessions, etc.?
or any number of other things that only work because f/oss projects work together...
i understand that the connection isn't immediately evident and that it is indeed buried behind technical efforts and lots of code, but it absolutely does affect you as a user.
it not only impacts how well things work together, but the quality of the results and how quickly they end arriving on your system.
if this really had no impact to the user, i would have stopped banging my head on this wall years ago.
Reading all this... I can't believe this in-fighting. Let's have a quick compare/summary:
KDE - builds good looking, plays-well-with-others software. Clean OSS.
Gnome - rebuilds that software and claims as it's own - Microsoft!
@Canonical (sabdfl, jono) - I genuinely hope this pushes you towards KDE (or at least pure Qt) in the long run. If Gnome don't want your help then I say let them rot.
This whole conversation has put me off using a Gnome desktop anytime in the future.
(whoops, just leaving this here so I get email followups!)
@Sicofante
Reading your post I couldn't believe in what you wrote. :) KDE's inconsistent? This is one of the best jokes I've ever heard. In KDE probably every KDE SC application is consistent (unlike in gnome, which is a real mess in this case) - you've got options in the same places, you've got very nice looking theme, you've got many features that are needed for normal desktop usage (unlike gnome), it's more user friendly - you have a single panel as default, open dialog is far better than the strange thing in gnome, there are window buttons etc. I was shocked when you have written gnome is consistent, because it's very inconsistent.
Here is all I care to know about appindicator: Install a recent version of Ubuntu. Right click on the stupid Twitter icon and choose "remove." The clock disappears. Shite.
@Aaron J. Seigo
I see. Guess holding my breath would have been a good idea after all. I didn't expect that :)
This is awesome.
Hello Aaron, I have been a dirty end user of Linux since the beginning of 1999 as well as a KDE user and I have to say, unlike the closed source world there is never a dull moment in the FOSS community. From the Richard Stallman/QT debacle, Mosfet's angry abandonment KDE and his developing of FOSS. the Icaza/Friedman roller-coaster and the guys from Eazel trying to make a go with the creation of Nautilus.
The FOSS landscape is always changing and improving. What I am saying it that Everybody that touches FOSS leaves a mark...a little bit of themselves that makes FOSS better in some way. The Idea that there is open discussion about problems with the way a Dev team works with companies,individuals and other projects outside their own is a good thing. People like to make statements that this openness hurts FOSS compared to closed source but, that is just foolish. Open discussion leads to a transparency that, a good portion of the time will lead to positive changes.
I follow these discussions even though I may not completely understand the technical aspects of the issues ( I am just a dirty end user after all) But, I feel that it is a disservice not to observe the FOSS community going about it's business. So even if I don't completely understand the technical issues involved I can at least "feel" the tenor and direction of the various developers and projects I enjoy using every day. This is actually a loosely based reply to "Fred" for his very disparaging remarks toward FOSS and all the fine projects and developers that he essentially called useless.
Girls! Stop fighting. We love you both! Really.
Please just let our laptops and desktops be what they are meant to be and don't turn them into some freaky iPhone like consumer devices. (You know who you are...)
Please don't follow the Microsoft way of releasing a pre-alpha buggy version as a major release. Vista didn't make anyone happy. Really. (You know who you are...)
Also keep in mind, squabble, argumentation, contradiction and competition are in fact healthy, powerful driving forces for progress and evolution. If you'd both do the same thing and always agree you'd die. But take competition too far, stop collaborating and we're gonna get hurt. That's when we'll put you on the same list Apple and Microsoft and you'll die.
Find the bloody middle way.
Finally from me: thanks to both Gnome and KDE communities for delivering on long years of quality, beauty and functionality.
@Jef "No, but not rejecting it does not imply that the GNOME community supported it above and beyond ODF. Jody's interest was to ensure that FLOSS products could implement it at all, so users had some hope of interoperability."
It's this kind of weaseling that's been wearing gradually thin over the past ten years. It's not directly related to what Aaron has posted, but it is related nonetheless.
Rushing to support a format that few people used at the time and where everyone knows it has proved practically impossible to share files with Microsoft Office wasn't the most productive thing to be doing. Like it or not, it appeared that Gnome as a whole was supporting it before proper ODF support was considered a priority at all.
I'd call that supporting it. Trying to back out of it by arguing that they were neither for or against it is just a way of trying to slide out of any accusation being levelled.
Frankly, that's been a consistent theme amongst some prominent community members over the past decade.
@Aaron J. Seigo: "App developers should not, and indeed do not need to, care about the differences in presentation."
In theory, yes. In practice for example, there are multiple ways to show a context menu (either done by the application or by whoever manage the items like appindicator/dbusmenu). So you end implementing a lot of duplicate functionality due to the way the spec is rather broadly defined.
Now, don't get me wrong, I do like the StatusNotifier spec and yes, it's api is pretty much fixed cross-desktop, but I am concerned the number of ways it can be used. (and trying to document that). I cannot say in my documentation that right-click will open the context menu because that may not be implemented.
@sxj: "you end implementing a lot of duplicate functionality due to the way the spec is rather broadly defined."
not at all; the application publishes a menu associated with the StatusNotifier and it gets shown. the application does not implement any duplicate functionality. if an app is, then it is doing it wrong(tm).
"I cannot say in my documentation that right-click will open the context menu because that may not be implemented."
this is true; you can document per-desktop environment or you can leave it up to the user to know how to use their environment and simply refer to it as the "context menu" and not get into specifics like "right click on ..".
the application shouldn't be involved in that, however, since it is part of the desktop shell. it does mean adjusting what we are used to being able to document and where the lines between "my application" and "the environment it works in" are, but so be it.
the same is already true for things like file dialogs, dialog button orders and more.
@sxj
I cannot say in my documentation that right-click will open the context menu because that may not be implemented.
You might be able to say in your documentation "open the status icon menu" just like you can say "maximize the application" or "minimize the application" without needing to tell the user which button to click. You can to rely on the users familiarity with their chosen environment to know how to do that. I say this as a developer who has used the KDE implementation of the spec and see how well my apps integrates in other non-KDE environments that support the spec even though the visualization approaches are different.
There are many real-world apps out there already to look at to see if there is a real, practical limitation that isn't outweighed by the flexibility it provides both to app developers and visualization/DE developers. And if there is, hey maybe with some feedback the spec can be updated. :-)
@aaron,
You "might" be right about my hedging.
I'm very exciting to see discussions between application authors who are learning to navigate between different UIs that are making use of different implementation of the same spec concerning best practises on how to approach it.
If the hedging is unfounding then some consensus best practises on what to do and what not to do as an application developer should be able to coalesce without much difficulty and give additional confidence to those who have so far hedged or been sceptical.
The discussion you and Jamboarder are having with sxj is useful in that regard. Far more useful than anything I "might" say.
-jef
There are also other things which aren't good for end users. The confirmation buttons were swapped from some reason in gnome which only shows they're doing everything to be incompatible with KDE. This just makes users more confused.
> Those days seem to be receding into the
> past however as GNOME seems
> increasingly content to "do their own
> thing".
Hey, I used to support KDE1, KDE2 and KDE3 but KDE4 with databases and devils has finally made it over the top.
Aaron, are you going to deliver what people ask for and not some visionary crap *yourself*?
Thanks, anyways.
Research of the Free Software Ecosystem
1. Interoperability
While most users don't really anticipate the use of standards, when we look at the big picture it's something the developers should bother themselves with.
A user experience on a desktop environment, lets say GNOME, is what the desktop provides him with.
But what happens when another user, who use a different DE (ex KDE), doesn't really have the ability to communicate, in terms of software technology and configuration, with the other?
The problem lies in standards.
Lets take a really simple example for that.
Say that user A has an icon theme in his system which he likes. Now, user A shows this icon theme to user B who uses a different DE.
With the current situation, he cannot share this icon theme with him because those two DEs use different approaches for this task. Simply put, they are not compatible.
The same goes for toolkit styles, program intercommunication (for ex, dragging a file from dolphin to Filezilla simply doesn't work), configuration patterns and resources.
We see some improvements on some fronts, take for example the recent Qt ability to adopt to a GTK+ environment, sharing the style theme, the color scheme and fonts.
Now that's what I call Free Desktop Interoperability.
The good news is that we already have organizations committed to provide standards for the Free Software world such as ISO, freedesktop.org etc..
The sad news is that not everyone take those standards into consideration when they design their applications.
Of course this problem was much bigger in the past years, however things are slowly moving to the right direction.
2. Resource wasting / Duplication of effort.
While having options is a great thing, that doesn't necessary mean that every project should be isolated from the other.
I see what KDE does with it's libraries and how every kde application uses those libraries to achieve things already implemented in various forms and places inside KDE.
You don't have to write a text editor from scratch if you need one in your program. You simply use kate's codebase (kpart). You don't even have to copy and paste this code to your program, you simply call it at execution time and the relevant piece of code get's executed inside your program.
This is obviously a great approach to the “effort duplication problem”, however it's limited only to KDE and KDE related apps. If your want a GNOME program to use those features you can't.
So how about this:
We create a set of libraries which everyone can use on their applications, and I mean EVERYONE.
I'm talking about the KDE approach, but for the Free Software Ecosystem as a whole.
That way, everyone can use the technologies provided by those libraries, everyone can support and expand those libraries and everyone can work together for the evolution of their respective programs which use those libraries.
Of course that's not something that can happen for everything, but many things can be implemented for that.
For example, if you want to use Qt as your toolkit while another one uses GTK+, you don't have to have a library which provides both toolkits, that would be stupid. But the common things that programQt and programGTK use, could be implemented in a shared library.
I hope you see my point and I'm looking forward to feedback.
Libfreedesktop ftw :D
@gvy
The obvious troll is obvious - otherwise you would give some examples what's wrong. Aaron and co. gives me opportunity to have the most feature rich, the most usable and the nicest DE in the world. Big kudos for this!
GNOME was made with the intention of undermining KDE. Why else would they whine about licensing, start two parallel projects (GNOME and Harmony) and then cancel only one when their concerns are resolved?
There was no reason to make GNOME at all other than to undermine KDE because the GNU people suffer from serious NIH.
Given that, I am not surprised that they do not want to work with the KDE people. I think the best solution is to push forward without them. KDE does not owe GNOME for anything. Let KDE be the leader of the UNIX desktop and let GNOME rot.
I'm not a GNOME or KDE developer/representative, but from reading the XDG mailing list thread Dan Winship pointed out, and several of the comments here, I think the main problem is that people have differing opinions on exactly what kind of information the spec should provide, and the level of detail it should go into. To try and summarise Dan's criticism, if I may, his main point seems to be that the spec doesn't make it clear how the information an application provides will be used. The counter-arguments seem to be along the lines of "people implementing status notifier hosts will be sensible", "we've already implemented it therefore it's fine", or "that is intentionally unspecified". This to me demonstrates a fundamental misunderstanding of the point Dan was trying to make, and whilst I don't claim to have the best answer for where he should have gone from there, I personally think he can be forgiven for feeling a bit disheartened.
The document should strive to be sufficient reading for anyone who wants to implement a status notifier host, or for anyone who wants to implement an application which provides status notifications, and I'm inclined to agree with Dan's assessment that in its current form, it is insufficient for either purpse. This is simply because there *has* to be some description of how the information provided by an application should be used, and there *have* to be some limitations on hosts with regards to what features they must implement (and which are optional), otherwise developers will be left scrabbling around looking at what other people have done to try and figure out what works. When you reach this point, the spec document might as well not exist: since it does not define a standard treatment of the information provided, there *is* no standard, just a bunch of libraries which happen to accept similar information and do vaguely similar things with it.
One of the specific examples mentioned early in the thread is to do with overlay icons. Dan said:
Either it is guaranteed to be overlaid over the main icon, or else it isn't. If it isn't, then no one will use this property, and they'll just change the main icon instead.
I think this is reasonable criticism, and the response "it's up to the visualisation" is far too vague. Dan never said the spec must state *where* it must be overlaid, or that it must appear at a particular size, or with a particular border/shadow style, or fade in/out with a particular time step, or... you get the picture. Just that it must be displayed as an overlay. If it isn't going to be displayed as an overlay, why is it called an overlay icon? Why have it in the spec at all?
Now, to be fair, the spec doesn't actually *say* that status notifier hosts may choose to discard certain information, but when taken hand-in-hand with some of the comments the mailing list thread, it might as well. Vague, inconsistent and imcomplete wording has resulted in a spec which basically says "call some methods and stuff may or may not happen", to which your response seems to be "yeah, so?"
Dan's other misunderstood example is to do with the provision of a window ID. Again, the spec says you can associate a window ID with a notifier, but not what a host is expected to do with that ID. This is pretty fundamental, because otherwise there is absolutely no point in having this in the spec. One of Dan's comments:
Let me try this again. Suppose you have:
- KDE implementation: If WindowId is set, then raise that window to
the top if the user clicks on the status icon.
- GNOME implementation: If WindowId is set, then *destroy* that
window if the user clicks on the status icon.
You are saying this is perfectly legitimate and StatusNotifierIcons are
expected to cope with it?
Your response:
yes. ignoring that the example given is a bit absurd, it is completely within
the realm of possibility.
Maybe if it's "absurd", the spec shouldn't allow it? Dan's point is that I could write a host which does whatever the hell I like to the window matching the given ID, ranging from "raise it" through to "maximise it and turn it bright pink" through to "nothing", and technically I'd be compliant with the spec. The spec notes that an application can set it to 0 if it's not interested - not interested IN WHAT!? As an application developer I would most certainly not be interested in having random things happen to one of my windows, because the spec certainly doesn't tell me what *could* happen!
Fix the spec, and maybe people will be interested. Saying "developers won't be that stupid" or "look at what existing implementations do" is not good enough, because then you haven't provided a specification, you've provided a bunch of code which does stuff and a vague suggestion that maybe other people's code might want to do likewise.
Aren't there any agreed and accepted ways of colaboration between different projects like KDE, GNOME and others? Now that would be really odd...
@ mangobrain: once again, you are missing the point. This is intended to be used by a functional, useful piece of software. Of course it is possible to do something completely bizarre and illogical. But that is the case with lots of other areas as well. Of course it is possible to for a window manager to do something bizarre and illogical, but that is not an argument for client-side window management. Of course it is possible for task manager to do something bizarre and illogical, but that is not an argument for giving applications control over painting of task manager entries.
The assumption is that this spec is going to be used by actual real-world software intended for use by real people. There is a certain assumption that the people implementing the spec are not going to behave in an insane or malicious manner.
The problem is that it is impossible for the application developer to anticipate every possible valid use for the spec, so it is impossible for them to properly control how the information they provided is used.
Let's use your example of window ids. For a standard system tray, the window id could be used for raising the window when you click on a notification. However, in a system where the notifications are embedded in the task manager, it could be used for making sure the notifications are associated with the correct taskbar entry. For window decoration buttons, it could be used to put them on the right window. And who knows what sort of other uses could be found for it in the future.
This sort of thing makes it impossible to specify what the window ID is going to be used for. The application developer would need to know every possible use for the spec, including many that haven't been thought up yet, and then explicitly set each one.
On the other hand, they could just say "I'm going to assume that someone using this spec isn't going to intentionally screw over his or her users".
Let's look at this more directly. Let's say that there is an implementation that closes a window when you click on it. We need to assume that there is a good reason for this, otherwise nobody would be using the implementation so it would be a moot point.
If users want to use a visualization that closes a window when you click on it, who are you to tell them that they can't? Why should it matter to you, as an application developer, when and where users choose to close your application's windows? Why is it so important that you know this is going to happen?
You assert that you would need to know this information, but you don't explain why. An application that publishes window ids should be able to handle commands sent to that window ID. It shouldn't need to know where those commands came from or why.
I would say that an application that can't deal with standard requests to close a window is a broken application.
@toddrme2178: You actually give some interesting use cases for the window ID stuff, which make it clear why the spec may be vague on that point. But that is *not* what Aaron did on the mailing list, he just said "yes, that's up to the visualization." - since it's clear that Dan was already confused as to the purpose of this point in the spec, don't you think a somewhat less dismissive response to Dan's comments was in order? A response like yours would probably have worked wonders, and words to that effect in the spec itself (explaining *why* it's so vague; perhaps an extended preamble setting out the design goals and rationale) would be even better still, because then it would be in the spec for all to see.
I notice also that you've conveniently ignored my point about the overlay icon, though, and so it still stands: if it isn't guaranteed to be an overlay, don't call it an overlay. This kind of thing *matters* when laying out specs and APIs which are ideally going to be used for years to come.
@ Philip: All of those examples came from the email discussion.
Further, immediately after that email Aaron provided a follow-up where he explained the rationale in more detail. He didn't include those examples, but he did include roughly the same explanation.
The reason I didn't respond to the part about overlays is because I thought they followed naturally from what I said about window IDs.
You seem to be missing the big picture here. The point is that application developers provide data they think is relevant to their application, and visualization developers show information they think is relevant to their visualization. Application developers need to trust visualization developers to know what information is actually useful to that visualization, and the visualization developers need to trust application developers to know what information is actually useful to that application.
Application developers need to assume that visualization developers are not stupid or malicious. If overlay icons provide information that is relevant to a particular visualization, then application developers can trust visualization developers will use that information.
However, there are many cases where overlay icons do no provide any information relevant to the visualization. In those cases, using the overlays anyway would be useless at best and harmful at worst. It is up to the visualization developer to know what sort of visualization they are trying to make, the application developers don't need to know or care.
For some examples where overlays wouldn't necessarily be useful:
1. Simple control interface. This just lists notifications that have controls, letting you manipulate those controls in a convenient manner. This doesn't care about status or notifications, it is only about controlling applications.
2. Task bar thumbnail controls. This puts buttons on a taskbar thumbnail. Once again, status is not necessarily important here, it may not even have the icon to begin with. Further, yhe overlay could go on the taskbar icon or on the thumbnail itself instead of on the icon provided by the notification.
3. Window title bar controls. Once again, this is only concerned with controls, so status is not necessarily relevant. Or the overlay may go somewhere other than on the icon the notification provides.
4. Really small icons. There simply may be no place for overlays, or they would be too small to be visible, or they could obscure the icon, so they might be eliminated or they could go next to the icon instead of on it.
But I shouldn't have to provide examples in every case. The point is that the application developers should assume that the information they provide will be used if and only if it is relevant to the visualization. They should assume that visualization developers are competent enough to know when, how, and if to best show the information available to them.
If the a particular piece of data isn't used by a visualization, the application developers should trust that there is a good reason for that decision and respect it. It is not application developers' place to force their views on visualization developers.
They should still provide the information, since for existing common use-cases like the system tray overlays are important. But they should accept that this won't always be the case any.
Post a Comment