Give GNOME 3 time [LWN.net]

Give GNOME 3 time

Posted Aug 16, 2012 16:53 UTC (Thu) by pboddie (subscriber, #50784)
In reply to: Give GNOME 3 time by krake
Parent article: The GNOME project at 15

You came up with wording that made it sounds like entitlement, which Havoc simply pointed out.

I merely stated that the inter-project collaboration hadn't produced as many results as it could have in precisely the areas where such collaboration could have paid off. Lots of people write client and server code to handle Internet protocols that doesn't need to link to a bunch of desktop or GUI libraries, but instead we have the end-user experience equivalent of one plus one not equalling two because people apparently don't want to write some service-level code without sucking in libraries that other people don't want to use.

Maybe to use the word "promised" instead of "anticipated" was unwise, but my impression was that people were committed to pooling effort and not reinventing the wheel. Things like the Desktop Summit were held. Instead, we now have more dilution of effort than ever before.

For your information, I don't feel entitled to anything from the KDE or GNOME developers. However, I find it very sad that where I could have comfortably recommended something like the KDE version I use every day to a new user a couple of years ago, I can only apologise for the workarounds the current versions of these projects seem to demand of their users in order to perform the same tasks.

Now on the subject of opening programs...

Being that someone I'd like to emphasis that this was intended to be a short-term stop gap solution because its behavior cannot be guaranteed to be stable (due to delegating to many different tools) nor does it provide most of the features application developer using launcher APIs grew accustomed to.

All you need is agreement from everyone that certain tools will be around to do the job. As you already mentioned, getting agreement when no-one can see the point ("developers using GNOME or KDE libs" wondering why you don't just fire up some internal mechanism or other) is pretty tough, but maybe then you have to be the one providing the stability for everyone else.

I passively maintain a Python library for launching applications that pre-dates xdg-open and was recently notified that kfmclient has been renamed to kioclient in KDE 4 but takes the same options. All I need to do is to wonder briefly how hard it would be to make a symbolic link for compatibility before just getting on with adding yet another corner case provided by a bunch of people who can't even agree on a name and a bunch of standard options for a program that they and everyone else provide.

I find it pretty ironic that "failure of collaboration" comes up in a reply to a posting by Havoc, a person who has put unparalleled efforts into *the* collaboration enabler: D-Bus

D-Bus is but one mechanism that should make decoupling of, say, WebDAV access services from graphical clients easier so that the developers of the latter can leave the work of the former to others. In any case, had enabling collaboration led directly to the decline of actual collaboration, you would genuinely have an ironic situation. I didn't link these two things, however.

(Log in to post comments)

Give GNOME 3 time

Posted Aug 16, 2012 18:49 UTC (Thu) by krake (subscriber, #55996) [Link]

"...because people apparently don't want to write some service-level code without sucking in libraries that other people don't want to use."

Quite the opposite. Prior to having an established and shared service communication framework (D-Bus) the only viable options were collaboration on specifications and low-level libraries.
The people involved were aware of the decoupling provided by a service based approach, oherwise D-Bus would have never received the buy-in it has today.

But it is important to understand that creating such a technology and respective application developer API and raising awareness of the benefits over its drawbacks takes some time and that having the means doesn't automatically imply replacements for existing implementations happening either.

"...but my impression was that people were committed to pooling effort and not reinventing the wheel."

I think your impression is correct and also that this has indeed happend. A lot of shared infrastructure has been created and is being used not only by "the big guys" (GNOME, KDE) but even by individual application developers.

"All you need is agreement from everyone that certain tools will be around to do the job."

I don't think any of the tools got removed or altered in an incompatible fashion, but not all tools necessarily export the same feature set (e.g. Thunderbird initially? did not support attachments in mailto URIs).

Another difficulty was that e.g. xdg-open used the best available tool for a given task, which however might not have been intended to be basically the runtime equivalent of public API (thus not necessarily being governed by the same strict policies).

"As you already mentioned, getting agreement when no-one can see the point [...] is pretty tough"

That's not what I meant. Sure, not being aware of a problem makes it difficult to see the need for a solution, but that never resulting in people blocking a solution. It just shrinks the pool of people available to work on said solution. Surprisingly those in need of the solution (e.g. people working on a technoloy stack without launcher API) are even less likely to contribute, making it even less likely to draw resources from those who are already covered.

"...and was recently notified that kfmclient has been renamed to kioclient in KDE 4 but takes the same options."

Actually kioclient is an additional tool that does have fewer dependencies (and is therefore always available, not just when the KDE workspace is installed).
It even comes with a simplified interface named kde-open which is specifically intended for use cases like xdg-open, while kfmclient had such capabilities just incidentally, its purpose being a console interface to KDE file manager program.

"All I need to do is to wonder briefly how hard it would be to make a symbolic link for compatibility..."

Which would have made sense if kioclient had replaced kfmclient and I am sure that is what would have been done. Anyway, purely hypothetical due to stories about kfmclient's death being hugely exagerated :)

"D-Bus is but one mechanism that should make decoupling [...] easier"

Sure, but the irony I was referring to was not that D-Bus would have had a negative effect on collaboration (it had a very positive effect), I was referring to the, let say call for collaboration, being posted as a reply to a comment by a person who has figuratively enabled a new universe of collaboration.