Re: Copy to clipboard for Linux

[<tim...@en...>]

Daniel J Sebald wrote:
> Timoth=E9e Lecomte wrote:
>>
>> In february this year, Ethan and I have patched gplt_x11.c to fix=20
>> klipper, the KDE clipboard utility, that was polling gnuplot for its=20
>> pixmap every second. Ethan wrote the patch to make gnuplot only=20
>> respond once to klipper.
>
> Oh, OK.  So that might explain why the PIXMAP request comes over to=20
> gnuplot twice in a row from the OpenWrite application.=20
Hmm, I'm not sure I get it.
> I bet the PIXMAP request fails for some reason and OpenWrite (or X)=20
> tries a second time then decides after the second time that that is=20
> it, and to not try again.
It should have worked the first time anyway.
>
> On the other hand, Klipper probably has a policy to keep trying until=20
> either a success or a "None" for the return property.
That's unrelated. Klipper does not keep trying because of any failure.=20
Read below.
>
>
>> I wrote a patch to make gnuplot provide the TIMESTAMP atom, because=20
>> klipper would poll it instead of the pixmap and see that the pixmap=20
>> has not changed. TIMESTAMP is part of the ICCCM, so the protocol is=20
>> respected here.
>
> It's always difficult to know exactly what the problem is.  Perhaps=20
> the TIMESTAMP was tied in with the failure of PIXMAP request.  Well,=20
> it seems to me that the failure of PIXMAP is at issue because that is=20
> what Klipper keeps sending and O.W. appears to send twice.
Again, klipper is not polling because of any failure per se. Let me=20
explain : Klipper is a clipboard manager. It keeps track of the=20
clipboard/selection by retrieving its content as soon as an application=20
puts something in it. When an application has something to offer as a=20
selection, it calls XSetSelectionOwner. Klipper detects that event, and=20
retrieve what the application has to offer.

Then, if the application has something *new* to offer, Klipper has to=20
retrieve the clipboard's content *again*. How does Klipper know that the=20
clipboard contains something new ? It polls the application for the=20
TIMESTAMP atom, which is supposed to contain the age of the application=20
data, and retrieves the clipboard's content each time TIMESTAMP has=20
changed. If the application does not answer to TIMESTAMP, then Klipper=20
chooses to poll directly the clipboard's content each second, and you=20
could see klipper history getting filled by identical plot images.

Ethan's approach was pretty straightforward : if Klipper is polling each=20
second, let's simply stop it as soon as it got it once.
We realized later the TIMESTAMP thing from the blog of a klipper=20
developper. It wasn't implemented at all in gnuplot.

As far as OpenWriter is concerned, it am pretty sure it does not even=20
call the TIMESTAMP atom, why would it ?
However, it should succeed at retrieving the pixmap at the first try. If=20
it doesn't, then there's definitely a bug.

I am sorry for the confusion, but it's worth noting that there are two=20
"timestamps" in the X11 context : the one I am talking about above is=20
the atom that application should answer to to satisfy klipper.
The other one that Dave was talking about is the argument that you need=20
to pass to most Xlib calls. It should be the time of the event that=20
triggered the call, but as gnuplot is not completely event-driven (at=20
least the events are on the command-line, not managed by X), we don't=20
have any relevant time to provide here, so CurrentTime has been used,=20
which tells the server to use the time when it receives the call.

I hope it is clearer.

Best regards,

Timoth=E9e