Re: Copy to clipboard for Linux

[Dave D. <dde...@es...>]

Daniel J Sebald <dan...@ie...> writes:

> Dave Denholm wrote:
>> Daniel J Sebald <dan...@ie...> writes:
>> 
>> 
>>>I believe I have the selection features worked out for the X11
>>>clipboard.  As far as the race condition, I think I have it now so
>>>that rarely does selecting and clicking not work.  Tell me if this
>>>logic and part of the solution makes sense. 
>>>
>> 
>> 
>> Incidentally, ethereal (or whatever it's called now) can decode X
>> protocol. So if you capture all network traffic on port 6000 you
>> should be able to decode the sequence of events afterwards. Or use
>> xmon (but that may change timings).
>> 
>> 
>> 
>>>Here are the basic commands in handling that event (before the change I made):
>>>
>>>		XChangeProperty(dpy, reply.xselection.requestor,
>>>				reply.xselection.property, reply.xselection.target,
>>>				32, PropModeReplace, (unsigned char *) requested_pixmap, 1);
>>>
>>>	    XSendEvent(dpy, reply.xselection.requestor, False, 0L, &reply);
>>>
>>>	    XFlush(dpy);
>>>
>>>So the idea is to set some property and send an event to the
>>>requestor saying the information it requested is *ready to go*.
>>>(Emphasis for later... point is, no it isn't ready.) 
>>>
>> 
>> 
>> Are you saying that you know that gnuplot has not yet written it, or
>> that you suspect it is getting done out-of-order by the X server ?
>
> Out of order.  I messed with XCreatePixmap and such to see if that had any bearing on things.  That doesn't seem to be a problem.  Perhaps on other versions of X it might, but not what I'm running.
>
>> 
>> 
>>>That is, XChangeProperty is changing some property on the *client*
>>>window.  There is this Pixmap sitting in X land and it puts the
>>>location of the Pixmap atom on that Window. 
>>>
>> 
>> 
>> I think it's just the pixmap id - there's no atom for a pixmap.
>
> Pixmap ID appears to be called an atom as well in some documentation.
>

There is a predefined atom for the string "PIXMAP", which is used to
identify the type of the property.

$ xlsatoms | grep PIXMAP
20      PIXMAP

Atom is a well-defined term in X, so any documentation that misuses
the term is broken.

>> 
>> 
>>>I think, however, that things don't necessarily happen contiguously
>>>in X that way.
>> 
>> 
>> X is quite strict about the sequence of events. It does provide
>> gaurantees about ordering, and promises not to start on one request
>> until the previous one is finished. This is necessary so that error
>> reporting can provide the correct sequence numbers, etc.
>
> Well, something is slightly off.  Allow me to live in ignorance and be happy.
>
>
>> 
>>> So, it could well be that the Property Change is not
>>>actually complete before the time the sent event reaches the
>>>window. 
>>>
>> 
>> 
>> I'm sceptical about that. And all that arrives on the other client is
>> an event that the property has changed. The client still has another
>> round-trip to get hold of the value you've written. So the X server
>> has a lot of time to finish its work, even if it was doing things out
>> of order.
>
> Unless perhaps it is a fairly huge Pixmap in X's world where sparsity rules.
>

Don't think so. If the X server does decide to defer some work, it
will have to somehow lock the pixmap, and then when someone tries to access it,
block that client until the work is done.

>> A simpler way to change the timing would be to do an XFlush between
>> the ChangeProperty and the SendEvent.
>
> And I believe that is right.  (It finally dawned on me.)
>

I agree it's a simpler way to change the timing. But if you are
relying on timing, the code is broken somewhere.

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 gnuplot
doesn't have such an event. IIRC, we use "currenttime" for that, but
that isn't a real time.

The X server uses the timestamp to resolve if two separate clients try
to acquire the same selection : the later time should win. Maybe the
problem is in that part of the code.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com