Hi John, hi Alex, hi list,
On Do 20 Jan 2011 04:57:48 CET "John A. Sullivan III" wrote:
On Thu, 2011-01-20 at 02:09 +0100, Oleksandr Shneyder wrote:
Am 19.01.2011 17:03, schrieb John A. Sullivan III:
On Wed, 2011-01-19 at 16:40 +0100, Oleksandr Shneyder wrote:
Thanks, Oleksandr. This is helpful. Phil and I (mostly Phil) do have vcxsrv up and running with libssh and on everything from Windows XP to Windows 7. It has eliminated all the crippling bugs and appears to perform better. We can probably send you the simple code changes we made if it will save you some time.
However, we still have some of our original issues. I'll restate them using your numbers from above.
Thankfully, vcxsrv is working perfectly fine in full screen and rootless as well as multi-windows so these possibilities are now open to us.
That's an important point but it still leaves us with the original dilemma: if we start X before we know the session parameters, we cannot run fullscreen or rootless. More accurately, we can but we must choose one of the three (fullscreen, rootless, or multi-window) before we know the session parameters. If we default to full screen, then we get a full screen but the session may only paint into a part of it and leave the rest of the screen black. My understanding from Phil is that it does not automatically resize the session to consume the entire windows like it does on Linux. Even if it did, fullscreen is not what all users will want (or rootless or multi-window - exactly why we should give them a choice). My guess would be the delayed start would be a worthwhile trade-off for giving users important options. Thoughts? Vehement disagreements? Insults? (well . . . hopefully no insults :) )
Argh!! That's really unfortunate. Our practical experience is that losing <ALT><TAB> significantly impacts productivity and makes the users more likely to resist transitioning to X2Go desktops.
I think I did not communicate this well in my original email. I'm not referring to the "magic pixel" to minimize the X2Go session. What we find happening VERY frequently is that a user has an application maximized in their X2Go desktop. They then want to close the application and do so by clicking on the top right most "x" box on the title bar, i.e., the shortcut to close (alongside restore and minimize). They click the top right most one because that's the habit they have built for closing maximized applications and briefly forget that the top rightmost "x" is not the one for the application but the one for the X2Go session. Thus, they accidentally close their X2Go session rather than the application. If they were working in full screen mode, the X2Go desktop would be more like their physical desktop rather than a desktop within a desktop and thus their habitual actions are less like to be a problem. It also gives <ALT><TAB> and eliminates the confusion we frequently hear among end users as they say "now where am I - my virtual world or my physical world".
Thanks again - John
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
Hello John, All I wrote is relative to Xming, not vcxsrv. Sure, we will change a behavior of X2Go client to make it work as good as possible with new Xserver. For example, we can start Xserver after the users choose his session, in this case x2goclient can use a time, that user need to type password to start Xserver. It is possible, that vcxsrv have not alt+tab problem in fullscreen mode. But I must do some researches before we will replace Xming with vcxsrv. I hope, I can give you an answer next week. <snip> Thanks, Oleksandr. We just wanted to make sure we weren't overlooking something before we set about changing the start sequence. We'll get working on our proposed changes to incorporate vcxsrv right away - John
If I understand it correctly the different setups require two
different XServer modes: fullscreen and multi-window mode.
The multi-window mode can handle many different sessions (desktop
type, rootless type), so these won't need separate XServer instances.
Thus only fullscreen sessions would need their own XServer instances.
How about that? (Or has anyone already provided this suggestion?).
I am thinking of choosing this approach for some later version of
pyhoca-gui. This would also be neat on Unix (have separate ttys for
local session and X2go sessions).
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...