GNOME and the way forward
Posted Aug 18, 2005 3:58 UTC (Thu) by jamesh
In reply to: GNOME and the way forward
Parent article: GNOME and the way forward
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.
to post comments)