[Annoyances] X-Windows Copy & Paste

Lubos Lunak l.lunak at suse.cz
Thu Aug 21 20:46:42 EEST 2003

On Thursday 21 of August 2003 17:32, Richard Boulton wrote:
> On Thu, 2003-08-21 at 14:20, Havoc Pennington wrote:
> > The problem that does need solving is persistence of clipboard after
> > an app exits, ideally without harvesting a selection and freezing its
> > format immediately.
> I can think of lots of solutions - but none are without problems.
> 1) Use cut buffers.
>    This is supported by some terminal applications, and not much else.
> Pros: Simplicity. Doesn't require any new processes/protocols.
> Cons: Only works for text.
>       Possibly has some size of data limitations.
>       Text is unformatted and has to be assumed to be in Latin1.
>       The data has to be copied even if noone wants it.
>       Needs lots of application changes, since few currently bother to
>       look in cut buffers.

 Conclusion: Forget it.

> 2) Define and use a new mechanism like cut buffers, but that supports
>    formatted data.
> Pros: Could be made to work with images, etc. Could store the data in
>       XProperties still, or use XProperties to point to where to go to
>       get the data.
> Cons: Needs whole new system to be built.  Also, the data has to be
>       copied even if noone wants it.  Forces data to be converted to a
>       single format.

 I.e. - no advantage compared to X selections with xclipboard-like tool. Needs 
designing whole new system.

 Conclusion: Not worth it.

[snipped 3) and 4) - interesting, the question is whether it would be really 
worth it]

> 5) The current solution; run a clipboard manager which grabs the
>    clipboard as soon as it is set.
> Pros: Doesn't require any application changes.
>       Works acceptably.
>       Allows features such as a clipboard history to be built in.
>       Clipboard persists even if application crashes.
> Cons: Forces clipboard data to a single format.

 Not necessary - usually at even more copying of data though.

>       Performs much unneccessary copying of data.
>       Requires a manager process to be running.
> 6) Add to X a mechanism for an application to receive notification of
>    X selection changes.  Then, run a manager application which
>    copies the contents of the clipboard whenever it is set - but doesn't
>    do the current thing of claiming the clipboard ownership.  Only if an
>    application dies whilst holding the clipboard will the manager claim
>    ownership of the clipboard.  Basically, the manager provides a
>    "backup" of the clipboard data.
> Pros: Doesn't require application changes.
>       Allows features such as a clipboard history to be built in.
>       Doesn't force clipboard data to a single format.
>       Clipboard persists even if application crashes.
> Cons: Requires modification of X.  (At least, I can't find any way to
>       get notification of selection changes without claiming the
>       ownership first.)
>       Performs unneccesary copying to clipboard.
>       Requires a manager process to be running.

 Actually, KDE's Klipper is this 6), and not 5), so it's not exactly like 
xclipboard. Qt provides its own way to signal that the clipboard contents 
have changed, and for non-Qt apps, it's solved by ... well, you guessed it, 
polling :(.

 However, see this: 
https://listman.redhat.com/archives/xdg-list/2002-November/msg00095.html - 
XFree86-4.3.0 was supposed to have XFIXES extension that among other things 
also had the ability to notice every X client about changes in X selection 
ownership. It didn't make it in, for well known reasons. But if this Xouvert 
project makes up to its promises, I think it could include this stuff too (I 
don't know actually what Keith Packard's relation to it is, he's probably not 
involved with it yet).

> I think option 5 is what we have to live with for the moment, and option
> 6 would be better except for the need to modify X.

 I agree.

> I'd actually like the ability to get notifications of selection changes
> for other purposes than the above too (specifically, I'd like to make an
> application which searched documentation databases for the contents of
> the current selection, and instantly presented links any useful
> information it found in a small window on my screen).  So if anyone
> knows a way to do it, let me know. ;-)

Lubos Lunak
KDE developer
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/

More information about the xdg mailing list