X11 Selections

X11 Selections

[Alexander Gottwald]

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?

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.

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

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

Win32->X11

 Win32 client copies to the clipboard

  - WindowProc receives WM_DRAWCLIPBOARD
  - call ProcSetSelectionOwner with RootWindow (or fake window) as owner

 X11 client calls XConvertSelection

  - receive SelectionRequest event
  - translate clipboard data for xclient
  - send data to client

bye
    ago

NP: Funker Vogt - Compulsions
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

Re: X11 Selections

[Harold L Hunt II]

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

Re: X11 Selections

[Alexander Gottwald]

Harold L Hunt II wrote:

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

This is something I was still searching in the MSDN.

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

This sounds great.

bye
    ago

NP: Placebo - Ask for answers
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

Re: X11 Selections

[Harold L Hunt II]

I have successfully wrapped the dix layer's SetSelectionOwner function 
in InitInput.c (it seems this needs to happen only once per instance of 
XWin.exe, not per screen), and confirmed that I can print out a message 
from this function.

The next step is to make sure that I can retrieve the current selection 
contents within the X Server without a real client connection.  I 
believe that I already had code that could do this, but I will have to 
look around.  I have some new ideas for how to do this if I don't have 
old code around.

After these two steps are complete I will have to make sure that our 
protocol for changing ownership of the Win32 and X11 clipboards will not 
lead to any infinite looping, then I can go about implementing some 
simple copying and pasting routines.

Finally, I will have to adapt the xwinclip/-clipboard code that handles 
Unicode and MBCS strings to work with teh new system.

Looks exciting.  I might have something later tonight.

Harold

Re: X11 Selections

[Harold L Hunt II]

I have followed through on the idea that Alexander and I were working on.

I am trapping the SetSelectionOwner call within the server and I am 
using it, together with monitoring the Windows clipboard chain, to 
determine when to copy data from which clipboard.  There are still some 
bugs in this code, but I think I can work through them tomorrow and 
release the new code.

However, working on this reminded me that we really had two problems 
that we wanted to solve:

1) Stop stealing the selection ownership as a means to tell when the 
clipboard has changed within X.

2) Don't require an X Client connection and try to remove the dependency 
on Xlib.

The new code solves problem #1, but it does nothing for #2, since we 
still need an X Client connection to receive the contents of the 
selection and we still need Xlib to convert the selection into the 
desired format.  I am not sure how long it will take us to remove these 
two dependencies, so I am going to release the solution to problem #1 in 
the mean time.  I am not sure that we will ever deem it worth the time 
and effort to solve problem #2.

Harold

Re: X11 Selections

[Kensuke Matsuzaki]

Harold,

I think you were working on XFIXES extention to solve #1.
Is that another solution?

> 1) Stop stealing the selection ownership as a means to tell when the 
> clipboard has changed within X.
> 
> 2) Don't require an X Client connection and try to remove the dependency 
> on Xlib.
> 
> The new code solves problem #1, but it does nothing for #2, since we 
> still need an X Client connection to receive the contents of the 
> selection and we still need Xlib to convert the selection into the 
> desired format.  I am not sure how long it will take us to remove these 
> two dependencies, so I am going to release the solution to problem #1 in 
> the mean time.  I am not sure that we will ever deem it worth the time 
> and effort to solve problem #2.

-- 
Kensuke Matsuzaki
mailto:zakki@peppermint.jp
http://peppermint.jp

Re: X11 Selections

[Harold L Hunt II]

Kensuke,

Kensuke Matsuzaki wrote:

> Harold,
> 
> I think you were working on XFIXES extention to solve #1.
> Is that another solution?

Yes, I was working on using XFIXES, but it was very difficult to get 
code within the server to compile with and use the XFIXES extension.

The clipboard integration is only for our X Server, so it isn't a 
problem to wrap the function that we need to monitor directly.  In fact, 
it ends up being a much cleaner solution.  It is a lot easier to 
understand, and it does not introduce another X Client library 
dependency for XWin.exe, which is good to avoid.

Harold

>>1) Stop stealing the selection ownership as a means to tell when the 
>>clipboard has changed within X.
>>
>>2) Don't require an X Client connection and try to remove the dependency 
>>on Xlib.
>>
>>The new code solves problem #1, but it does nothing for #2, since we 
>>still need an X Client connection to receive the contents of the 
>>selection and we still need Xlib to convert the selection into the 
>>desired format.  I am not sure how long it will take us to remove these 
>>two dependencies, so I am going to release the solution to problem #1 in 
>>the mean time.  I am not sure that we will ever deem it worth the time 
>>and effort to solve problem #2.
> 
> 

Re: X11 Selections

[Alexander Gottwald]

Harold L Hunt II wrote:

> The new code solves problem #1, but it does nothing for #2, since we
> still need an X Client connection to receive the contents of the
> selection

This one is quite complex: Hook into ProcSendEvent and catch Selection*
events for the rootwindow (or the fake window id)

> and we still need Xlib to convert the selection into the desired format.

Which conversions are these? Can they be done by other libraries or by using
connection idependent code from libX11 (which could be staticly linked)

bye
    ago

NP: Welle:Erdball - Feindsender 64,3
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

Re: X11 Selections

[Kensuke Matsuzaki]

Alexander,

> > and we still need Xlib to convert the selection into the desired format.
> 
> Which conversions are these? Can they be done by other libraries or by using
> connection idependent code from libX11 (which could be staticly linked)

Conversion text encoding between compound text, UTF-8, Unicode and
locale encoding. lib/X11/lc*.c contain those code. Maybe some part of
those conversion can be done by iconv. But as far as I know, gnu
libiconv doesn't supprot compound text.

-- 
Kensuke Matsuzaki
mailto:zakki@peppermint.jp
http://peppermint.jp

Re: X11 Selections

[Harold L Hunt II]

Kensuke Matsuzaki wrote:
> Alexander,
> 
> 
>>>and we still need Xlib to convert the selection into the desired format.
>>
>>Which conversions are these? Can they be done by other libraries or by using
>>connection idependent code from libX11 (which could be staticly linked)
> 
> 
> Conversion text encoding between compound text, UTF-8, Unicode and
> locale encoding. lib/X11/lc*.c contain those code. Maybe some part of
> those conversion can be done by iconv. But as far as I know, gnu
> libiconv doesn't supprot compound text.

I think a lot of those functions might be connection independent.  I was 
looking at them last night and they do a lot of processing within Xlib, 
but they don't make calls to the server.  Thus, they should not need a 
connection.

Harold

Re: X11 Selections

[Harold L Hunt II]

Harold L Hunt II wrote:
> Kensuke Matsuzaki wrote:
> 
>> Alexander,
>>
>>
>>>> and we still need Xlib to convert the selection into the desired 
>>>> format.
>>>
>>>
>>> Which conversions are these? Can they be done by other libraries or 
>>> by using
>>> connection idependent code from libX11 (which could be staticly linked)
>>
>>
>>
>> Conversion text encoding between compound text, UTF-8, Unicode and
>> locale encoding. lib/X11/lc*.c contain those code. Maybe some part of
>> those conversion can be done by iconv. But as far as I know, gnu
>> libiconv doesn't supprot compound text.
> 
> 
> I think a lot of those functions might be connection independent.  I was 
> looking at them last night and they do a lot of processing within Xlib, 
> but they don't make calls to the server.  Thus, they should not need a 
> connection.

I lied, these functions make use of XInternAtom, which requires a 
display connection.  However, there may be various ways of hacking this. 
  For example, we could pre-register any used atoms when our X Server 
starts up and use our pre-defined (or at least accessible without a 
client connection) atom values in place of a lookup via XInternAtom.

I have not looked further into the problem yet.

Harold