Re: Copy to clipboard for Linux

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

Dave Denholm wrote:
> Daniel J Sebald <dan...@ie...> writes:
> 
> 
>>Daniel J Sebald wrote:
>>
>>
>>>SO, the idea is to force the requestor window to clear all pending updates before sending the event.  Here's the additional command:
>>>
> 
> 
> [snip]
> 
> 
>> 
>>+	    /* Make sure things are ready on the requestor window. */
>>+	    XFlush(dpy);
>>+
>> 	    XSendEvent(dpy, reply.xselection.requestor, False, 0L, &reply);
>>-	    /* we never block on XNextEvent(), so must flush manually
>>-	     * (took me *ages* to find this out !)
>>-	     */
>> 
>>-	    XFlush(dpy);
>>
>>The flush should be before sending the event.  (That comment may be a red herring.)
>>
> 
> 
> With no flush afterwards..?
> 
> This really concerns me : you are basically relying on a delay to make
> things work. There will be a flush soon anyway,
> 
> All the flush is doing is forcing them to be written to the socket
> fd.  You have no guarantee that it has actually been written over
> the network. So the send event may still actually get transmitted in
> the same buffer. The only way to gaurantee that it has actually been
> processed by the X server is to use XSync() rather than XFlush.
> 
> I believe that X is deterministic, and so if you have to
> solve it this way, you've missed the real problem somewhere.

Works much better for me; that's all I know.  You may be correct about the Flush, but it could be that there is a Flush in the loop of gplt_x11.c...  Sure, here it is:


    while (1) {

	/* XNextEvent does an XFlush() before waiting. But here.
	 * we must ensure that the queue is flushed, since we
	 * dont call XNextEvent until an event arrives. (I have
	 * twice wasted quite some time over this issue, so now
	 * I am making sure of it !
	 */

	XFlush(dpy);

	FD_ZERO(&tset);
	FD_SET(cn, &tset);


After the event is processed, the loop comes back and flushes before waiting.  So, that XFlush I removed was extraneous.

Dan