Re: commit -- more clipboard functionality

Justin Bradford (justin@ukans.edu)
Sat, 24 Jul 1999 20:22:31 -0500 (CDT)


> As far as I know GTK only does the Selection stuff for you... and it's
> just a wrapper to the X Selection stuff with some code to interpret
> targets for Motif, etc.
>
> It's all hanging around in gtk-1.2.3/gtk/gtkselection.[ch] and
> works like the X selection stuff.

You're right the GTK selection code is mostly a wrapper to normal
XSelections, but it does handle some annoying things for you, like
initializing all the extra atoms (TARGETS, MULTIPLE, etc) and dealing with
te INCR type (which I believe is a series of "chunks" of data).

Also, much of the selection code is similar to the xdnd code (which also
uses the selection mechanism, just abstracted some), so it would be a good
base for handling drag&drop someday for both xdnd and Motif (which is
basically everything on UNIX systems).

It won't take too much work to flesh out the cross-app unix clipboard
code. The normal cut/copy/paste stuff should just deal with the CLIPBOARD
selection.

And to make it behave like most X-users expect, anytime text is selected
in the editor, Abiword should "put" it on the PRIMARY selection. And
correspondingly, the 2nd button (middle) should paste the PRIMARY
selection.

Also, clipboard formats are specified via atoms in X. I believe the X
specs describe a few standards (which GTK has defines for), but many are
especially vague (such as IMAGE). STRING is the basic, straight text
format (like CF_TEXT on Windows). I believe the Motif community extended
it with some of their own, too (such as _NETSCAPE_URL [probably
Netscape's creation...]). GNOME (and KDE, too, I imagine) has taken a sane
approach -- MIME types. All that means, of course, is that applications
make X atoms named after mime-types and add that atom to their format
options for selections. The receiving (pasted into) application takes the
list of formats, picks a mime-type it recognizes (STRING being the
simplest format which all apps should know), and calls the convert
function. Signal handlers on each end deal with with converting on demand
(owner) and getting the data after conversion (client).

I noticed in the wp code, some object is built with a list of formats, and
the those formats lables have things like 'rtf', 'Abisource.Abiword.1',
etc, which are ok for internal abiword stuff, but I'd prefer something
like 'text/rtf', 'application/x-abiword' (with version info if necessary),
etc, for the actual underlying X atom names. If I find any widely-used
Motif atoms, I'll stick those in, too...

Anyway, I'll write the clipboard stuff for unix sometime tomorrow, unless
someone can beat me to it.

Justin



This archive was generated by hypermail 1.03b2.