On Thu, May 17, 2018 at 2:13 PM, Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
Nope, it looks for me, that nxproxy window get information about screens from WM. If WM is not started, nxproxy get just the window geometry. With started WM we have correct display information on server side. Xinerama starts to work with WM even if X2Go Session already running. I made some experiments like:
- Starting tce without WM.
- Connect to TC with ssh.
- Open X2Go Session. At this moment Xinerama in X2Go session not working. I have one big screen over two monitors.
What exactly do you mean by "open x2go session"?
- Starting WM on the TC. At this moment Xinerama starts to work in the running X2Go session immediately.
It worked in TCE for me in 100% of cases. Independent when I'm starting WM - before X2Go Client, after X2Go Client or even when X2Go Session already running. I'll implement this solution in classic TCE and will let my customers test it.
I'd prefer understanding what's going on first. nxagent is running
if (nxagentGrabServerInfo.grabstate == SERVER_GRABBED && nxagentGrabServerInfo.client != NULL) { /* * If any client grabbed the server it won't expect screen * configuration changes until it releases the grab. That could * lead to an X error because available modes are changed * in the meantime. */
#ifdef TEST
fprintf(stderr, "nxagentChangeScreenConfig: Cancel with grabbedserver (grab held by [%p]).\n", (void *) nxagentGrabServerInfo.client); #endif
return 0;}
pScreen = screenInfo.screens[screen] -> root -> drawable.pScreen;
#ifdef TEST fprintf(stderr, "nxagentChangeScreenConfig: Changing config to %d x %d (%dmm x %dmm).\n", width, height, mmWidth, mmHeight); #endif
r = nxagentResizeScreen(pScreen, width, height, mmWidth, mmHeight);
if (r != 0) { if (nxagentOption(Xinerama) && (noRRXineramaExtension == FALSE)) { nxagentAdjustRandRXinerama(pScreen); } else { #ifdef DEBUG fprintf(stderr, "%s: Xinerama is disabled\n", __func__); #endif
nxagentAdjustCustomMode(pScreen);
}}
And XineramaQueryScreens ins finally called in nxagentAdjustRandRXinerama. BUT: If nxagentAdjustRandRXinerama FAILS to get that data it will NOT fall back to the version you see but to reporting ONE screen (called NX1, IIRC). So all this fails somewhere else.
Can you run an nxagent that has #define TEST and #define DEBUG enabledin in Screen.c?
Uli
Am 17.05.2018 um 14:33 schrieb Ulrich Sibiller:
On Thu, May 17, 2018 at 2:13 PM, Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
Nope, it looks for me, that nxproxy window get information about screens from WM. If WM is not started, nxproxy get just the window geometry. With started WM we have correct display information on server side. Xinerama starts to work with WM even if X2Go Session already running. I made some experiments like:
- Starting tce without WM.
- Connect to TC with ssh.
- Open X2Go Session. At this moment Xinerama in X2Go session not working. I have one big screen over two monitors.
What exactly do you mean by "open x2go session"?
I mean start X2Go session from TC
- Starting WM on the TC. At this moment Xinerama starts to work in the running X2Go session immediately.
It worked in TCE for me in 100% of cases. Independent when I'm starting WM - before X2Go Client, after X2Go Client or even when X2Go Session already running. I'll implement this solution in classic TCE and will let my customers test it.
I'd prefer understanding what's going on first. nxagent is running
You can easily reproduce this issue by running x2goclient without WM. It's not really important for me now, why it's not working without WM. I think NX using some WM-Based function to determine screen configuration on the client side. I don't have resources to investigate this issue right now and it's not critical for me.
if (nxagentGrabServerInfo.grabstate == SERVER_GRABBED && nxagentGrabServerInfo.client != NULL) .................... And XineramaQueryScreens ins finally called in nxagentAdjustRandRXinerama. BUT: If nxagentAdjustRandRXinerama FAILS to get that data it will NOT fall back to the version you see but to reporting ONE screen (called NX1, IIRC). So all this fails somewhere else.
No, if I'm starting the session from TC without WM, I don't have screen with name NX1. xrandr output looks in this case like this:
Screen 0: minimum 320 x 240, current 2560 x 1024, maximum 2560 x 1200 default connected 2560x1024+0+0 0mm x 0mm 1360x768 60.00 320x240 60.00 1024x600 60.00 1280x800 60.00 1600x900 60.00 1600x1200 60.00
Only if I starting session from TC with running WM, I have screens with names NX1, NX2, etc.
Can you run an nxagent that has #define TEST and #define DEBUG enabledin in Screen.c?
Uli
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Harzstr. 4 | Fax. : 0911 - 14870374 9 D-90491 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
On Thu, May 17, 2018 at 2:45 PM, Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
Am 17.05.2018 um 14:33 schrieb Ulrich Sibiller:
On Thu, May 17, 2018 at 2:13 PM, Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
Nope, it looks for me, that nxproxy window get information about screens from WM. If WM is not started, nxproxy get just the window geometry. With started WM we have correct display information on server side. Xinerama starts to work with WM even if X2Go Session already running. I made some experiments like:
- Starting tce without WM.
- Connect to TC with ssh.
- Open X2Go Session. At this moment Xinerama in X2Go session not working. I have one big screen over two monitors.
What exactly do you mean by "open x2go session"?
I mean start X2Go session from TC
- Starting WM on the TC. At this moment Xinerama starts to work in the running X2Go session immediately.
It worked in TCE for me in 100% of cases. Independent when I'm starting WM - before X2Go Client, after X2Go Client or even when X2Go Session already running. I'll implement this solution in classic TCE and will let my customers test it.
I'd prefer understanding what's going on first. nxagent is running
You can easily reproduce this issue by running x2goclient without WM. It's not really important for me now, why it's not working without WM. I think NX using some WM-Based function to determine screen configuration on the client side. I don't have resources to investigate this issue right now and it's not critical for me.
if (nxagentGrabServerInfo.grabstate == SERVER_GRABBED && nxagentGrabServerInfo.client != NULL) .................... And XineramaQueryScreens ins finally called in nxagentAdjustRandRXinerama. BUT: If nxagentAdjustRandRXinerama FAILS to get that data it will NOT fall back to the version you see but to reporting ONE screen (called NX1, IIRC). So all this fails somewhere else.
No, if I'm starting the session from TC without WM, I don't have screen with name NX1. xrandr output looks in this case like this:
Screen 0: minimum 320 x 240, current 2560 x 1024, maximum 2560 x 1200 default connected 2560x1024+0+0 0mm x 0mm 1360x768 60.00 320x240 60.00 1024x600 60.00 1280x800 60.00 1600x900 60.00 1600x1200 60.00
Only if I starting session from TC with running WM, I have screens with names NX1, NX2, etc.
That's what I am saying. It is NOT the xinerama code going nuts, the difference is happening somewhere else in nxagent. I will try to determine the cause tonight.
Uli
Anyway, having to install a WM in a TCE is not dumb stuff, it makes TCE acts much more like a real desktop than without it (and thus, easier to debug and a more uniform setup than with local fat client). The real problem was this was not part of the x2gothinclient-displaymanager install and so, you had to patch the installation by hand which is always risky.
Regards, Walid Moghrabi
TRAVAUX.COM BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403 13591 AIX EN PROVENCE CEDEX 3
----- Mail original -----
De: "Ulrich Sibiller" <uli42@gmx.de> À: "Oleksandr Shneyder" <o.shneyder@phoca-gmbh.de> Cc: x2go-dev@lists.x2go.org Envoyé: Jeudi 17 Mai 2018 14:56:17 Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE
On Thu, May 17, 2018 at 2:45 PM, Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
Am 17.05.2018 um 14:33 schrieb Ulrich Sibiller:
On Thu, May 17, 2018 at 2:13 PM, Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
Nope, it looks for me, that nxproxy window get information about screens from WM. If WM is not started, nxproxy get just the window geometry. With started WM we have correct display information on server side. Xinerama starts to work with WM even if X2Go Session already running. I made some experiments like:
- Starting tce without WM.
- Connect to TC with ssh.
- Open X2Go Session. At this moment Xinerama in X2Go session not working. I have one big screen over two monitors.
What exactly do you mean by "open x2go session"?
I mean start X2Go session from TC
- Starting WM on the TC. At this moment Xinerama starts to work in the running X2Go session immediately.
It worked in TCE for me in 100% of cases. Independent when I'm starting WM - before X2Go Client, after X2Go Client or even when X2Go Session already running. I'll implement this solution in classic TCE and will let my customers test it.
I'd prefer understanding what's going on first. nxagent is running
You can easily reproduce this issue by running x2goclient without WM. It's not really important for me now, why it's not working without WM. I think NX using some WM-Based function to determine screen configuration on the client side. I don't have resources to investigate this issue right now and it's not critical for me.
if (nxagentGrabServerInfo.grabstate == SERVER_GRABBED && nxagentGrabServerInfo.client != NULL) .................... And XineramaQueryScreens ins finally called in nxagentAdjustRandRXinerama. BUT: If nxagentAdjustRandRXinerama FAILS to get that data it will NOT fall back to the version you see but to reporting ONE screen (called NX1, IIRC). So all this fails somewhere else.
No, if I'm starting the session from TC without WM, I don't have screen with name NX1. xrandr output looks in this case like this:
Screen 0: minimum 320 x 240, current 2560 x 1024, maximum 2560 x 1200 default connected 2560x1024+0+0 0mm x 0mm 1360x768 60.00 320x240 60.00 1024x600 60.00 1280x800 60.00 1600x900 60.00 1600x1200 60.00
Only if I starting session from TC with running WM, I have screens with names NX1, NX2, etc.
That's what I am saying. It is NOT the xinerama code going nuts, the difference is happening somewhere else in nxagent. I will try to determine the cause tonight.
Uli
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
DISCLAIMER: This e-mail is private and confidential and may contain proprietary or legally privileged information. It is for the intended recipient only. If you have received this email in error, please notify the author by replying to it and then destroy it. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail or any attachment. Thank you
Am 17.05.2018 um 15:32 schrieb Walid MOGHRABI:
Anyway, having to install a WM in a TCE is not dumb stuff, it makes TCE acts much more like a real desktop than without it (and thus, easier to debug and a more uniform setup than with local fat client).
And that's why we added OpenBox to TCE-live in the first place. (TL;DR: +1)
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
On Thu, May 17, 2018 at 3:40 PM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
Am 17.05.2018 um 15:32 schrieb Walid MOGHRABI:
Anyway, having to install a WM in a TCE is not dumb stuff, it makes TCE acts much more like a real desktop than without it (and thus, easier to debug and a more uniform setup than with local fat client).
And that's why we added OpenBox to TCE-live in the first place. (TL;DR: +1)
Nevertheless I have opened an issue on nx-libs (https://github.com/ArcticaProject/nx-libs/pull/694) and I have a possible solution (https://github.com/ArcticaProject/nx-libs/pull/695).
Also I suppose we should automatically disable the magic pixel when there's no window manager running. What do you think?
Uli
Am 17.05.2018 um 23:21 schrieb Ulrich Sibiller:
Also I suppose we should automatically disable the magic pixel when there's no window manager running. What do you think?
I'd say your thinking is a bit too Linux-centric here. Or would your code also detect a running MS Windows / macOS underneath X2GoClient as "has WM"? Because the magic pixel is useful on those platforms, too - especially Windows, where pressing Ctrl+Alt+F regularly crashes the X server, instead of toggling fullscreen mode.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
On Thu, May 17, 2018 at 11:35 PM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
Am 17.05.2018 um 23:21 schrieb Ulrich Sibiller:
Also I suppose we should automatically disable the magic pixel when there's no window manager running. What do you think?
I'd say your thinking is a bit too Linux-centric here. Or would your code also detect a running MS Windows / macOS underneath X2GoClient as "has WM"?
Unfortunately I do not remember, although I have beee examining that recently (while debugging the flickering issue on Windows). No, wait, I remember: vcxsrv brings its own window manager for the multiwindow mode and then nx is reporting "has WM". No idea about MacOs, though.
Because the magic pixel is useful on those platforms, too - especially Windows, where pressing Ctrl+Alt+F regularly crashes the X server, instead of toggling fullscreen mode.
We could file vcxsrv bug for that. We "just" need to track it down and build some small example code. ;-)
Uli
Am 17.05.2018 um 23:46 schrieb Ulrich Sibiller:
Because the magic pixel is useful on those platforms, too - especially Windows, where pressing Ctrl+Alt+F regularly crashes the X server, instead of toggling fullscreen mode. We could file vcxsrv bug for that. We "just" need to track it down and build some small example code. ;-)
Given how long that bug has bothered us, I don't expect it to get fixed any time soon ...
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Am 17.05.2018 um 23:46 schrieb Ulrich Sibiller:
Also I suppose we should automatically disable the magic pixel when there's no window manager running. What do you think? I'd say your thinking is a bit too Linux-centric here. Or would your code also detect a running MS Windows / macOS underneath X2GoClient as "has WM"? Unfortunately I do not remember, although I have beee examining that recently (while debugging the flickering issue on Windows). No, wait, I remember: vcxsrv brings its own window manager for the multiwindow mode and then nx is reporting "has WM". No idea about MacOs, though.
*pinging Mihai and Mike#2 here, because of the macOS question ...*
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Am 17.05.2018 um 23:21 schrieb Ulrich Sibiller:
Also I suppose we should automatically disable the magic pixel when there's no window manager running. What do you think?
Wait, no. Let's not get confused here. Magic Pixel *is* effectively disabled when there is no Window Manager running, because the command "minimize" is sent to a WM. If there is none, nothing happens. That is fine how it is. No further action needed.
The problem arises on systems that have a Window Manager (like OpenBox), but no task bar, so no way to un-minimize the X2Go/NX-window once the user hits the magic pixel. And we need a way to disable the magic pixel there, because we need OpenBox for several reasons and can't just ditch it to fool NX. So instead of detecting the presence of a Window Manager, we'd need to detect the presence of a task bar. Which, I'd guess, isn't as easy.
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
On Fri, May 18, 2018 at 1:18 AM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
[...] The problem arises on systems that have a Window Manager (like OpenBox), but no task bar, so no way to un-minimize the X2Go/NX-window once the user hits the magic pixel.
Are you sure that task bar is required? AFAIK any tool with window switching ability (e.g. bbkeys, xdotool, some custom quick-and-dirty libwnck script) would work, wouldn't it?
Am 18.05.2018 um 00:39 schrieb Nable:
On Fri, May 18, 2018 at 1:18 AM, Stefan Baur <X2Go-ML-1@baur-itcs.de <mailto:X2Go-ML-1@baur-itcs.de>> wrote:
[...] The problem arises on systems that have a Window Manager (like OpenBox), but no task bar, so no way to un-minimize the X2Go/NX-window once the user hits the magic pixel.
Are you sure that task bar is required? AFAIK any tool with window switching ability (e.g. bbkeys, xdotool, some custom quick-and-dirty libwnck script) would work, wouldn't it?
Well, we are using xdotool in one of our workarounds. But, in a ThinClient environment, such a workaround must either function automatically (detect minimize and un-minimize instantly), or give the user some visual indication that X2GoClient hasn't crashed, but just needs to be un-minimized. The way to do this, because even an only marginally trained user would still understand this, is showing a task bar with an X2Go icon. Otherwise, all the user sees is a completely blue screen once they hit the magic pixel. An advanced user might try key combinations like Alt+Tab, but I wouldn't be sure that they help restoring the window to fullscreen.
Oh, and as stated above, we tried xdotool for a workaround, but sadly, it's not as simple as it seems and can trigger some nasty side-effects. That's why we went for the other workaround - disabling OpenBox as soon as the NX window spawns, then restarting it afterwards, once it has been closed.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
I definitely don't agree ... you're too developer centric ... This MagicPixel thing *IN TCE MODE* is troubling for users and your workaround is NOT a good option because the desktop is minimized then, thanks to a little daemon running, maximized again which is extremely confusing and frustrating for users. In TCE mode, there is no need for such thing and there MUST be a way to disabling it completely. This is what has been done by a server side switch which is fine for most *TCE* cases, now, I can understand that it can be desirable to keep that stuff for some other use cases but then, don't do tricks like that, just keep it and inform your users OR add the ability to disable this behaviour client side if disabling it server side really bothers you.
Regards, Walid Moghrabi
TRAVAUX.COM BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403 13591 AIX EN PROVENCE CEDEX 3
----- Mail original -----
De: "Stefan Baur" <X2Go-ML-1@baur-itcs.de> À: x2go-dev@lists.x2go.org Envoyé: Vendredi 18 Mai 2018 00:49:29 Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE
Am 18.05.2018 um 00:39 schrieb Nable:
On Fri, May 18, 2018 at 1:18 AM, Stefan Baur <X2Go-ML-1@baur-itcs.de <mailto:X2Go-ML-1@baur-itcs.de>> wrote:
[...] The problem arises on systems that have a Window Manager (like OpenBox), but no task bar, so no way to un-minimize the X2Go/NX-window once the user hits the magic pixel.
Are you sure that task bar is required? AFAIK any tool with window switching ability (e.g. bbkeys, xdotool, some custom quick-and-dirty libwnck script) would work, wouldn't it?
Well, we are using xdotool in one of our workarounds. But, in a ThinClient environment, such a workaround must either function automatically (detect minimize and un-minimize instantly), or give the user some visual indication that X2GoClient hasn't crashed, but just needs to be un-minimized. The way to do this, because even an only marginally trained user would still understand this, is showing a task bar with an X2Go icon. Otherwise, all the user sees is a completely blue screen once they hit the magic pixel. An advanced user might try key combinations like Alt+Tab, but I wouldn't be sure that they help restoring the window to fullscreen.
Oh, and as stated above, we tried xdotool for a workaround, but sadly, it's not as simple as it seems and can trigger some nasty side-effects. That's why we went for the other workaround - disabling OpenBox as soon as the NX window spawns, then restarting it afterwards, once it has been closed.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
DISCLAIMER: This e-mail is private and confidential and may contain proprietary or legally privileged information. It is for the intended recipient only. If you have received this email in error, please notify the author by replying to it and then destroy it. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail or any attachment. Thank you
Walid,
the proper way to handle this is to set the "MP disable" command *in X2GoClient*, but *only when* X2GoClient is called with *--thinclient*, because that is the option used to tell X2GoClient it is in TCE mode.
And the workaround with the un-minimizing daemon you are talking about is the deprecated one anyways. The better workaround, and the one we are deploying until this gets fixed in X2GoClient, is the one where OpenBox is getting killed once the NX window comes up, and restarted when it vanishes. That way, MP is DEAD even in TCE. No "zap and unminimize", it just doesn't have anything to send the minimize command to. The only thing I'm considering changing is the time until OpenBox gets killed when the NX window is detected - if the patch to X2GoClient takes longer, adding a longer delay here might help getting Xinerama to work properly.
Kind Regards, Stefan Baur
Am 18.05.2018 um 09:36 schrieb Walid MOGHRABI:
I definitely don't agree ... you're too developer centric ... This MagicPixel thing *IN TCE MODE* is troubling for users and your workaround is NOT a good option because the desktop is minimized then, thanks to a little daemon running, maximized again which is extremely confusing and frustrating for users. In TCE mode, there is no need for such thing and there MUST be a way to disabling it completely. This is what has been done by a server side switch which is fine for most *TCE* cases, now, I can understand that it can be desirable to keep that stuff for some other use cases but then, don't do tricks like that, just keep it and inform your users OR add the ability to disable this behaviour client side if disabling it server side really bothers you.
Regards, Walid Moghrabi
TRAVAUX.COM BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403 13591 AIX EN PROVENCE CEDEX 3
----- Mail original -----
De: "Stefan Baur" <X2Go-ML-1@baur-itcs.de> À: x2go-dev@lists.x2go.org Envoyé: Vendredi 18 Mai 2018 00:49:29 Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE
Am 18.05.2018 um 00:39 schrieb Nable:
On Fri, May 18, 2018 at 1:18 AM, Stefan Baur <X2Go-ML-1@baur-itcs.de <mailto:X2Go-ML-1@baur-itcs.de>> wrote:
[...] The problem arises on systems that have a Window Manager (like OpenBox), but no task bar, so no way to un-minimize the X2Go/NX-window once the user hits the magic pixel.
Are you sure that task bar is required? AFAIK any tool with window switching ability (e.g. bbkeys, xdotool, some custom quick-and-dirty libwnck script) would work, wouldn't it?
Well, we are using xdotool in one of our workarounds. But, in a ThinClient environment, such a workaround must either function automatically (detect minimize and un-minimize instantly), or give the user some visual indication that X2GoClient hasn't crashed, but just needs to be un-minimized. The way to do this, because even an only marginally trained user would still understand this, is showing a task bar with an X2Go icon. Otherwise, all the user sees is a completely blue screen once they hit the magic pixel. An advanced user might try key combinations like Alt+Tab, but I wouldn't be sure that they help restoring the window to fullscreen.
Oh, and as stated above, we tried xdotool for a workaround, but sadly, it's not as simple as it seems and can trigger some nasty side-effects. That's why we went for the other workaround - disabling OpenBox as soon as the NX window spawns, then restarting it afterwards, once it has been closed.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
On Fri, May 18, 2018 at 9:47 AM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
Walid,
the proper way to handle this is to set the "MP disable" command *in X2GoClient*, but *only when* X2GoClient is called with *--thinclient*, because that is the option used to tell X2GoClient it is in TCE mode.
And the workaround with the un-minimizing daemon you are talking about is the deprecated one anyways.
I am getting more an more confused about the TCE stuff. Is there a difference between TCE you are talking about and the x2gothinclient Alex is working on?
Uli
Am 18.05.2018 um 09:57 schrieb Ulrich Sibiller:
I am getting more an more confused about the TCE stuff. Is there a difference between TCE you are talking about and the x2gothinclient Alex is working on?
Alex is working on the classic, NFS-based TCE, that so far does not come with a Window Manager.
Juri and I are maintaining the Debian-Live based TCE, where OpenBox is included, because we were annoyed by X2GoClient's popups being inaccessible.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
On Fri, May 18, 2018 at 10:03 AM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
Am 18.05.2018 um 09:57 schrieb Ulrich Sibiller:
I am getting more an more confused about the TCE stuff. Is there a difference between TCE you are talking about and the x2gothinclient Alex is working on?
Alex is working on the classic, NFS-based TCE, that so far does not come with a Window Manager.
Juri and I are maintaining the Debian-Live based TCE, where OpenBox is included, because we were annoyed by X2GoClient's popups being inaccessible.
Got it, thanks! Are there plans of mergeing the two? Or for dropping one of them?
Uli
Am 18.05.2018 um 10:08 schrieb Ulrich Sibiller:
Alex is working on the classic, NFS-based TCE, that so far does not come with a Window Manager.
Juri and I are maintaining the Debian-Live based TCE, where OpenBox is included, because we were annoyed by X2GoClient's popups being inaccessible. Got it, thanks! Are there plans of mergeing the two? Or for dropping one of them?
Alex has a customer (I think) that wants to see TCE-NFS being kept alive
- so while someone is actively maintaining it, we can keep it.
IMO, the Debian-Live based TCE is the way to go, though, as it only requires a few startup scripts to be maintained as patches, and a build script. The NFS-based solution seems to require a lot more manual work and constant changes to keep it running and supported on newer Debian releases, at least that's my opinion and why I started building TCE-Live.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
NFS-based TCE has a lot of advantages and will be kept anyway.
regards Alex
Am 18.05.2018 um 10:14 schrieb Stefan Baur:
Am 18.05.2018 um 10:08 schrieb Ulrich Sibiller:
Alex is working on the classic, NFS-based TCE, that so far does not come with a Window Manager.
Juri and I are maintaining the Debian-Live based TCE, where OpenBox is included, because we were annoyed by X2GoClient's popups being inaccessible. Got it, thanks! Are there plans of mergeing the two? Or for dropping one of them?
Alex has a customer (I think) that wants to see TCE-NFS being kept alive
- so while someone is actively maintaining it, we can keep it.
IMO, the Debian-Live based TCE is the way to go, though, as it only requires a few startup scripts to be maintained as patches, and a build script. The NFS-based solution seems to require a lot more manual work and constant changes to keep it running and supported on newer Debian releases, at least that's my opinion and why I started building TCE-Live.
Kind Regards, Stefan Baur
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Harzstr. 4 | Fax. : 0911 - 14870374 9 D-90491 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
Am 18.05.2018 um 10:32 schrieb Oleksandr Shneyder:
NFS-based TCE has a lot of advantages and will be kept anyway. ... as long as someone is actively maintaining it. If you have customers paying for it, or you volunteer to maintain it, fine.
But I'm not happy with keeping a TCE-NFS in git that works on, say, Debian 9 only, when Debian 10 or 11 becomes/is the stable release.
I'm curious to learn about the "lot of advantages" of TCE-NFS. Go ahead and list them, please, so we can put them in the Wiki and create a side-by-side comparison between TCE-NFS and TCE-Live as a guide for potential users, so they know which version is right for them.
My personal experience with TCE-NFS was horrifying, that's why I started TCE-Live. But maybe it is just a serious lack of documentation of TCE-NFS that made Debian-Live feel way easier to me ...
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Don't see much advantages either except the fact that it lets you easily change some settings live without a reboot needed to start a new image.
But to be honest, as far as I'm concerned, I see more drawbacks in TCE-NFS than in TCE-Live.
Regards, Walid Moghrabi
TRAVAUX.COM BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403 13591 AIX EN PROVENCE CEDEX 3
----- Mail original -----
De: "Stefan Baur" <X2Go-ML-1@baur-itcs.de> À: x2go-dev@lists.x2go.org Envoyé: Vendredi 18 Mai 2018 10:43:16 Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE
Am 18.05.2018 um 10:32 schrieb Oleksandr Shneyder:
NFS-based TCE has a lot of advantages and will be kept anyway. ... as long as someone is actively maintaining it. If you have customers paying for it, or you volunteer to maintain it, fine.
But I'm not happy with keeping a TCE-NFS in git that works on, say, Debian 9 only, when Debian 10 or 11 becomes/is the stable release.
I'm curious to learn about the "lot of advantages" of TCE-NFS. Go ahead and list them, please, so we can put them in the Wiki and create a side-by-side comparison between TCE-NFS and TCE-Live as a guide for potential users, so they know which version is right for them.
My personal experience with TCE-NFS was horrifying, that's why I started TCE-Live. But maybe it is just a serious lack of documentation of TCE-NFS that made Debian-Live feel way easier to me ...
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
DISCLAIMER: This e-mail is private and confidential and may contain proprietary or legally privileged information. It is for the intended recipient only. If you have received this email in error, please notify the author by replying to it and then destroy it. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail or any attachment. Thank you
I don't know why you should have troubles with it. The installation procedure is described in the Wiki step by step. You can use TCE with very simple hardware which is not powerful enough to run TCE-Live. And you can make changes in NFS-Root even without restarting thin clients. I don't want to start battle "NFS vs Live" here. Everyone should decide it for himself. For me TCE-Live is not a substitution for NFS-TCE. And it's basically not a Thin Client System by definition. It's more a live image system, IMHO.
regards Alex
Am 18.05.2018 um 10:43 schrieb Stefan Baur:
Am 18.05.2018 um 10:32 schrieb Oleksandr Shneyder:
NFS-based TCE has a lot of advantages and will be kept anyway. ... as long as someone is actively maintaining it. If you have customers paying for it, or you volunteer to maintain it, fine.
But I'm not happy with keeping a TCE-NFS in git that works on, say, Debian 9 only, when Debian 10 or 11 becomes/is the stable release.
I'm curious to learn about the "lot of advantages" of TCE-NFS. Go ahead and list them, please, so we can put them in the Wiki and create a side-by-side comparison between TCE-NFS and TCE-Live as a guide for potential users, so they know which version is right for them.
My personal experience with TCE-NFS was horrifying, that's why I started TCE-Live. But maybe it is just a serious lack of documentation of TCE-NFS that made Debian-Live feel way easier to me ...
Kind Regards, Stefan Baur
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Harzstr. 4 | Fax. : 0911 - 14870374 9 D-90491 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
Hi Alex,
I don't want to start a battle either, but I think a side-by-side comparison would be nice so users know what to expect and thus what they should pick for their intended use.
Back when I tried to follow the installation instructions, they were for Wheezy only. Attempting to run the same installation steps for Jessie failed (Stretch wasn't released back then), and there were no obvious error messages pointing me toward what I should fix/change. Which, to me, is an indication that TCE-NFS has lots of "hackish" parts that need to be altered with every new major Debian release to make them work again.
I would also like to know what your minimum hardware requirements for TCE-NFS are. Even though TCE-Live has the option to run from a RAM disk, it is by no means mandatory. I just booted an i386 stretch build of TCE-Live (without the "toram" parameter) from USB and it shows approximately 69 MB of RAM used in idle, and 76 MB RAM used with a fullscreen session and pulseaudio running. I have to admit that this doesn't seem to be the whole truth, though - actually reducing the RAM on the machine to 128MB caused a kernel crash right while booting. With 256MB of RAM, it boots up, and runs a session - though it's obviously slow because it can use almost no RAM as buffer/cache. But I doubt that would be different with TCE-NFS ...
Kind Regards, Stefan Baur
Am 18.05.2018 um 11:07 schrieb Oleksandr Shneyder:
I don't know why you should have troubles with it. The installation procedure is described in the Wiki step by step. You can use TCE with very simple hardware which is not powerful enough to run TCE-Live. And you can make changes in NFS-Root even without restarting thin clients. I don't want to start battle "NFS vs Live" here. Everyone should decide it for himself. For me TCE-Live is not a substitution for NFS-TCE. And it's basically not a Thin Client System by definition. It's more a live image system, IMHO.
regards Alex
Am 18.05.2018 um 10:43 schrieb Stefan Baur:
Am 18.05.2018 um 10:32 schrieb Oleksandr Shneyder:
NFS-based TCE has a lot of advantages and will be kept anyway. ... as long as someone is actively maintaining it. If you have customers paying for it, or you volunteer to maintain it, fine.
But I'm not happy with keeping a TCE-NFS in git that works on, say, Debian 9 only, when Debian 10 or 11 becomes/is the stable release.
I'm curious to learn about the "lot of advantages" of TCE-NFS. Go ahead and list them, please, so we can put them in the Wiki and create a side-by-side comparison between TCE-NFS and TCE-Live as a guide for potential users, so they know which version is right for them.
My personal experience with TCE-NFS was horrifying, that's why I started TCE-Live. But maybe it is just a serious lack of documentation of TCE-NFS that made Debian-Live feel way easier to me ...
Kind Regards, Stefan Baur
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Well, 256MB RAM it's what they used in city of Treuchtlingen. Loading images from local drive it's not an option, if you have about 200 clients which are located kilometers away from each other. NFS-TCE is nothing else than simple debootstrap loaded from NFS with some scripts to launch X2Go Client. Should be no problem to anyone who has a minimal knowledges about NFS-Root, DHCP and TFTP. It took me just a several minute to migrate it from Wheezy to Stretch. Didn't work out of the box because some files were moved in Debian from one package to another.
regards Alex
Am 18.05.2018 um 11:32 schrieb Stefan Baur:
Hi Alex,
I don't want to start a battle either, but I think a side-by-side comparison would be nice so users know what to expect and thus what they should pick for their intended use.
Back when I tried to follow the installation instructions, they were for Wheezy only. Attempting to run the same installation steps for Jessie failed (Stretch wasn't released back then), and there were no obvious error messages pointing me toward what I should fix/change. Which, to me, is an indication that TCE-NFS has lots of "hackish" parts that need to be altered with every new major Debian release to make them work again.
I would also like to know what your minimum hardware requirements for TCE-NFS are. Even though TCE-Live has the option to run from a RAM disk, it is by no means mandatory. I just booted an i386 stretch build of TCE-Live (without the "toram" parameter) from USB and it shows approximately 69 MB of RAM used in idle, and 76 MB RAM used with a fullscreen session and pulseaudio running. I have to admit that this doesn't seem to be the whole truth, though - actually reducing the RAM on the machine to 128MB caused a kernel crash right while booting. With 256MB of RAM, it boots up, and runs a session - though it's obviously slow because it can use almost no RAM as buffer/cache. But I doubt that would be different with TCE-NFS ...
Kind Regards, Stefan Baur
Am 18.05.2018 um 11:07 schrieb Oleksandr Shneyder:
I don't know why you should have troubles with it. The installation procedure is described in the Wiki step by step. You can use TCE with very simple hardware which is not powerful enough to run TCE-Live. And you can make changes in NFS-Root even without restarting thin clients. I don't want to start battle "NFS vs Live" here. Everyone should decide it for himself. For me TCE-Live is not a substitution for NFS-TCE. And it's basically not a Thin Client System by definition. It's more a live image system, IMHO.
regards Alex
Am 18.05.2018 um 10:43 schrieb Stefan Baur:
Am 18.05.2018 um 10:32 schrieb Oleksandr Shneyder:
NFS-based TCE has a lot of advantages and will be kept anyway. ... as long as someone is actively maintaining it. If you have customers paying for it, or you volunteer to maintain it, fine.
But I'm not happy with keeping a TCE-NFS in git that works on, say, Debian 9 only, when Debian 10 or 11 becomes/is the stable release.
I'm curious to learn about the "lot of advantages" of TCE-NFS. Go ahead and list them, please, so we can put them in the Wiki and create a side-by-side comparison between TCE-NFS and TCE-Live as a guide for potential users, so they know which version is right for them.
My personal experience with TCE-NFS was horrifying, that's why I started TCE-Live. But maybe it is just a serious lack of documentation of TCE-NFS that made Debian-Live feel way easier to me ...
Kind Regards, Stefan Baur
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Harzstr. 4 | Fax. : 0911 - 14870374 9 D-90491 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
Am 18.05.2018 um 12:09 schrieb Oleksandr Shneyder:
Well, 256MB RAM it's what they used in city of Treuchtlingen. Loading images from local drive it's not an option, if you have about 200 clients which are located kilometers away from each other.
It is an option, if local storage is present. We have a background updater exactly for that. Also, TCE-Live *should* work via netboot as well, even on 256MB RAM machines, though admittedly I haven't tested it myself. In those situations, you need to use httpfs instead of the "fetch" boot parameter, that way, even in netboot mode, the image isn't loaded into RAM (at least that's the theory behind it).
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Alex has a customer (I think) that wants to see TCE-NFS being kept alive
- so while someone is actively maintaining it, we can keep it.
If we're talking about the x2gothinclient-displaymanager package, this is not "NFS based or anything else" centric and it can be used for both modes. It just installs x2goclient and configures it to start at boot as a DM replacement. I do agree that Live Build with no dependency to any network FS is the way to go. For what I can tell, a "full TCE" mode (which means booting to x2goclient, not mini desktop mode which highly depends on what you install in your image) can easily fit in a client with 1Gb memory, maybe less and this is far more reliable and faster.
Regards, Walid Moghrabi
TRAVAUX.COM BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403 13591 AIX EN PROVENCE CEDEX 3
----- Mail original -----
De: "Stefan Baur" <X2Go-ML-1@baur-itcs.de> À: uli42@gmx.de Cc: x2go-dev@lists.x2go.org Envoyé: Vendredi 18 Mai 2018 10:14:58 Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE
Am 18.05.2018 um 10:08 schrieb Ulrich Sibiller:
Alex is working on the classic, NFS-based TCE, that so far does not come with a Window Manager.
Juri and I are maintaining the Debian-Live based TCE, where OpenBox is included, because we were annoyed by X2GoClient's popups being inaccessible. Got it, thanks! Are there plans of mergeing the two? Or for dropping one of them?
Alex has a customer (I think) that wants to see TCE-NFS being kept alive
- so while someone is actively maintaining it, we can keep it.
IMO, the Debian-Live based TCE is the way to go, though, as it only requires a few startup scripts to be maintained as patches, and a build script. The NFS-based solution seems to require a lot more manual work and constant changes to keep it running and supported on newer Debian releases, at least that's my opinion and why I started building TCE-Live.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
DISCLAIMER: This e-mail is private and confidential and may contain proprietary or legally privileged information. It is for the intended recipient only. If you have received this email in error, please notify the author by replying to it and then destroy it. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail or any attachment. Thank you
Am 18.05.2018 um 10:50 schrieb Walid MOGHRABI:
If we're talking about the x2gothinclient-displaymanager package, this is not "NFS based or anything else" centric and it can be used for both modes. It just installs x2goclient and configures it to start at boot as a DM replacement.
This does not seem to integrate well with TCE-Live, if you look at how things are being started there ... so I don't see how it would bring any advantage to TCE-Live. Care to explain how you would use it? (i.e. which parts of TCE-Live would you ditch/change and pull in x2gothinclient-displaymanager instead)?
In my opinion, at first glance, we'd lose quite some functionality by replacing our TCE-Live start script with x2gothinclient-displaymanager.
I do agree that Live Build with no dependency to any network FS is the way to go. For what I can tell, a "full TCE" mode (which means booting to x2goclient, not mini desktop mode which highly depends on what you install in your image) can easily fit in a client with 1Gb memory, maybe less and this is far more reliable and faster.
The regular TCE-Live with the full-screen X2GoClient login will remain the standard TCE-Live for the time being. Minidesktop is for special use cases; we have a few commercial opportunities there that I would like to explore, that's why we're working on it in parallel. Also, a local browser is nice to have when you're doing web stuff that just won't work well over remote connections, say, Videoconferencing or anything that works fine in Firefox' new rendering engine when used locally, but sucks even with XRENDER enabled. Plus, Firefox has declared that XRENDER is going away soon, and not everybody wants to or can switch to the "Pale Moon" browser (which is going to stick with XRENDER for the foreseeable future).
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
I am getting more an more confused about the TCE stuff. Is there a difference between TCE you are talking about and the x2gothinclient Alex is working on?
Let me clarify then :
TCE is just a micro Linux starting X2Goclient with the --thinclient option in fullscreen (mostly).
There are some other implementations such as "mini desktop" which, to me, is not a "real" Thin Client since you just start a smaller Linux distro with a few local apps (such as web browser) and the X2Go client installed as a local app but I'm not talking about this since this is just x2goclient in local desktop mode.
By default, the x2gothinclient-displaymanager package built by Alex don't have any WM dependencies and thus, if you do a very lightweight TCE setup (aka debootstrap Debian/Ubuntu and install x2gothinclient-displaymanager package), it will only install minimal dependencies such as Xorg libs, x2goclient and a buch of scripts to start it at boot time but no WM. Since there is no WM, xinerama is not working properly and everything is OK with this setup unless you have a dual head (or more) display and in this case, your multiple monitors are used but x2goagent only see ONE huge display that stretches over your screens and not a proper multihead display with multiple monitors the way you have when using a local desktop.
Simply spawning a minimalistic WM such as OpenBox before starting X2Goclient fixes this issue.
Regards, Walid Moghrabi
TRAVAUX.COM BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403 13591 AIX EN PROVENCE CEDEX 3
----- Mail original -----
De: "Ulrich Sibiller" <ulrich.sibiller@gmail.com> À: "Stefan Baur" <X2Go-ML-1@baur-itcs.de> Cc: "Walid MOGHRABI" <w.moghrabi@servicemagic.eu>, x2go-dev@lists.x2go.org Envoyé: Vendredi 18 Mai 2018 09:57:31 Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE
On Fri, May 18, 2018 at 9:47 AM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
Walid,
the proper way to handle this is to set the "MP disable" command *in X2GoClient*, but *only when* X2GoClient is called with *--thinclient*, because that is the option used to tell X2GoClient it is in TCE mode.
And the workaround with the un-minimizing daemon you are talking about is the deprecated one anyways.
I am getting more an more confused about the TCE stuff. Is there a difference between TCE you are talking about and the x2gothinclient Alex is working on?
Uli
DISCLAIMER: This e-mail is private and confidential and may contain proprietary or legally privileged information. It is for the intended recipient only. If you have received this email in error, please notify the author by replying to it and then destroy it. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail or any attachment. Thank you
On Fri, May 18, 2018 at 12:18 AM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
Am 17.05.2018 um 23:21 schrieb Ulrich Sibiller:
Also I suppose we should automatically disable the magic pixel when there's no window manager running. What do you think?
Wait, no. Let's not get confused here. Magic Pixel *is* effectively disabled when there is no Window Manager running, because the command "minimize" is sent to a WM. If there is none, nothing happens. That is fine how it is. No further action needed.
The problem arises on systems that have a Window Manager (like OpenBox), but no task bar, so no way to un-minimize the X2Go/NX-window once the user hits the magic pixel. And we need a way to disable the magic pixel there, because we need OpenBox for several reasons and can't just ditch it to fool NX. So instead of detecting the presence of a Window Manager, we'd need to detect the presence of a task bar. Which, I'd guess, isn't as easy.
Taskbar detection would be plainly wrong. It is completely up the window manager how iconification (and that is what we really talking about, IMHO) is handled. So it totally depends on the window manager what you see and what you can (or can't) do.
Uli
Well, don't ask me ... to me, TCE is TCE and I don't mix X2Go servers dedicated to TCE with X2Go servers dedicated to other usages so, if it was only for me, I would remove MagicPixel completely and eventually replace it by some x2go script that can be triggered manually (by some cli command or desktop app or even keyboard shortcut).
Regards, Walid Moghrabi
TRAVAUX.COM BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403 13591 AIX EN PROVENCE CEDEX 3
----- Mail original -----
De: "Ulrich Sibiller" <ulrich.sibiller@gmail.com> À: "Stefan Baur" <X2Go-ML-1@baur-itcs.de> Cc: x2go-dev@lists.x2go.org Envoyé: Jeudi 17 Mai 2018 23:21:47 Objet: Re: [X2Go-Dev] Different behavior of X2Go Client from Desktop and TCE
On Thu, May 17, 2018 at 3:40 PM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
Am 17.05.2018 um 15:32 schrieb Walid MOGHRABI:
Anyway, having to install a WM in a TCE is not dumb stuff, it makes TCE acts much more like a real desktop than without it (and thus, easier to debug and a more uniform setup than with local fat client).
And that's why we added OpenBox to TCE-live in the first place. (TL;DR: +1)
Nevertheless I have opened an issue on nx-libs (https://github.com/ArcticaProject/nx-libs/pull/694) and I have a possible solution (https://github.com/ArcticaProject/nx-libs/pull/695).
Also I suppose we should automatically disable the magic pixel when there's no window manager running. What do you think?
Uli
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
DISCLAIMER: This e-mail is private and confidential and may contain proprietary or legally privileged information. It is for the intended recipient only. If you have received this email in error, please notify the author by replying to it and then destroy it. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail or any attachment. Thank you
-
Nable -
Oleksandr Shneyder -
Stefan Baur -
Ulrich Sibiller -
Ulrich Sibiller -
Walid MOGHRABI