Re: Copy to clipboard for Linux

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

Timoth=E9e Lecomte wrote:

>>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.
>=20
> Ok, I'm a little late in this thread, but in what conditions did the=20
> transfer failed ? How can I reproduce it ?

Without adding some code to verify gnuplot_x11.c is getting requests but =
the plot is not appearing, I guess just try selecting (i.e., clipboarding=
) a plot Pixmap and attempting to paste in OpenWrite.  Check if there is =
a feeling of inconsistency, i.e., that the Pixmap doesn't appear to trans=
fer even though you believe you've pressed the button.

>=20
>>>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.
>=20
> Agreed, so it may not be the origin of the unsuccessful transfer, but=20
> it's worth trying.

Sure, but I think moving that XFlush() command to before sending an event=
 to the requesting client puts us in the realm of reasonable understandin=
g (Dave hasn't disagreed with that yet, I think) and at the same time app=
ears to fix the problem.  Perhaps someone else could test and verify the =
code.

>=20
>>>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.
>=20
> Well, you acquire the selection once, when it's ready, not one hour=20
> later.

But that is the issue I'm making.  I keep wondering why we should program=
 gnuplot to behave significantly different from usual X behavior.  Is it =
nice to have gnuplot automatically saving to the clipboard without being =
initiated to do so?  Obviously not; that is the reason for adding the abi=
lity to turn off "export plot".  Otherwise users will not like that their=
 clipboard is being overwritten.

I guess I was thinking along the lines of the mouse click or key press or=
 "set output clipboard; plot x" activating the Selection, where the plot =
time and selection time could be different.  I see what you were thinking=
 though.

> 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.

As it is program, useless yes.  But not in the conventional X method.

> 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.

It's clear I've rearranged the concept, but I think I'm trying to move mo=
re along the lines of X expected behavior.

Dan