On Thu, Sep 11, 2008 at 3:33 PM, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > 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.
The CM and WM can be different things in principle, but usually you want a unified interaction with your desktop, and it's easiest to do that if you just put everything into one address space. In xpra's case, though, we really need to be the window manager anyway -- being the window manager means that when a client window gets resized, we can resize the real window on the server side. >> -- 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. Sure, the rendering gets funneled into some array offscreen somewhere, but the "real window" is still where-ever it is, just invisible. Input handling, for instance, is not affected by compositing at all. At some point there may or may not be a way for a CM to hook into input event processing (the use case is for using the mouse to interact with distorted windows; the status is that keithp was going to add it and then realized he couldn't figure out how to implement it, so... not holding my breath). But even if we had support from the server to let us remap input event coordinates from client space to server space, that wouldn't solve the problem with pop-ups like menus and tooltips -- remember that they're just ordinary windows that appear at some absolute position on the screen. From the point of view of the WM, the fact that they are position in a very precise way relative to some other window (like the main app window) is just a coincidence; there's no way to look at a menu window and figure out which app window it belongs to, and therefore if the client<->server coordinate transformation is different for different apps, then you can't figure out which transformation to apply and you lose. >>> * 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. Well, I guess I can look on the bright side: it's creating lock-in! ;-) > 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. I've been going around for a while trying to figure out how to get keymap handling to be... as close to non-broken as feasible, anyway... and I think the solution is probably to just ship over the client's full keymap/modifier map when it connects. (And pray that XKB is not doing anything too clever.) So this should be possible to fix, I think, and it's even a high priority, it's just also a pain. > - 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. I think the answer to all this weirdness is "gconf". I have no idea what defines a "gconf session", though, or why all the apps run against xpra would be isolated from your main desktop's gconf settings *except* for gnome-appearance-manager. I'd be curious to know too, if you figure it out. > - 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. That's curious -- I guess in principle there's a race condition; assigning focus to a window is not instantaneous (the way it actually works is, the WM tells the window to take the focus, then the window issues a request to take the focus. At least sometimes. X is awesome), so it would be possible for a key event to slip in before the focus actually changes. But the exact same race condition exists for ordinary window managers too, and you'd only lose one keypress at most from this, so... maybe not. I don't know what would cause this. Does the window styling change to reflect it getting the focus? (Cursors appearing and starting to blink, that kind of thing?) -- Nathaniel _______________________________________________ Parti-discuss mailing list [email protected] http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
