Give GNOME 3 time
Posted Aug 16, 2012 16:53 UTC (Thu) by pboddie
In reply to: Give GNOME 3 time
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.
to post comments)