On Sat, May 23, 2009 at 7:36 PM, Dwight Schauer <[email protected]> wrote: > I just started using xpra recently as I've gotten to where nomachine's > inability to consistently reconnect to sessions upon link loss was too > unbearable.
Ugh, that does sound like a pain. Xpra is still somewhat immature, but hopefully we'll be able to get it working for you! > For the most part xpra is working very well, at least it has always > been able to reconnect to an existing session without any problems. > > I have encountered 3 usability issues with xpra however. > > 1) Strange behavior when running with Nvidia's twinview. An xpra > window will be running fine until I move it another monitor. After > that the menus are all out of place and mouse clicks no longer go to > the right places. Killing the xpra connection and starting it up again > allows me to resume work normally however (until I forget and move > them though). This issue I've worked around by using xpra in a local > nomachine stripped down xfce session. What's the total resolution of your desktop across both monitors? (E.g., what does 'xwininfo -root | grep geometry' say?) One limitation of xpra currently is that the Xvfb it uses in the background must run at a resolution that is at least as large as any real display that you attach from. For now it's just hardcoded to 2048x2048 on the theory that that's pretty darn big :-). But if you're running into that limit, then we can bump it up a bit. (If you want to try yourself, search for the string '2048x2048' in xpra/scripts/server.py, change it, and restart your session.) (The only downside to increasing the default -- and the reason that it's not set to like 100000x100000 now -- is that Xvfb will actually allocate a chunk of memory of whatever size is specified, which is sort of wasteful. The real solution -- which will also fix some more minor weirdnesses with menu placement etc. -- is to teach Xvfb how to resize its framebuffer on the fly using RANDR. But I haven't gotten up the courage to go poking at the X server directly yet, myself. No-one's complained about the current 16 meg buffer yet, though, so I bet they wouldn't complain about, say, a 32 meg buffer.) > 2) Minor issue, weird sloppy focus mouse behavior behavior. I've > noticed this both with xfwm and metacity. Focus follow mouse works > some of the time, but quite often it stops working and I have to click > on the title bar of the window in question to gain focus. For my > regular local (non xpra) windows sloppy focus follows mouse always > works. Like I said, this is a very minor issue, and one I could easily > live with. Several people have reported issues with focus failing to be delivered to windows when it is supposed to be. So far I am mystified. (It never seems to happen here, and the logs I've seen seem to show everything working correctly.) Is it any apps in particular that you notice this with? If it's reliable, can you run the client and server with --debug=all, and send me the output from the client plus the server's ~/.xpra/:<display>.log file? > 3) Jerkiness and frequent momentary stalling, which appears to the be > issue mentioned here: http://partiwm.org/browser/README.xpra#L214 > > With a VTE like xfce's terminal, I don't notice any problems. However, > I use Geany http://www.geany.org/ quite bit and it seems to frequently > exhibit the stalling and not responding for a few seconds issue. With > nomachine I did not have this issue. Ugh, that sounds unpleasant. What sort of connection are you using? Is Geany the only app running when this happens? I'll have to think how to add some sort of latency logging so we can debug further.. -- Nathaniel _______________________________________________ Parti-discuss mailing list [email protected] http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
