Give GNOME 3 time [LWN.net]

Give GNOME 3 time

Posted Aug 15, 2012 22:15 UTC (Wed) by pboddie (subscriber, #50784)
In reply to: Give GNOME 3 time by hp
Parent article: The GNOME project at 15

If you don't want to get labelled as hate, you should take out the phrases that ascribe motivations to others. For example:
the developers are presumably obsessed about a specific choice made in the early 1980s by someone at Apple
Sounds pretty unlikely to be true.

Well, that's what it seems like because double-click to do the common thing certainly isn't very ergonomic. What's the real reason for doing double-click apart from it having been done on the Mac because the Mac had one mouse button and various platforms copying it? I seem to remember Windows 95 doing away with double-clicking for many operations, but I imagine that the users revolted and this misfeature survived another generation.

collaborated properly (as promised)
Sounds like you're saying you know exactly what the issues are here better than the developers and are implying that "the developers" (not a monolith; this is open source) broke a promise to you (I doubt there was some sort of promise to implement webdav to your satisfaction).

Thanks for using the "entitlement" argument. To take an example, I remember following the discussion about having a cross-desktop standard way for launching applications. Instead of initially doing the simple thing and having a simple well-known named program to do this, discussions about dlopening dynamic libraries were indulged instead and then nothing happened for a few more years until someone eventually wrote xdg-open which did, at least when released, all the hacks that everyone was already having to do themselves.

simple scripts that wrap stuff like wget
This makes it clear to developers that you have no idea what's involved.

Let that be your opinion, then. I see that you cut the bit about such things being a quick hack.

menu-stealing masquerading as innovation
You're implying that the developers are trying to impress you with BS "innovation" claims, rather than making what they think is the best decision.

They're trying to do both, although I would again argue that they're unduly influenced by the Mac: I remember arguing with people about this on the Internet almost twenty years ago, so times don't really change on this front. And they're certainly making claims of innovation in case you don't read Mark Shuttleworth's blog.

In short you do not know what the issues are here, but you're telling other people they are incompetent jerks with evil motivations. That's why you get labelled as hate.

Thanks for projecting a bunch of stuff onto what I wrote in order to make me look like the bad guy for complaining. Perhaps you can indicate the precise mix of criticism and unbridled praise with which people can make suggestions to projects in order to be heard and heeded because there are quite a few people who spend their time trying to suggest improvements only to be told that they aren't "designers" or don't understand the issues.

It would suffice to say "I wish webdav worked in Nautilus and interoperated with KDE, here's what I try to do that doesn't work" (if it isn't there already, saying it in a bug tracker would be ideal).

I think there's an essay that covers spending time writing comprehensive bug reports only to see them closed by people who can't bear to have open bug reports in their tracker.

(Log in to post comments)

Give GNOME 3 time

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

"Thanks for using the "entitlement" argument."

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

"Instead of initially doing the simple thing and having a simple well-known named program...."

There was just no way to create a simple program for doing that without either replicating the already existing implementations or generalizing one of the existing implementations enough to provide an acceptable dependency for a new stand-alone program.

Which naturally lead to "..discussions about dlopening dynamic libraries..." so programs could use the currently prevalent implementation without tightly depending on it.

A natural compromise in the face of a shared goal and limited resources.

"...then nothing happened for a few more years..."

The unfortunate reality was that there were simply to few resources to implement a medium term solution given that he majority of application developers already had access to a launcher framework (i.e. developers using GNOME or KDE libs).

"...until someone eventually wrote xdg-open which did, at least when released, all the hacks that everyone was already having to do themselves."

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.

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

Give GNOME 3 time

Posted Aug 16, 2012 16:53 UTC (Thu) by pboddie (subscriber, #50784) [Link]

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.

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.