This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: X11 Selections
- From: Harold L Hunt II <huntharo at msu dot edu>
- To: cygwin-xfree at cygwin dot com
- Date: Sat, 03 Jan 2004 18:27:59 -0500
- Subject: Re: X11 Selections
- References: <Pine.LNX.4.55.0401032358520.18354@lupus.ago.vpn>
- Reply-to: cygwin-xfree at cygwin dot com
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