Re: Copy to clipboard for Linux

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

Dave Denholm wrote:

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

Yes, I'm not fluent in the terminology, but I understand.


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

There is discussion in the documentation about large data transfers.  Can't say I totally understand it, but that is where we seemed to consistently have the problem.

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

That did concern me, because we don't handle that gracefully.  But I can't imagine how that could cause a problem.

Hold on, let me say there is more that I added, and maybe it is more crucial to the problem than I would think.  Now, I changed things slightly in the sense that I want the client to have a copy of the pixmap that doesn't have the mouse coordinates along the bottom of the Pixmap.  To do that, in the midst of this handling of the selection request I've added:

/* Want only the graph portion of Pixmap */
if (requested_pixmap == &selected_pixmap && *requested_pixmap != None) {
[snip]
    if (storage_pixmap != None)
	XFreePixmap(dpy, storage_pixmap);
[snip]
	storage_pixmap = XCreatePixmap(dpy, root, plot->width, GRAPH_HEIGHT(plot), dep);
	if (storage_pixmap != None) {
	    /* Composited for highlight, undo that before copying. */
	    CompositeWindow(plot, 0);
	    XCopyArea(dpy, plot->pixmap, storage_pixmap, *current_gc, 0, 0, plot->width, GRAPH_HEIGHT(plot), 0, 0);
	    CompositeWindow(plot, 1);
	}
[snip]

(The CompositeWindow() stuff is to turn off and back on the inverse video effect.  I seemed to have little issue with those... as you say, those seemed to happen contiguously with no problems.)

The above lines of code did seem to add to the bad behavior.

I'm almost certain I read somewhere that things don't happen in X necessarily when you think they will.  So even though things happen contiguously, could it be they happen later than one might think?  That is, without the XFlush, all the above stuff I added, which admittedly is a lot of processing from X's perspective is deferred and not finished before the client window, the requestor, gets its event to proceed?

And here is a bit more information.  The XCopyArea(), here and in other locations, appears to return with a non-Success value, it returns BadRequest, a value of 1.  I always thought Odd, that seems to work fine.  However, maybe that non-Success indication simply means X can't do all that right now so it is deferring the operation until a little later in its refresh cycle (or whatever terminology).

So maybe we should be checking for that BadRequest value and if we find it, *then* we need to XFlush().  (Or, we just always XFlush.)  Again, things are contiguous for our window, so that BadRequest is no problem for gnuplot_x11, but it is for any outside client.

Dan