[X2go-dev] X2Go Client Code Changes

[John A. Sullivan III]

On Wed, 2011-01-19 at 16:40 +0100, Oleksandr Shneyder wrote:
> Hello John, Phil, Moritz, list,
> 
> I'll tray in this short mail to give answers on all your questions.
> 
> 1) Xming working correct with nxproxy only in "multiwindow" mode.
> 2) Xming need some time to start and it started by parallel thread to
> reduce delay. It make not sense to start it by x2goconnections, this
> will only enlarge connection time on 3-5 sec and bring no effort
> 3) Xming just ignoring "keyhook" option (I think because of multiwindow
> mode)
> 4) "right top click" is a feature of x2goagent, not X11. It will be
> possible to make changes in x2goagent to disable it or make configurable,
> 
> We would be happy to say "Good By" to Xming and old xorg-6 sources. I'll
> take a look on VcXsrv this week. It looks good, seems to be gpl-3
> (http://sourceforge.net/projects/vcxsrv/develop) and based on the xorg
> git(http://vcxsrv.sourceforge.net/) git = Xorg-7. I think, John and Phil
> made a good experience with VcXsrv. I'll make some tests and will try to
> use it with x2goplugin. Possible, I'll need to make some changes, as I
> have made it with Xming. If VcXsrv will work good with x2goclient, we
> will include it in windows installer.

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.

1) Thankfully, vcxsrv is working perfectly fine in full screen and
rootless as well as multi-windows so these possibilities are now open to
us.

2) 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 :)  )

3) 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.

4) 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