Re: Copy to clipboard for Linux

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Tuesday 18 July 2006 03:06 pm, Timoth=E9e Lecomte wrote:
>=20
>>>Correct.  I think the important thing we are try to address is the
>>>race condition Ethan describes.  One in which the Pixmap doesn't
>>>seem to successfully make it over to the application (client)
>>>requesting it.  We were handling the request, but sometimes the
>>>trasfer was unsuccessful.
>=20
>=20
> Who, me?
> I didn't say anything about a race condition.

You're right.  Sorry.  Your comment was:

"If you allow the selection to remain active
(multiple pastes) then some window managers spin endlessly,
using 100% of CPU."


> What is the problem you are trying to solve?
> So far as I know the clipboard stuff is currently working as well,
> or better, than it did before.

I'm not sure it does.  Someone indicated that the pasting of the image in=
 OpenWriter took two or three presses of the mouse...   I printed out the=
 Atoms that gnuplot_x11.c was receiving, and yes it was receiving the ato=
ms and responding but some times the plot would not appear.

>=20
> My only contribution to this thread was to point out that we
> discovered during the last go-round that different versions of KDE
> (in particular different versions of klipper) and different versions
> of OpenOffice all play fast-and-loose with the supposedly "standard"
> protocol for the X clipboard.  Following the standard doesn't help
> if the apps you are trying to work with do not themselves follow it.
>=20
> All of these issues with timestamps and selection requests were
> involved, and it seemed at the time that only an empirical fix
> was possible.  Certainly no "fix" can be accepted if it doesn't
> work with the whole range of window managers that are likely to
> be used.

Well, give the patch I made a try.  As far as I see it, there is now a wa=
y to put things in the PRIMARY and CLIPBOARD.  If there is a version of X=
 that doesn't use one of those mechanisms (which are called out in the X =
documentation) then that is its problem.

It may be that in KDE one must use one or the other.  But again, we can a=
lways provide a term option to configure the behavior.  Why aim for the l=
owest common denominator?

Dan