Tried the Python3 builds of the Xpra 2.4 Windows client and unfortunately it has a lot of graphics artifacts (ghosting when moving a terminal, some applications being completely washed out and illegible, etc). I'll continue to use the standard 2.4 build for the time being.
On Thu, Aug 30, 2018 at 11:05 AM Ben Sferrazza <[email protected]> wrote: > > > On Wed, Aug 29, 2018 at 9:06 PM Antoine Martin <[email protected]> > wrote: > >> On 30/08/18 07:15, [email protected] wrote: >> > Now that I've established a connection again with Xpra server 2.3.3, I >> > can try to address some of the issues I was/am experiencing. I haven't >> > used it enough to encounter the first two issues, which were the most >> > debilitating and largely made it unusable for me before (the stuck focus >> > issue and the disappearing mouse cursor). Once I can re-create those >> > I'll have more to offer. >> > >> > On Tue, Aug 28, 2018 at 8:42 PM Antoine Martin <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > On 29/08/18 03:23, Ben Sferrazza via shifter-users wrote: >> > > Hi. I'm including my previous correspondence below, as it will at >> > least >> > > offer some history about my setup and prior issues. >> > > >> > > I stopped using Xpra a few months ago due to numerous bugs that >> > made it >> > > unusable (this is using a Linux server and Windows client). >> > > >> > > 1. windows get stuck with on-top focus >> > Which windows from which applications? >> > >> > >> > This was by far the most egregious bug. It seemed to happen at random >> > and affected all applications. Considering I do a lot of work in a >> > terminal, chances are it was a terminal such as xfce4-terminal. I will >> > report back once this occurs again. My only solution was to minimize the >> > window, rather than simply clicking on another window to give it focus. >> This does ring a bell, but I don't think I ever saw it myself. >> https://xpra.org/trac/ticket/713 >> https://xpra.org/trac/ticket/1381 >> >> This could be a platform specific bug (ie: affecting mswindows clients) >> in which case the newer Python3 GTK3 builds may fare better. >> > > Yes, those tickets describe the exact same behavior I'm experiencing (or > at least was with Xpra 2.2) using the Windows client and Linux server. I'll > give one of the Python3 builds a shot. Is there a particular build that you > think would be the most stable (with the understanding that I likely need > 2.4 and the paramiko ssh client given the tcsh issues I was experiencing)? > > >> >> > > 2. disappearing mouse cursor when using X11-only no-toolkit apps >> > that use >> > > inverted black mouse pointer after clicking on something >> > Do you have a specific application we can use to reproduce the >> problem? >> > >> > Unfortunately the application I encountered this issue with the most was >> > Cadence's Simvision, a digital simulation waveform viewer that's part of >> > their CAD/EDA software suite. The only observation I had was that it is >> > an application which does not make use of a modern toolkit, such as GTK. >> > Perhaps it's using Motif? When you click on a menu the mouse cursor >> > inverts to a right-pointing black cursor, which is a cursor internal to >> > the program and is not replaced by the client's cursor. That's when the >> > menu items would disappear. I've attached a screenshot of it working, >> > which required using an actual camera, as the inverted black cursor is >> > not picked up by the Windows print screen function. >> There were bugs in the cursor code on mswindows, including some fixed >> quite recently, those could have caused the problems you describe - it >> should now revert to the default cursor in case of failure. >> > > OK that's great to hear. I'll keep an eye out to see if this bug occurs > with the newer builds > > >> >> > > 3. some windows don't show window bar until resized (e.g. gvim >> > always gets >> > > placed in upper-left without window bar) >> > Some applications do weird things with their geometry sometimes, >> gvim is >> > one of those. That said, I've just tried it and it worked fine and >> it >> > does seem to request to be placed in the top left corner. >> > Please provide more details so we can reproduce the window bar >> problem. >> > (ie: server os and version, gvim version, etc..) >> > >> > >> > This isn't a showstopper. I'm using gvim 8.0.586 with the latest Xpra >> > 2.3.3 on Linux l-server-13 2.6.18-398.el5 #1 SMP Tue Sep 16 20:50:52 EDT >> > 2014 x86_64 GNU/Linux. I've attached a screenshot showing this behavior. >> > It corrects itself once I do any resizing of the window (which must >> > initiate a redraw event). Perhaps Xpra could force a redraw event after >> > opening the window? >> I bet it's not a redraw event but a window "configure notification" that >> gvim is waiting for. If I can reproduce this, it should be fixable. We >> can synthesize an event if needed. >> What's the server version? CentOS 7.5? >> > > Actually the primary machine I use it on is CentOS 5.11 (unfortunately > needed apparently to support an older version of Cadence IC5). Though I did > build an entirely bootstrapped toolchain on this machine, so its using the > latest glibc (2.19) for the older kernel it uses (2.6.18), as well as the > latest versions binutils and gcc. Xpra and all of its dependencies were > built against this toolchain. However, I did just run Xpra 2.3.3 on a > CentOS 7 machine we have here at work and with that same version of Gvim > (8.0.586) I experience the same issue of it going to the top left corner > and not showing the title bar until the window is resized. > > >> >> > > 4. dialog box black bars (appears to be trying to add >> scrollbars?). >> > Can you provide example applications we can use to reproduce the >> > problem? >> > I've never seen that anywhere except when X11 windows are smaller >> than >> > the minimal window size on mswindows, then we have to pad it with >> > something. >> > >> > Perhaps that's all it is. >> Sadly, it's not. From the screenshot you attached, this looks like a >> different problem. >> >> > Certainly not a big deal, and just a cosmetic >> > annoyance. I've attached an example of this issue from a dialog box that >> > pops up using diffuse. Perhaps this would be too much work, but a >> > slightly more pleasing visual than black bars would be to sample the >> > color of the edge pixels and use this color (or an average of samples) >> > to extend the window to the minimum size. >> Fixing the problem might be easier. (it looks similar to the gvim >> problem - the application gets the window geometry wrong) >> Do you have a sample application I can use to reproduce it? >> > > It was happening using diffuse (the graphical diff tool). If I'm comparing > two files and edit one of them outside of diffuse, diffuse will pop up a > dialog asking if you'd like to reload the file since it detected a change. > That small dialog was showing the black borders. However, I'm not seeing > the same issue again. Though there is another issue that could perhaps be > masking this. For some reason, many of my GTK applications (diffuse, gvim, > etc) are not using the window decorations and icons I have chosen when > using Xpra. This was working just fine in Xpra 2.2, and the correct theme > and icons are shown when I VNC into the same machine. Oddly enough, Emacs > does use the correct decorations even with the latest Xpra. > > >> >> > > 5. windows are all blank (white) when returning into work after >> > several >> > > hours (requires restarting client) >> > That's a known "feature" of some opengl drivers, they clear the >> video >> > memory when the system goes into idle or suspended state. >> > We try to detect that (slowing down the refresh rate) and then >> refresh >> > the screen when the session resumes, but that doesn't always fix >> things. >> > You should not need to restart the client: minimizing the windows >> and >> > restoring them should be enough. >> > Alternatively, turn off opengl in the client - the client >> performance >> > will be much lower. >> > >> > >> > OK, the next time this occurs I'll try to simply minimize the windows. >> > >> > >> > > 6. flickering clipboard icon in systray >> > That's a very obvious sign that something is not right and >> something is >> > constantly requesting the clipboard contents. This will cause >> > unnecessary traffic and instability. Try to figure out what is >> causing >> > this and stop it. Usually, this is caused by clipboard managers or >> other >> > clipboard synchronization tools (synergy, virtualbox, etc). >> > >> > >> > Hmm. I don't have anything running like that. No VNC session, >> > VirtualBox, etc. Microsoft's Remote Desktop is enabled, but certainly >> > nothing is currently connected to it. It seems to flicker at a rate of >> > once every 4 seconds or so. >> OK, then it's not so bad that it will cause instability. >> Some clipboard managers request the clipboard contents as soon as >> they're available, swamping the system with clipboard events. >> If you wish, you can confirm the rate of change by running the client >> with: "--debug=clipboard" >> >> > It seems periodic, in the mathematical sense >> > of the word. My PC at work is a standard issue Dell box. It has the >> > typical Dell bloatware and some Symantec security software (not much >> > control over this), but can't think of anything that could be >> > potentially interfering with the clipboard. Any suggestions how to >> > determine the cause? >> Sorry, I don't know how. The API we use to interact with the clipboard >> does not offer any information about the application which set or >> queried the clipboard. Some third party tools may exist to monitor the >> system at this level. >> > > Is there a way to turn off the flickering, just to avoid the annoyance of > it? Also, it seems the newer versions of Xpra place a small Xpra icon > imposed on top of a window's regular icon. Is there a way to turn off this > feature, as it's difficult for me to see the original icon, since it's > resized smaller. > > Thanks, > Ben > _______________________________________________ shifter-users mailing list [email protected] http://lists.devloop.org.uk/mailman/listinfo/shifter-users
