GNOME and the way forward [LWN.net]

GNOME and the way forward

Posted Aug 18, 2005 2:56 UTC (Thu) by mem (subscriber, #517)
Parent article: GNOME and the way forward

Part of the problem is that while GNOME developers bitch about "an inconsistent user experience" they have gone out of their way to provide a consistent user experience that's *inconsistent* with the rest of the only environemnt where GNOME actually runs.

Take middle click pasting. Sure, it's not Microsoft Windows, but it *is* the way the X Window System works. The X way is non-intuitive for long-term Microsoft Windows users, but it's expected behaviour for long-term Unix users. The argument against the X way, at least the one put forward by GNOME developers, is that in the X way selecting with the mouse destroys the information in the current selection. A short trip to the X Window documentation reveleas the difference between "selection" and "cut buffer". When you select something with the mouse you destroy the information in cut buffer 0, but the other buffers remain intact.

Sure, there's stuff that can be fixed in the system and there *is* stuff that's broken (cut and paste of complex data just doesn't work -- e.g. selecting something in the Gimp and pasting it in Inkscape -- mostly because the programs can't agree on an interchange format, and IIRC Jim Gettys came with a proposal for fixing that). The point is that that isn't a reason to go ahead and plain ignore it.

Try for example Epiphany. It's a TOTAL MESS. Sometimes you have to go to the location bar, select and hit copy, sometimes selecting is enough. Selecting in another program and pasting to Epiphany is even *worse*. Why this? Because GTK+/Gnome just can't play nice with the rest of the environment.

GNOME's "consistent user experience" actually means "to comply with the expectations of the users of a different environment."

(Log in to post comments)

GNOME and the way forward

Posted Aug 18, 2005 3:22 UTC (Thu) by hp (subscriber, #5220) [Link]

For the specific example you cite (clipboard, cut-and-paste) there are guidelines that pretty much everyone has agreed on:
http://standards.freedesktop.org/clipboards-spec/clipboar...

These guidelines are believed to spell out the intent of the ICCCM version 2 from 1994. So blaming GNOME isn't really accurate. The cut buffers you mention were considered deprecated in the ICCCM at that time, replaced by the CLIPBOARD selection for a variety of reasons.

All the recent GNOME/KDE/Mozilla/OO.org stuff works the same way as documented at the above URL, modulo any remaining bugs but my experience is that stuff follows the guidelines. Even on old UNIX systems, there were a number of apps that used these cut-and-paste guidelines, they are not exactly new.

Finally, as documented in the first point in the GTK+ 2.0 release notes in 2002, there is a config option to turn off the select-text-on-focus behavior and the ctrl+c/ctrl+v keybindings if you like.

GNOME and the way forward

Posted Aug 18, 2005 3:58 UTC (Thu) by jamesh (guest, #1159) [Link]

You realise that the X selection mechanism was designed to replace the idea of cut buffers in X? Quoting from the 1988 O'Reilly Xlib Programming Manual:

Cut buffers are provided as a simple but limited method of interclient communication. Cut buffers are sometimes used by applications that use the Andrew toolkit. The concept (but not the implementation) of cut buffers was inherited from Version 10 of X. The selection mechanism is superior for many applications since it allows communication regarding the type of the data transferred.

So it isn't surprising that a toolkit written after 1988 would be written to use the selection mechanism in preference to cut buffers.

As with cut buffers, you can have more than one selection. The two most commonly used ones are PRIMARY and CLIPBOARD, both of which GTK uses. When you select a piece of text, the application acquires the PRIMARY selection. When you middle click in another application, that application requests the contents of PRIMARY in the form it wants. When some other application acquires the PRIMARY selection, the first app deselects its text.

The CLIPBOARD selection is used for the traditional cut/copy/paste operations, and should not interfere with X-style select/middle-click. This all works correctly in GTK if you are using the standard widgets. If an application uses custom widgets or has complex data to cut/paste it will need to have custom selection code, which may have bugs in it (although it is a lot easier to implement with the GtkClipboard interface added a few versions back).

With regard to Epiphany, note that it embeds Mozilla. Mozilla's selection behaviour seems to be quite broken: conflating PRIMARY and CLIPBOARD, not deselecting text when someone else acquires PRIMARY, etc. This just confuses matters, and there is a limit to what Epiphany can do until Mozilla is fixed.