From ionic@ionic.de Mon Jun 29 20:43:43 2015 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= Subject: Re: [X2Go-Dev] Can be fixed by reverting winmultiwindow.patch To: Oleksandr Shneyder , 883@bugs.x2go.org, Michael DePaulo 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 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" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1GjqRM1TGpm6cBK49Wwe1SHHCTKNjOj4L Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 usefu= l > 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 settin= gs. > 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-pri= mary 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 ann= oyance. It may not look nice to have window decorations for a "full screen deskto= p session" and it's annoying to have to resize the window back into shape a= fter maximizing it, but at least you don't lose the ability to manipulate wind= ows. 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 whethe= r 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 h= ave 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 scre= en 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 com= mand 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 deco= rations 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 l= east it will do that when the window is resized/maximized again. Letting VcXsrv and X2Go Client fight over windows properties is not a goo= d idea. I can see it blowing up easily. Mihai --1GjqRM1TGpm6cBK49Wwe1SHHCTKNjOj4L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVkZHZAAoJEB/WLtluJTqH9aYQANoDjXveqqiw7rUOnJvOkpdF puROz0HVAN1iqPE8fD8I8v6h02lRoc5JA29uUbIT3TFiZ5yH/Me0Lsab2nywQx4N M2c14RMf5OviC0b8wlCLYq72aP7YaYTwifQMKNXsj4Jp/eewa+bRpaVYTcXoKurr aU3TJL2ay7tuhgapYBPoO67SreWCEKG5WLDpqqd6ZVaLbnI9bBYjq9eM5SqRPuah 0cJaHcINKZFpRX/StiSXaLhrzSHo8VO31y4bxbKF9wqhCbpoR9SK2rzfxRHwfhWg b3qQi70KvJwucBltxsNF5rvq6fEd9AV2CxPqQ8ZqVR5t5GOWHOzMC7GmxWltcbgc WTSBSFiYqclOGF7TkRrc4AKMtpsTH5/B09esqwBQpzK5L4xjVpk4DFRh4yDNciqQ Q0LCz7dmMptmg/ITn/Dxf9c4trzkTSGdqjvxY99xswO/MKvT3f/eU3U/lD9eN+vO 1I8ad6MllXFBZ9daq+gMGoRvHLdRU5f2lOaNxq5gmviwvSFtubmP1x7cEctdCXXf mjFaiPhUQ69vXyDXjdFDsX7O8KbCsNY1Lc1hGQON4VGaqmwwfNDzeIhGAaeA0BAf U3vMuJ6Psy7M9siDLUFdGBqwdDMycgYO+nsn3f4E8hlCH30Gic5gg8s8e/MlbB24 gkAc7fH9nVcRQcdnAfsV =+tBo -----END PGP SIGNATURE----- --1GjqRM1TGpm6cBK49Wwe1SHHCTKNjOj4L--