Re: Copy to clipboard for Linux

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

Timoth=E9e Lecomte wrote:
> Daniel J Sebald wrote:
>=20
>> Timoth=E9e Lecomte wrote:
>> =20
>>
>>> Dave Denholm wrote:
>>>
>>>   =20
>>>
>>>> Ah - tell you what - there is one thing that is timing dependent.
>>>>
>>>> When you acquire a selection, you're supposed to give a
>>>> timestamp. That is a server time, and it usually comes from the X
>>>> event that triggered the action to acquire the selection. But gnuplo=
t
>>>> doesn't have such an event. IIRC, we use "currenttime" for that, but
>>>> that isn't a real time.
>>>>        =20
>>>
>>> Hmm. I wrote the code just a few months ago to provide this=20
>>> timestamp. I took the time as plot->time. I realise now that this=20
>>> time is only updated at a button release event, and put to 0 at each=20
>>> "record", so if the user doesn't click on the window this timestamp=20
>>> may have a useless value.
>>>    =20
>>
>>
>> Could have been a problem.  But I eventually whittled things down to=20
>> the one problem Dave is keen to.  I did notice that the client used to=
=20
>> call a XA_TIMESTAMP selector request.  But now it no longer does. =20
>> Perhaps that was an issue (that X could resolve with the XA_TIMESTAMP=20
>> property request), and now has gone away.
>>  =20
>=20
> Well, X itself does not call XA_TIMESTAMP, but other applications that=20
> check for the content of the clipboard/selection like klipper. Without=20
> XA_TIMESTAMP, klipper would infinitely retrieve the pixmap provided by=20
> gnuplot, even if it did not change.
>=20
> But that's not the race condition you're talking about, right ?

Correct.  I think the important thing we are try to address is the race c=
ondition Ethan describes.  One in which the Pixmap doesn't seem to succes=
sfully make it over to the application (client) requesting it.  We were h=
andling the request, but sometimes the trasfer was unsuccessful.

> I must=20
> admit that I am a little lost in this thread. Can you repeat what you'r=
e=20
> trying to solve/achieve ?
>=20
> I think that Dave was probably talking about this=20
> (gplot_x11.c:5924:export_graph):
>=20
>    XSetSelectionOwner(dpy, EXPORT_SELECTION, plot->window, CurrentTime)=
;

Well, that is an issue Dave raised.  But I think he basically answered th=
at question himself by stating that time stamp is used to resolve conflic=
ts in who gets control of the selection.  For example, if two X windows r=
equest control at very near the same time and both of them request Curren=
tTime, I'm guessing that X has no recourse but to make a random choice.

>=20
> where we indeed use CurrentTime which is definitely not the time when=20
> the event was triggered. Could be interesting to change CurrentTime to=20
> plot->time, or rather :
>=20
>    (!plot || !(plot->time)) ? CurrentTime : plot->time

Ehhhh.  Not sure.  Don't think that will achieve anything.  The plot coul=
d have been created an hour ago and we'd be saying we want to take contro=
l of the PRIMARY selection or CLIPBOARD at a time one hour ago.  (I think=
 X would realize that something is not right about that and deal with it.=
)  Unless we want to be very accurate about when the button or key is pre=
ssed that activates Selection, CurrentTime is probably best choice.

But, at the same time, there is the related issue that if the other clien=
t asks for a XA_TIMESTAMP we should be able to provide, again, definetly =
not the time of the plot, but we shouldn't then say CurrentTime.  We shou=
ld be saying the time the button was pressed.  Keep a record of that some=
how.  (I can fix this up later.)

But still, since OpenWrite didn't seem to be asking me for XA_TIMESTAMP, =
I don't think the reason for unsuccessful transfer was the time stamp iss=
ue.  It is the XFlush().

Dan