public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
* X11 Selections
@ 2004-01-03 23:16 Alexander Gottwald
2004-01-03 23:28 ` Harold L Hunt II
0 siblings, 1 reply; 11+ messages in thread
From: Alexander Gottwald @ 2004-01-03 23:16 UTC (permalink / raw)
Cc: cygwin-xfree
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: X11 Selections
2004-01-03 23:16 X11 Selections Alexander Gottwald
@ 2004-01-03 23:28 ` Harold L Hunt II
2004-01-03 23:34 ` Alexander Gottwald
0 siblings, 1 reply; 11+ messages in thread
From: Harold L Hunt II @ 2004-01-03 23:28 UTC (permalink / raw)
To: cygwin-xfree
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: X11 Selections
2004-01-03 23:28 ` Harold L Hunt II
@ 2004-01-03 23:34 ` Alexander Gottwald
2004-01-04 0:22 ` Harold L Hunt II
0 siblings, 1 reply; 11+ messages in thread
From: Alexander Gottwald @ 2004-01-03 23:34 UTC (permalink / raw)
To: cygwin-xfree
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: X11 Selections
2004-01-03 23:34 ` Alexander Gottwald
@ 2004-01-04 0:22 ` Harold L Hunt II
2004-01-04 7:47 ` Harold L Hunt II
0 siblings, 1 reply; 11+ messages in thread
From: Harold L Hunt II @ 2004-01-04 0:22 UTC (permalink / raw)
To: cygwin-xfree
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: X11 Selections
2004-01-04 0:22 ` Harold L Hunt II
@ 2004-01-04 7:47 ` Harold L Hunt II
2004-01-04 9:35 ` Kensuke Matsuzaki
2004-01-04 14:07 ` Alexander Gottwald
0 siblings, 2 replies; 11+ messages in thread
From: Harold L Hunt II @ 2004-01-04 7:47 UTC (permalink / raw)
To: cygwin-xfree
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: X11 Selections
2004-01-04 7:47 ` Harold L Hunt II
@ 2004-01-04 9:35 ` Kensuke Matsuzaki
2004-01-04 21:13 ` Harold L Hunt II
2004-01-04 14:07 ` Alexander Gottwald
1 sibling, 1 reply; 11+ messages in thread
From: Kensuke Matsuzaki @ 2004-01-04 9:35 UTC (permalink / raw)
To: cygwin-xfree
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: X11 Selections
2004-01-04 7:47 ` Harold L Hunt II
2004-01-04 9:35 ` Kensuke Matsuzaki
@ 2004-01-04 14:07 ` Alexander Gottwald
2004-01-04 14:48 ` Kensuke Matsuzaki
1 sibling, 1 reply; 11+ messages in thread
From: Alexander Gottwald @ 2004-01-04 14:07 UTC (permalink / raw)
To: cygwin-xfree
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: X11 Selections
2004-01-04 14:07 ` Alexander Gottwald
@ 2004-01-04 14:48 ` Kensuke Matsuzaki
2004-01-04 21:11 ` Harold L Hunt II
0 siblings, 1 reply; 11+ messages in thread
From: Kensuke Matsuzaki @ 2004-01-04 14:48 UTC (permalink / raw)
To: cygwin-xfree
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: X11 Selections
2004-01-04 14:48 ` Kensuke Matsuzaki
@ 2004-01-04 21:11 ` Harold L Hunt II
2004-01-04 22:14 ` Harold L Hunt II
0 siblings, 1 reply; 11+ messages in thread
From: Harold L Hunt II @ 2004-01-04 21:11 UTC (permalink / raw)
To: cygwin-xfree
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: X11 Selections
2004-01-04 9:35 ` Kensuke Matsuzaki
@ 2004-01-04 21:13 ` Harold L Hunt II
0 siblings, 0 replies; 11+ messages in thread
From: Harold L Hunt II @ 2004-01-04 21:13 UTC (permalink / raw)
To: cygwin-xfree
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.
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: X11 Selections
2004-01-04 21:11 ` Harold L Hunt II
@ 2004-01-04 22:14 ` Harold L Hunt II
0 siblings, 0 replies; 11+ messages in thread
From: Harold L Hunt II @ 2004-01-04 22:14 UTC (permalink / raw)
To: cygwin-xfree
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-01-04 22:14 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-03 23:16 X11 Selections Alexander Gottwald
2004-01-03 23:28 ` Harold L Hunt II
2004-01-03 23:34 ` Alexander Gottwald
2004-01-04 0:22 ` Harold L Hunt II
2004-01-04 7:47 ` Harold L Hunt II
2004-01-04 9:35 ` Kensuke Matsuzaki
2004-01-04 21:13 ` Harold L Hunt II
2004-01-04 14:07 ` Alexander Gottwald
2004-01-04 14:48 ` Kensuke Matsuzaki
2004-01-04 21:11 ` Harold L Hunt II
2004-01-04 22:14 ` Harold L Hunt II
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).