Subject: Can be fixed by reverting winmultiwindow.patch

From: Michael DePaulo <[email-masked]>
Date: Mon, 22 Jun 2015 09:18:28 +0200

I determined that this bug can be fixed by reverting Alex's
winmultiwindow.patch to VcXsrv, which was a workaround for #594 and
has been included in both 1.15.2.x and 1.17.0.0-x of the VcXsrv
X2Go/Arctica builds.

I also created a bug report & branch in the GitHub project for VcXsrv
(X2Go/Arctica builds):
https://github.com/ArcticaProject/vcxsrv/issues/3
https://github.com/ArcticaProject/vcxsrv/commits/bugfix/bug3

I will be releasing X2Go Client for Windows 4.0.4.0-2015.06.22 with
the OpenSSL updates. When I do, I will offer an alternate build with
VcXsrv with winmultiwindow.patch reverted. This will be a workaround
until we make a change to VcXsrv that fixes both #594 and #883

-Mike#2

---

From: Mike Gabriel <[email-masked]>
Date: Tue, 23 Jun 2015 10:51:15 +0000

Hi Michael, hi Alex,

> until we make a change to VcXsrv that fixes both #594 and #883

@Alex: Before Michael starts diving into your patch for fixing #594,  
do you see any chance for taking a look at the regression described in  
#883 introduced by your patch? Any feedback on a possible solution  
would be highly welcome.

Thanks,
Mike
-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: [email-masked], http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

---

From: Oleksandr Shneyder <[email-masked]>
Date: Tue, 23 Jun 2015 21:22:41 +0200

Hi,
I'll look on it on Thursday-Monday,

regards,
Alex

Am 23.06.2015 um 12:51 schrieb Mike Gabriel:
> @Alex: Before Michael starts diving into your patch for fixing #594, do
> you see any chance for taking a look at the regression described in #883
> introduced by your patch? Any feedback on a possible solution would be
> highly welcome.
> 
> Thanks,
> Mike

-- 
-----------------------------------------------------------
Oleksandr Shneyder        | Email: [email-masked]
phoca GmbH                | Tel. : 0911 - 14870374 0
Ludwig-Feuerbach-str. 18  | Fax. : 0911 - 14870374 9
D-90489 Nürnberg          | Mobil: 0163 - 49 64 461

Geschäftsführung:
Dipl.-Inf. Oleksandr Shneyder

Amtsgericht München | http://www.phoca-gmbh.de
HRB 196 658         | http://www.x2go.org
USt-IdNr.: DE281977973
-----------------------------------------------------------

---

From: Mihai Moldovan <[email-masked]>
Date: Wed, 24 Jun 2015 04:04:43 +0200

> I'll look on it on Thursday-Monday,

I've had a look myself and played around with it, assisted by Mike#2.

I don't see any benefit in applying this patch and suggest dropping it.

As far as I've gathered, it's supposed to create a "fake" fullscreen window by
removing the borders and title bar IFF the window extents are greater or equal
the monitor's size, with "monitor" being the monitor that holds most of the
window's contents.

It doesn't make sense to do something like this in multiwindow mode. It *does*
make sense to do something like this in fullscreen mode, but the patch targets
multiwindow mode.

For this mode, it's plain wrong and only causing trouble. You can't fix it
either, because you're missing a crucial bit of information: when *do* you want
to have a "fake" fullscreen window?

Why did you write the original patch exactly? What was the use case that this
patch fixed?

Mihai

---

From: Mike Gabriel <[email-masked]>
Date: Wed, 24 Jun 2015 08:57:49 +0000

Hi Alex,

> I'll look on it on Thursday-Monday,

Thanks!

My suggestion would be to drop that patch and try-out the  
-multimonitors and the -screen options of VcXsrv instead (as also  
proposed by Ionic and mikedep333 on IRC):

"""
-[no]multimonitors or -[no]multiplemonitors
Use the entire virtual screen if multiple
monitors are present.

[...]

-screen scr_num [width height [x y] | [[WxH[+X+Y]][@m]] ]
Enable screen scr_num and optionally specify a width and
height and initial position for that screen. Additionally
a monitor number can be specified to start the server on,
at which point, all coordinates become relative to that
monitor. Examples:
-screen 0 800x600+100+100@2 ; 2nd monitor offset 100,100 size 800x600
-screen 0 1024x768@3 ; 3rd monitor size 1024x768
-screen 0 @1 ; on 1st monitor using its full resolution (the default)
"""

Greets,
Mike
-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Oleksandr Shneyder <[email-masked]>
Date: Mon, 29 Jun 2015 11:36:19 +0200

Hello,

I'll try to explain why I wrote this patch. In x2go client you have
possibility to run x2go session in "full screen" mode on only one of
physical displays. It has nothing to do with xinerama. It is very useful
if you have a client with several monitors and you want to have the
native session on one monitor and  full screen remote session on second
monitor. It's also not a full screen mode, because you are using only a
part of virtual display, so you are not running a vcxsrv in full screen
mode. This scenario widely used in enterprise environments.

To create a full screen window on only one physical display you need to
 maximize the window on this display and remove the window decorations.
Unfortunately on some setups it was not possible to maximize an
X-window. As soon as you tried it, vcsrv resized a window with a size
that was bigger then physical display and reseted a window decorations.
After some investigation I figured out that it's only happening on the
displays with negative coordinates, for example if a secondary display
is left of or on the top of primary display. So I assumed that vcxsrv
doesn't work properly with negative coordinates. Unfortunately I didn't
manage to find a bug in vcxsrv, so I wrote a workaround that checking if
the windows size is bigger than a physical display and in this case
resizing a window on a screen size. Usually it is no ways to create a
windows that are bigger then a physical display, so that workaround
worked well. Unfortunately in the case described in this bug report,
nxagent creating window that is bigger then screen size, because screen
was resized. This is why a firefox or whatever window will be maximized
and window decorations will be erased by a workaround.

I don't think that we can remove this workaround, because it will brake
many productive x2go setups. At least as long as we won't find a bug
handling negative screen sizes in vcxsrv and now I have not sufficient
resources to do it.

I suggest to check in workaround if screen has negative coordinates and
omit any window that placed on the displays with positive coordinates.

Also in x2go client I'll check a window size and decoration flags and
reset it in the case if x2go session is not a multi window session.
This fill fix #883 and won't brake a multi monitor setups.
I'll do it today or tomorrow.

regards,
Alex

Geschäftsführung:

---

From: Mihai Moldovan <[email-masked]>
Date: Mon, 29 Jun 2015 20:43:37 +0200

> mode. This scenario widely used in enterprise environments.

Yeah, it's a valid use case. Thanks for explaining it. I want to add that this
is the reason for this "Use whole display" property in the session settings.

> handling negative screen sizes in vcxsrv and now I have not sufficient

This patch will either have to be fixed, an alternative solution be found or it
will be removed from our VcXsrv builds and you will have to maintain it
separately for your customers.

I don't mean to be rude, but this patch causes *two* higher severity bugs
Windows users are often hit by:
  - disappearing, maximized window after session resume if the resolution
decreased to something less than window size
  - disappearing, maximized window after MAXIMIZING a window on a non-primary
display(!!!)

I regularly get reports of both things happening, even over IRC.

In both cases, users are left without window decorations and thus cannot resize,
move or otherwise manipulate windows. The only "solution" is to terminate the
session completely. This is very disrupting.

In contrast, the initial problem your patch tried to fix is merely an annoyance.
It may not look nice to have window decorations for a "full screen desktop
session" and it's annoying to have to resize the window back into shape after
maximizing it, but at least you don't lose the ability to manipulate windows.

Ideally, we have to make sure that all three scenarios work fine without any bugs.

Mike#2 presented a very promising approach as an alternative:

On 29.06.2015 03:16 PM, Michael DePaulo wrote:
> It sounds like the best approach to making a "full screen" secondary
> monitor work is to launch VcXsrv (or Cygwin XWin) with these
> arguments:
> -nodecoration -screen 0 @2
>
> For tertiary monitor, use @3 instead.
>
> This launches Cygwin XWin in root window mode (the default) rather
> than -multiwindow mode. -nodecoration hides the window decoration from
> the Windows OS.

The only thing that needs testing with that suggestion is to check whether
windows are automatically resized to the display's extents.

Also, we probably should not use this on the primary display. That's what
VcXsrv's fullscreen mode is for.

If the alternative suggested by Mike#2 does not work as intended, we'll have to
fix the patch.

I have one approach for doing that in mind:
  - add a new VcXsrv command line option
  - only enable this command line option if the user selected a full screen
    session on a non-primary display
  - restart VcXsrv if such a session is to be started
  - in your multiwindow patch: only execute the workaround if the new command
    line option has been used when starting VcXsrv

> omit any window that placed on the displays with positive coordinates.

This won't work, because users can put windows on a vscreen with negative
coordinates. If they do, they'll experience the same problems as before.

> reset it in the case if x2go session is not a multi window session.

Did you mean full screen desktop session? Because re-setting windows decorations
only makes sense if the x2go session IS a multi window session or a
non-fullscreen desktop session.

But even if you do that, won't VcXsrv delete the window decorations again as
soon as you re-add the window decorations from X2Go Client? At the very least it
will do that when the window is resized/maximized again.

Letting VcXsrv and X2Go Client fight over windows properties is not a good idea.
I can see it blowing up easily.

Mihai

---

From: Mihai Moldovan <[email-masked]>
Date: Mon, 20 Jul 2015 01:13:28 +0200

Some progress happened in private and I should have been updating this bug
report a while ago.

It seems we dropped #883 from the conversation list a while ago accidentally.

Alex has committed a few changes in
http://code.x2go.org/gitweb?p=x2goclient.git;a=commit;h=58c2db08167d490797f3160d12274761f23bfaa8
that were subsequently fixed up by
http://code.x2go.org/gitweb?p=x2goclient.git;a=commit;h=d220069e8f721b2d462145cbb9cf6fe1c9ec4a47
and
http://code.x2go.org/gitweb?p=x2goclient.git;a=commit;h=465b0309db391a0ae4dd2b87201da1fdca458712

These basically start VcXsrv with -nodecoration instead of -multiwindow when a
"fake" fullscreen session on one display is requested (i.e., when the window is
not rootless and "use whole display" was set in session settings.)

Mike#2 has tested the changes and came up with these results:
http://imgur.com/tmYhffj,L7778NZ,kdege2q,slDcGSa#0

Screenshots 3 and 4 only relate to Cygwin's XWin server.

Testing looked good, but another issue resurfaced:

> I did discover another issue/limitation though. It happens when we
> start a "Use Whole Display" session and the X.org server settings are
> set to "use custom X-Server" but with "start X-Server on X2Go Client
> start" disabled. The X server specified in that GUI is launched, but
> with the options determined by X2Go Client rather than the options
> specified by the user in the GUI. In fact, we need to add a widget and
> setting for "Use whole display":
> http://imgur.com/KpYE64y

Thus, there's one more change required within the client's global settings
regarding the usage of an external X server.

At the same time, I'd suggest removing the "start X-Server on X2Go Client start"
option completely, because the different session types require differently
started X server instances.

Mihai