Re: Copy to clipboard for Linux

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

Daniel J Sebald wrote:
> Timoth=E9e Lecomte wrote:
>> Daniel J Sebald wrote:
>>
>>> 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 gnupl=
ot
>>>>> doesn't have such an event. IIRC, we use "currenttime" for that, bu=
t
>>>>> 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=20
>>>> each "record", so if the user doesn't click on the window this=20
>>>> timestamp 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=20
>>> to call a XA_TIMESTAMP selector request.  But now it no longer=20
>>> does.  Perhaps that was an issue (that X could resolve with the=20
>>> XA_TIMESTAMP property request), and now has gone away.
>>>  =20
>>
>> Well, X itself does not call XA_TIMESTAMP, but other applications=20
>> that check for the content of the clipboard/selection like klipper.=20
>> Without XA_TIMESTAMP, klipper would infinitely retrieve the pixmap=20
>> provided by gnuplot, even if it did not change.
>>
>> 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=20
> race condition Ethan describes.  One in which the Pixmap doesn't seem=20
> to successfully make it over to the application (client) requesting=20
> it.  We were handling the request, but sometimes the trasfer was=20
> unsuccessful.
Ok, I'm a little late in this thread, but in what conditions did the=20
transfer failed ? How can I reproduce it ?
>
>> I must admit that I am a little lost in this thread. Can you repeat=20
>> what you're trying to solve/achieve ?
>>
>> I think that Dave was probably talking about this=20
>> (gplot_x11.c:5924:export_graph):
>>
>>    XSetSelectionOwner(dpy, EXPORT_SELECTION, plot->window, CurrentTime=
);
>
> Well, that is an issue Dave raised.  But I think he basically answered=20
> that question himself by stating that time stamp is used to resolve=20
> conflicts in who gets control of the selection.  For example, if two X=20
> windows request control at very near the same time and both of them=20
> request CurrentTime, I'm guessing that X has no recourse but to make a=20
> random choice.
Agreed, so it may not be the origin of the unsuccessful transfer, but=20
it's worth trying.
>
>>
>> where we indeed use CurrentTime which is definitely not the time when=20
>> the event was triggered. Could be interesting to change CurrentTime=20
>> to plot->time, or rather :
>>
>>    (!plot || !(plot->time)) ? CurrentTime : plot->time
>
> Ehhhh.  Not sure.  Don't think that will achieve anything.  The plot=20
> could have been created an hour ago and we'd be saying we want to take=20
> control of the PRIMARY selection or CLIPBOARD at a time one hour ago. =20
> (I think X would realize that something is not right about that and=20
> deal with it.)  Unless we want to be very accurate about when the=20
> button or key is pressed that activates Selection, CurrentTime is=20
> probably best choice.
Well, you acquire the selection once, when it's ready, not one hour=20
later. That's why this XSetSelectionOwner() call is made in record() and=20
display() but that's all. You don't call it later, that's useless.
However, when it's called, it should be provided the right timestamp.=20
CurrentTime probably means "use the current time when the server=20
processes the XSetSelectionOwner call", which is a little later.
>
> But, at the same time, there is the related issue that if the other=20
> client asks for a XA_TIMESTAMP we should be able to provide, again,=20
> definetly not the time of the plot, but we shouldn't then say=20
> CurrentTime.  We should be saying the time the button was pressed. =20
> Keep a record of that somehow.  (I can fix this up later.)
>
> But still, since OpenWrite didn't seem to be asking me for=20
> XA_TIMESTAMP, I don't think the reason for unsuccessful transfer was=20
> the time stamp issue.  It is the XFlush().
XA_TIMESTAMP and the unsuccessful transfer are two unrelated issues. I=20
am sorry I talked about that, it seems it made you confused.

Best regards,

Timoth=E9e