Re: X11 Selections

[Harold L Hunt II <huntharo@msu.edu>]

Alexander Gottwald wrote:
> Just what I've already written in IRC:
> 
> I've looked into the ICCCM to find out about the handling of X11 selections.
> From what I've read the xclient (eg xterm) just calls XSetSelectionOwner and
> can do whatever he wants. The actual data is accessed only when another
> client calls XConvertSelection. Is this correct?

Yes, I believe that is correct.

> But I have no idea what happens if the xterm calls XSetSelectionOwner, the
> other app gets the data with XConvertSelection and the xterm then modifies
> the selection without calling XSetSelectionOwner again  because it already
> own the selection buffer.

I think you are always supposed to (or at least it is common in 
practice) to call XSetSelectionOwner whenever the clipboard contents 
change, even if you already own the selection.

> To refine the outline the idea:
> 
> X11->Win32
> 
>  X11 client calls XSetSelectionOwner
> 
>   - get the data from the client (maybe by using a fake window or the root
>     window as recipient of the clipboard data)
>   - translate the data for the windows clipboard
>   - OpenClipboard
>   - EmptyClipboard
>   - SetClipboardData
>   - CloseClipboard

Actually, we can break this into two pieces like the Win32->X11 part 
below by calling SetClipboardData (foo, NULL)... this tells Windows that 
we are delaying rendering the copied text/image/whatever and we must 
process WM_RENDERFORMAT and WM_RENDERALLFORMATS to do the actual copying 
if the data is ever pasted within Windows.

This is great because it prevents copying text over the wire that will 
never be pasted, and it sets us up to handle images and other things 
that we do not currently handle.

>  If every change of the selection is indicated by XSetSelectionOwner then
>  we always place the copy of the selection in the clipboard.

I think we always get an XSetSelectionOwner call, but lets try to delay 
the actual copying until later, as I mentioned above.

> Win32->X11
> 
>  Win32 client copies to the clipboard
> 
>   - WindowProc receives WM_DRAWCLIPBOARD
>   - call ProcSetSelectionOwner with RootWindow (or fake window) as owner

Yes, that is good.

>  X11 client calls XConvertSelection
> 
>   - receive SelectionRequest event
>   - translate clipboard data for xclient
>   - send data to client

Right.  This is exacly like I mentioned above for delaying the copying 
in the X11->Win32 path.

Sounds like we have a good plan for implementing the next version of 
clipboard integration.

Harold