Re: commit -- more clipboard functionality
Jeff Hostetler (jeff@sourcegear.com)
Sat, 24 Jul 1999 22:08:01 -0500
Justin Bradford wrote:
>
> > 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...
yea, we have had the builtin format names since the original clipboard
work for XP reasons. but not a lot of thought was given to what strings
we should use for them. if you want to change them to mime-types, that's
probably ok -- that way you won't need the mapping table like win32 has
to map them into CF_ id's.
>
> Anyway, I'll write the clipboard stuff for unix sometime tomorrow, unless
> someone can beat me to it.
go for it.
jeff
This archive was generated by hypermail 1.03b2.