From: Dave D. <dde...@es...> - 2006-07-18 09:29:10
|
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 ? > 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. > 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. > 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. > 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. 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. A simpler way to change the timing would be to do an XFlush between the ChangeProperty and the SendEvent. dd -- Dave Denholm <dde...@es...> http://www.esmertec.com |