Re: Copy to clipboard for Linux

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

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.

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


> 
>>The client on its end gets the message, goes to look for the
>>property on its window and realizes it doesn't find the information
>>gplt_x11 said was there, on occassion. 
>>
>>SO, the idea is to force the requestor window to clear all pending
>>updates before sending the event.  Here's the additional command: 
>>
>>		XChangeProperty(dpy, reply.xselection.requestor,
>>				reply.xselection.property, reply.xselection.target,
>>				32, PropModeReplace, (unsigned char *) requested_pixmap, 1);
>>
>>	    XClearWindow(dpy, reply.xselection.requestor);
>>
>>	    XSendEvent(dpy, reply.xselection.requestor, False, 0L, &reply);
>>
>>	    XFlush(dpy);
>>
> 
> 
> What are you expecting the ClearWindow to do. All it will do is send
> one or more expose events to the client, asking it to repaint the
> window. The client is not required to discard any updates, or anything
> like that.

Right.

> The thing are are doing is (probably) forcing that client to do some
> extra work before it recents the selection event. So you are changing
> the timing, But it doesn't seem the right way to go about it.

Right.

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

Dan