Nathaniel Smith wrote:
On Mon, Feb 16, 2009 at 11:58 PM, Antoine Martin <[email protected]> wrote:
Traceback (most recent call last):
 File "wimpiggy.lowlevel.bindings.pyx", line 1269, in
wimpiggy.lowlevel.bindings.x_event_filter
TypeError: 'dict' object is unindexable
(...)
This messsage gets repeated regularly and the command never returns...

Yes, this is a bug in some versions of Pyrex (including possibly the
latest version, I'm not sure). There's a workaround in the current
development version of xpra, or you can just make the change yourself
to your copy:
http://lists.partiwm.org/pipermail/parti-discuss/2009-January/000072.html
Thanks, I'll try that out.

Also, some thoughts and questions:
* How hard would it be to use TCP sockets?
It would make it possible to use other transports, like openvpn/etc.. or
just plain TCP for testing.

It'd be pretty trivial -- all the core code pretty much just wants a
socket, it doesn't care where it came from -- just you'd have to deal
with security and the UI and all, which is a hassle.

Note that we already use plain sockets when connecting to a local
server (just they're Unix domain, rather than TCP), which is
sufficient for testing.
Cool, that's what I figured.

Do you have a use case in mind? Is using ssh inconvenient for some reason?
Yes and no, ssh is nice but when dealing with remote desktops openvpn may be more appropriate. As long as it can be done with a simple TCP socket, we can leave the security/authentication decisions to another layer/piece of software.

* How hard would it be to allow multiple clients connected to the same
server? (either with or without the multiple input X patches)

This, sadly, is very difficult. The problem is that xpra essentially
acts as a "window manager proxy". That is, your average X app cannot
control where its windows end up on the screen, how large they are,
etc. It makes a request, and then the WM does whatever it wants. When
running under xpra, xpra notices that request, ferries it over to the
xpra client, and then the user's actual WM on their local machine
makes all the decisions about window sizing and location.

But if there are two xpra clients, then whose WM makes the decisions?
If you and I are connected to the same xpra server, and my WM is
making the decisions, then how do I communicate those decisions to
your WM? (Remembering that there is no way for a client to force your
WM to do something.)
Yes, that is the sticky point.. Although there are tools to boss them around, I don't think they are extensive enough to do it all.

It *might* be possible to make this sort-of work when everyone
connected has a very friendly WM that is willing to be bossed around
by the xpra client, but it gets pretty hairy pretty quick. Of course,
if anyone wants to try, feel free, it'd be a neat hack.

The other problem is that everyone would have to always have their
xpra windows at the same locations on all their screens.
Does it?
Can't it just all be relative to the local window manager?

It seems to
me that this removes one of the main advantages of xpra over VNC, and
maybe at that point one should just use VNC.
Yes, that's what I thought...
vnc or rdp would be fine for doing this session mirroring.
Could just run vnc/rdp on the XVfb too for this special case.

Thanks!
Antoine

_______________________________________________
Parti-discuss mailing list
[email protected]
http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss

Reply via email to