Ganesh Sittampalam wrote:
>Hi,
>
>Does anyone know if there's a way to make Xnest propagate the current
>selection? Although it behaves perfectly correctly as an X server in
>allowing copy and paste between its own clients, it doesn't appear to do
>anything with the selection in the parent X server. I would expect that
>whatever I have last selected in any window, whether inside Xnest or not,
>would propagate all the way up to the topmost X server, and vice-versa when
>pasting. That way I could copy and paste between clients inside and outside
>Xnest.
>
>I've checked all the documentation I can find (the man page!), the Debian
>package's bugs list (because that's often a good place to find people who've
>had similar problems), and Google, but I can't find any mention of this
>issue at all, which I find somewhat surprising. I'm wondering if people just
>don't use Xnest very much anyway, or if I'm missing some way of fixing this
>that's so blindingly obvious that nobody bothered to document it.
>
>For what it's worth, I'm using Xnest under Exceed, but I've verified this
>behaviour on X running directly under Linux too.
>
>Cheers,
>
>Ganesh

I don't agree with your assertion that the selection should propagate.
For example, you might want to use Xnest to isolate a nasty client for
security reasons; in this case you would want maximum isolation.

I posted code to this group in December 2002 which can do such propagation.
It was actually developed to allow cut/paste between virtual terminals,
but the Xnest case is identical.

kbr@pangea.ca (Kip Rugger) wrote:

>I don't agree with your assertion that the selection should propagate.
>For example, you might want to use Xnest to isolate a nasty client for
>security reasons; in this case you would want maximum isolation.

Good point. I think it should be a configuration option, then.

>I posted code to this group in December 2002 which can do such propagation.
>It was actually developed to allow cut/paste between virtual terminals,
>but the Xnest case is identical.

Thanks. While your code (article ) does
allow me to paste between windows in Xnest and the parent X server, it seems
that it may have a bad interaction with the mechanisms in Exceed that
automatically propagate between the Windows clipboard and the X selection.

In particular, I can copy from Windows applications into clients in the
Xnest server fine. But when I try to copy from clients in the Xnest server
to Windows applications, nothing propagates. Also, when I try to copy from
clients in the Xnest server to an X client running directly under Exceed,
the binary I compiled from your code exits with the following error:

X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 18 (X_ChangeProperty)
Atom id in failed request: 0xde
Serial number of failed request: 36
Current serial number in output stream: 37

(The serial number varies, but the current number in the output stream is
always 1 greater).

I'd appreciate any advice you have on fixing this, though I realise it may
be Exceed's fault and there's little I can do about a closed source
application.

Also, it seems to me that a "cleaner" solution for this particular case
would be to modify Xnest, rather than having a separate helper application.
I'd also appreciate any hints you might have on how to do this. I don't
entirely understand what the different X events in your code are for, though
doubtless I could track that down from the relevant documentation.

Cheers,

Ganesh

Ganesh Sittampalam wrote:
>kbr@pangea.ca (Kip Rugger) wrote:
>
>>I don't agree with your assertion that the selection should propagate.
>>For example, you might want to use Xnest to isolate a nasty client for
>>security reasons; in this case you would want maximum isolation.
>
>Good point. I think it should be a configuration option, then.

Perhaps. Remember Xnest and similar programs (Xvfb, vnc) operate mainly
at the device-driver level. This is what makes them useful for debugging
the X server and for `chroot jails'. A seamless integration between two
servers -- a master/slave relationship -- is more ambitious, and would
likely require an extension to export more state information. This is
doable, but I don't think you would want to call the result Xnest.

>>I posted code to this group in December 2002 which can do such propagation.
>>It was actually developed to allow cut/paste between virtual terminals,
>>but the Xnest case is identical.
>
>Thanks. While your code (article ) does
>allow me to paste between windows in Xnest and the parent X server, it seems
>that it may have a bad interaction with the mechanisms in Exceed that
>automatically propagate between the Windows clipboard and the X selection.
>
>In particular, I can copy from Windows applications into clients in the
>Xnest server fine. But when I try to copy from clients in the Xnest server
>to Windows applications, nothing propagates. Also, when I try to copy from
>clients in the Xnest server to an X client running directly under Exceed,
>the binary I compiled from your code exits with the following error:
>
>X Error of failed request: BadAtom (invalid Atom parameter)
> Major opcode of failed request: 18 (X_ChangeProperty)
> Atom id in failed request: 0xde
> Serial number of failed request: 36
> Current serial number in output stream: 37
>
>(The serial number varies, but the current number in the output stream is
>always 1 greater).
>
>I'd appreciate any advice you have on fixing this, though I realise it may
>be Exceed's fault and there's little I can do about a closed source
>application.

I can't help you with Exceed -- at work we burned everything Microsoft
several years ago and have never looked back.

The BadAtom error appears to be a bad `type' parameter to XChangeProperty.
I wrote this program back in 1994 when everything would have had type
STRING, which is one of the fixed-encoded atoms and thus server independent.
Nowadays you are likely to hit UTF8_STRING which must be translated
properly. Somehow I managed to screw up the translation in 3 of 4 calls
to ChangeProperty. Diff attached.

>Also, it seems to me that a "cleaner" solution for this particular case
>would be to modify Xnest, rather than having a separate helper application.
>I'd also appreciate any hints you might have on how to do this. I don't
>entirely understand what the different X events in your code are for, though
>doubtless I could track that down from the relevant documentation.

The problem is that selection is a global resource, rather than a hierarchical
one. It really should be controlled in one place -- probably the top level
server -- but X protocol does not support this. Writing an extension to
do so would not be that difficult, and you could also support global control
of things like grabs. But realize that you are now modifying the server
as well as Xnest. This probably means you want to look at Xwin to replace
Exceed so that you can get the source.

Modifying the X server is not for everyone, but if you're up to a challenge,
then by all means, give it a try.

>
>Cheers,
>
>Ganesh


--- selection.c.save Fri May 13 14:25:00 1994
+++ selection.c Wed Dec 17 11:24:46 2003
@@ -114,9 +114,9 @@
if (type != None) {
xlate(owner, f, type);
XChangeProperty(dpy[owner],
win[owner],
- E.property, E.type,
+ E.property, type,
format,
PropModeReplace,
prop, nitems);
XFree(prop);
@@ -151,9 +151,9 @@
&bytes_after, &prop);
xlate(req, f, E.property);
xlate(req, f, E.type);
XChangeProperty(dpy[req], requestor,
- E.property, type, format,
+ E.property, E.type, format,
PropModeReplace,
prop, nitems);
XFree(prop);
XSendEvent(dpy[req], requestor,
@@ -175,9 +175,9 @@
&bytes_after, &prop);
xlate(req, f, E.atom);
xlate(req, f, E.type);
XChangeProperty(dpy[req], requestor,
- E.atom, type, format,
+ E.atom, E.type, format,
PropModeReplace,
prop, nitems);
XFree(prop);
}