Re: X clipboard

[Havoc Pennington <hp redhat com>]

ERDI Gergo <cactus cactus rulez org> writes:
> On 21 Dec 2001, Havoc Pennington wrote:
> 
> >  - "xclipboard" (as the ICCCM itself suggests) - a clipboard 
> >    server that takes over selections immediately.
> 
> XClipboard, IIRC, only stores TEXT selections.

The point isn't about xclipboard itself (which is a sucky old legacy
app) but about an app doing the same thing as xclipboard.

Said app could know about a type such as BONOBO_MONIKER and handle it
accordingly.

> I've always been saying that you shouldn't make app authors having to deal
> with clipboard persistancy, and all in all I don't think this problem
> space can be solved using only X features.
> Sure, you could create XClipboard++ that stored every selection, but then
> you face terrible performance problems when someone copies a Gimp image to
> the clipboard.

No more inherently so than with any other clipboard. If you have some
way to represent the cut data other than copying it (e.g. a moniker),
then you can pass that moniker via the X selection. All the X
clipboard inherently stores is the type of the selection, and the
selection's owner. The type of the selection implies how the data is
stored and transferred and interpreted.

The X clipboard is extensible to any data type you like. There's no
problem with extending it to handle more data types, even
GNOME-specific ones - because the way it works, you can also offer
interoperable data types as a fallback.

It's entirely reasonable to have a Bonobo-based data format and
moniker-aware xclipboard replacement.

Havoc