Nathaniel Smith wrote:
> [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.
>
Unfortunately the video in my laptop isn't capable of driving a big
monitor with decent performance. I also use my desktop machine in its
own right, so intermixing windows is pretty useful.
>> 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.
>
Yes. It's basically just a compositing engine which happens to ship the
bitmaps somewhere else before compositing. It would be nice if things
were sufficiently nicely factored so that the compositing and the window
manager could actually be separate things rather than tied together.
But I've never really understood how all that stuff fits together in detail.
But if it could be done in a lightweight way (ie, not too much penalty
when displaying locally), I'd run everything under xpra all the time.
> (Also, compositing/3d/etc. don't play together terribly well yet, but
> that will be fixed in the next 6 months or so.)
>
Yes, that's what I'd hope.
> 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
>
Yes. You wouldn't want to have to rewrite one.
> -- 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.
>
How does that work with regular compositing? Presumably each window
renders its pixmap offscreen somewhere without worrying about
interference from other windows, and then it all gets mushed together.
> 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.
>
That might be possible, though at the risk of losing state. Restarting
a window manager seems to be a delicate thing, and I've often noticed
windows getting into strange states (WM bugs, no doubt).
>> * 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).
>
Yeah. I've missed this particularly today. I've ended up migrating
more and more things into the xpra session just so I can cut'n'paste
between them.
Other annoyances:
- The sticky modifier problem has been pretty irritating. I don't know
if there's any useful way to deal with it, but I've been getting stuck
ctrl and alt keys all over the place.
- Things running in the xpra session have their own gtk themes and
fonts. I tried running gnome-appearance-properties from within the
xpra session to set them, but it only affects the main X server's
settings. Most irritiating minor difference: the behaviour of
double/triple-clicking to select lines/words is different, and I've got
no idea where that's even set.
- Focus seems erratic; I point to a window to focus, but my keyboard
input doesn't appear. Sometimes this is just the stuck modifier
problem, but sometimes it just seems to be a matter of trying again.
>> * 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.
>
I'm not even sure how useful it would be, but I thought I'd throw it out
there.
>> * 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.)
>
I haven't tried using it over anything other than a Gbit lan, so
bandwidth and latency haven't been issues at all. And VNC is certainly
messy.
J
_______________________________________________
Parti-discuss mailing list
[email protected]
http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
