[Resending to list] On Thu, Sep 11, 2008 at 9:40 AM, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > Nathaniel Smith wrote: >> You're a machine. > > xpra really solves a problem for me. I mostly work on my laptop, but > when I'm at my desk I want to use the big screen and keyboard. My ideal > would be to have a synergy-like mouse/keyboard sharing that allows me to > drag windows from one display to another, but xpra is a very close > second. Without it, the transition loses so much work context that its > really only worthwhile making the switch at the beginning of the day; > now I can switch on whim.
Glad to hear it! That's a use case I hadn't though of -- I just plug the big monitor/keyboard into my laptop and xrandr-over onto it, and use xpra for running stuff on the big iron in the server closet. > That said, I have a blue-sky wishlist: > > * Rather than using a Xvfb server, use the main server, with the > theory that you'd be able to use full hardware acceleration, esp > useful for 3D stuff. The downside is that I don't know how you'd > actually make it all fit together without being the window manager > (which I guess is what you're intending for parti). > * Mouse-keyboard sharing Yeah, it'd be tricky -- xpra *is* the window manager for the server-side-server (if that makes sense), but it isn't a very *good* window manager, by conventional standards -- if you actually look at that server (you can run xpra against an arbitrary X server using 'xpra upgrade', which I do against Xephyr sometimes for debugging), then you'll see that it's just a big blank screen with some black squares on it. Most people probably won't want to dedicate a whole video card to that. (Also, compositing/3d/etc. don't play together terribly well yet, but that will be fixed in the next 6 months or so.) If what you really want is for xpra to grow into an ordinary window manager, that *also* has the ability to "expand onto another screen", then there are a lot of things that would have to be overcome: -- Trying to compete with existing window managers on their home territory is very hard -- Xpra's handling of the server is pretty delicate -- for instance, it needs the ability to place windows anywhere (because windows need to know their real coordinates for things like menu placement to work), it needs the ability to track key presses, etc. I'm not sure you could have regular interaction with an X server *and* have some apps running against it exported without more cooperation from X. Things that might be more possible: -- running against a very large VNC root, which normally you look at one part of on your laptop, and then when you're at home you can make the second monitor display the rest -- teaching xpra to "take over" a session -- bump the existing window manager out of the way, put up a screensaver or whatever on the original screen, export all the programs running in it over to another system (that is running just an X server and a window manager and the xpra client). Later, you can kill the xpra server and restart the local window manager. > * Cut'n'paste between xpra and desktop I actually wrote most of this, before running into some limitations in the gtk+ clipboard API. Need to figure out whether I want to use ugly hacks to work around those, or to implement clipboard handling from scratch (the mechanics of the X clipboard protocol are pretty hairy). > * Using something like avahi to make the machines automatically hook > themselves up (or at least display a gui notification) There's the joy of multiple use cases -- this wouldn't do much for me, so I'm not sure what the best design would be, but feel free to file a wishlist bug about this. Probably wouldn't be too hard to add. > * What's the wire protocol for the image data? Would using vnc or > something be an improvement? At the moment, it's basically PNG -- which is to say, we just dump 24-bytes-per-pixel RGB onto the wire, and then the whole protocol is (by default) run through a zlib stream. This approach is somewhere between slightly and much better than PNG-encoding each redraw packet because using a single zlib stream for all of them means that inter-packet similarity is also compressible. "VNC" uses about 73 different image compression strategies depending on which version you're using and various other things; I'm sure some of them work better, but I don't know if they work enough better to matter. Modem users were a higher priority when VNC was designed than they are now, and latency is usually more important than bandwidth. Switching to a planar coding might improve compression relatively easily. The other easy thing is to degrade the color quality by using fewer pixels. (I'm not sure I have the stomach to deal with palletizing, though.) -- Nathaniel _______________________________________________ Parti-discuss mailing list [email protected] http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
