X2Go Bug report logs - #883
Window Decorations gone when resuming on smaller screen

Full log

🔗 View this message in rfc822 format

X-Loop: owner@bugs.x2go.org
Subject: Bug#883: [X2Go-Dev] Can be fixed by reverting winmultiwindow.patch
Reply-To: Mihai Moldovan <ionic@ionic.de>, 883@bugs.x2go.org
Resent-From: Mihai Moldovan <ionic@ionic.de>
Resent-To: x2go-dev@lists.x2go.org
Resent-CC: X2Go Developers <x2go-dev@lists.x2go.org>
X-Loop: owner@bugs.x2go.org
Resent-Date: Mon, 29 Jun 2015 18:45:02 +0000
Resent-Message-ID: <handler.883.B883.143560342519364@bugs.x2go.org>
Resent-Sender: owner@bugs.x2go.org
X-X2Go-PR-Message: followup 883
X-X2Go-PR-Package: x2goclient
X-X2Go-PR-Keywords: 
Received: via spool by 883-submit@bugs.x2go.org id=B883.143560342519364
          (code B ref 883); Mon, 29 Jun 2015 18:45:02 +0000
Received: (at 883) by bugs.x2go.org; 29 Jun 2015 18:43:45 +0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
	ymir.das-netzwerkteam.de
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID,
	URIBL_BLOCKED autolearn=ham version=3.3.2
Received: from Root24.de (powered.by.root24.eu [5.135.3.88])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTP id B257C5DA85
	for <883@bugs.x2go.org>; Mon, 29 Jun 2015 20:43:43 +0200 (CEST)
Received: from nopileos.local (home.ionic.de [217.92.117.31])
	by mail.ionic.de (Postfix) with ESMTPSA id 0A0364F0500C;
	Mon, 29 Jun 2015 20:43:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ionic.de; s=default;
	t=1435603423; bh=FPovtbmgcdweIikXTyXO1b7Uf9kzbeZthf2QNfvc9QU=;
	h=Subject:To:References:From:Date:In-Reply-To:From;
	b=SM6AjZWxc+CG9zZwswh64TgNkxfsIPSP/YfAkD6/jDGE6jmINAUAFRhAur6eKKzCf
	 LuaY5p6YcN3cUU6q7mtPmJzGYDgw/GXaDsMiBf3WLgwEK9qBJcpxiyihp+n7sSiztt
	 6UsKDmm1XU9ENr9/RNvvJuWRqIcfg46ofDaolu8o=
To: Oleksandr Shneyder <o.shneyder@phoca-gmbh.de>, 883@bugs.x2go.org,
 Michael DePaulo <mikedep333@gmail.com>
References: <20150623105115.Horde.cJ1xTsfQZTDIgaforyinLQ1@mail.das-netzwerkteam.de>
 <5589B201.2070208@phoca-gmbh.de> <558A103B.1030709@ionic.de>
 <55911193.1090006@phoca-gmbh.de>
From: Mihai Moldovan <ionic@ionic.de>
X-Enigmail-Draft-Status: N1110
Message-ID: <559191D9.2020007@ionic.de>
Date: Mon, 29 Jun 2015 20:43:37 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <55911193.1090006@phoca-gmbh.de>
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="1GjqRM1TGpm6cBK49Wwe1SHHCTKNjOj4L"

[Message part 1 (text/plain, inline)]

On 29.06.2015 11:36 AM, Oleksandr Shneyder wrote:
> 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.

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.


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

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


> I suggest to check in workaround if screen has negative coordinates and
> 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.


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

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

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.