Hi folks,
I'm interested in using x2go to:
Is this possible?
In my initial perusal of man pages and testing I don't see a way to do what seems to me to be the (probably wrong) solution- instruct the x2go-client (in either launch remote desktop mode, or desktop screen sharing mode) to not capture a specific key combination (like control-alt-right arrow and control-alt-left arrow) so that the parent desktop can handle them (e.g. switch between parent-side virtual desktops).
I'm using Fedora / XFCE for all systems.
Thanks very much in advance!
Jonah
On Thu, Jul 9, 2020 at 10:54 PM Jonah Benton <jonah@jonah.com> wrote:
Hi folks,
I'm interested in using x2go to:
- connect into several individual accounts/machines at the same time
- use each remote machine desktop in full screen mode
- switch between remote full screen desktops using a specific key combination, which would therefore not be sent to the remote
Is this possible?
In my initial perusal of man pages and testing I don't see a way to do what seems to me to be the (probably wrong) solution- instruct the x2go-client (in either launch remote desktop mode, or desktop screen sharing mode) to not capture a specific key combination (like control-alt-right arrow and control-alt-left arrow) so that the parent desktop can handle them (e.g. switch between parent-side virtual desktops).
Well, switching between application windows is a task of your local window manager or, more precisely, its task switching app. The reason you cannot do this in fullscreen sessions is that a session running in fullscreen mode will grab the X server to get ALL keys. That means no other application will get notified of keypresses. The hotkeys ("keystrokes") will be processed by the nxagent and will not reach the session. All others will be forwarded to the session. We could add another keystroke, something like "passthrough" or similar to pass that keystroke to your local X server. But even then I doubt that would work at all because usually grabbing prevents such things from happening. The only other options was to explicitly disable the grab in fullscreen mode which will probably lead to making your local session unusable because a window that is covered by the x2go fullscreen needs some interaction but cannot be activated or similar.
A more pragmatic approach: do not run in fullscreen but use maximized windows instead. Then your local window manager/task switcher will happily fullfill your request to switch to another x2go session.
Uli
Thank you Uli, follow up below-
On Fri, Jul 10, 2020, 2:52 AM Ulrich Sibiller <uli42@gmx.de> wrote:
On Thu, Jul 9, 2020 at 10:54 PM Jonah Benton <jonah@jonah.com> wrote:
Hi folks,
I'm interested in using x2go to:
- connect into several individual accounts/machines at the same time
- use each remote machine desktop in full screen mode
- switch between remote full screen desktops using a specific key
combination, which would therefore not be sent to the remote
Is this possible?
In my initial perusal of man pages and testing I don't see a way to do
what seems to me to be the (probably wrong) solution- instruct the x2go-client (in either launch remote desktop mode, or desktop screen sharing mode) to not capture a specific key combination (like control-alt-right arrow and control-alt-left arrow) so that the parent desktop can handle them (e.g. switch between parent-side virtual desktops).
Well, switching between application windows is a task of your local window manager or, more precisely, its task switching app. The reason you cannot do this in fullscreen sessions is that a session running in fullscreen mode will grab the X server to get ALL keys. That means no other application will get notified of keypresses. The hotkeys ("keystrokes") will be processed by the nxagent and will not reach the session. All others will be forwarded to the session. We could add another keystroke, something like "passthrough" or similar to pass that keystroke to your local X server. But even then I doubt that would work at all because usually grabbing prevents such things from happening. The only other options was to explicitly disable the grab in fullscreen mode which will probably lead to making your local session unusable because a window that is covered by the x2go fullscreen needs some interaction but cannot be activated or similar.
A more pragmatic approach: do not run in fullscreen but use maximized windows instead. Then your local window manager/task switcher will happily fullfill your request to switch to another x2go session.
Uli
The explanation is very helpful and it along with running some experiments has clarified the mental model and convinced me of the futility of my imagined approach. Events are pushed to the client window without grab, but are pulled by the window with grab, acted on or not, and discarded.
So re using maximized windows- the grab behavior allows for key combinations like alt-tab, or copy paste, that are present both locally and remotely to be only processed remotely.
In the absence of grab, can I still achieve the ergonomics of working natively in the remote environment, as with alt-tab? For keys, would I need to bind each needed key combination in the remote environment to a key combination unused in the local environment? Or maybe only alt-tab and shift-alt-tab?
Or is there an "ungrab" but leave full screen, then "regrab" when necessary?
Thanks again, appreciate the insight-
Jonah
On Fri, Jul 10, 2020 at 2:41 PM Jonah Benton <jonah@jonah.com> wrote:
Thank you Uli, follow up below-
On Fri, Jul 10, 2020, 2:52 AM Ulrich Sibiller <uli42@gmx.de> wrote:
On Thu, Jul 9, 2020 at 10:54 PM Jonah Benton <jonah@jonah.com> wrote:
Hi folks,
I'm interested in using x2go to:
- connect into several individual accounts/machines at the same time
- use each remote machine desktop in full screen mode
- switch between remote full screen desktops using a specific key
combination, which would therefore not be sent to the remote
Is this possible?
In my initial perusal of man pages and testing I don't see a way to do
what seems to me to be the (probably wrong) solution- instruct the x2go-client (in either launch remote desktop mode, or desktop screen sharing mode) to not capture a specific key combination (like control-alt-right arrow and control-alt-left arrow) so that the parent desktop can handle them (e.g. switch between parent-side virtual desktops).
Well, switching between application windows is a task of your local window manager or, more precisely, its task switching app. The reason you cannot do this in fullscreen sessions is that a session running in fullscreen mode will grab the X server to get ALL keys. That means no other application will get notified of keypresses. The hotkeys ("keystrokes") will be processed by the nxagent and will not reach the session. All others will be forwarded to the session. We could add another keystroke, something like "passthrough" or similar to pass that keystroke to your local X server. But even then I doubt that would work at all because usually grabbing prevents such things from happening. The only other options was to explicitly disable the grab in fullscreen mode which will probably lead to making your local session unusable because a window that is covered by the x2go fullscreen needs some interaction but cannot be activated or similar.
A more pragmatic approach: do not run in fullscreen but use maximized windows instead. Then your local window manager/task switcher will happily fullfill your request to switch to another x2go session.
Uli
The explanation is very helpful and it along with running some experiments has clarified the mental model and convinced me of the futility of my imagined approach. Events are pushed to the client window without grab, but are pulled by the window with grab, acted on or not, and discarded.
So re using maximized windows- the grab behavior allows for key combinations like alt-tab, or copy paste, that are present both locally and remotely to be only processed remotely.
In the absence of grab, can I still achieve the ergonomics of working natively in the remote environment, as with alt-tab? For keys, would I need to bind each needed key combination in the remote environment to a key combination unused in the local environment? Or maybe only alt-tab and shift-alt-tab?
Or is there an "ungrab" but leave full screen, then "regrab" when necessary?
Hmm, some time I ago we implemented a feature called "autograb". In default setup you can can enable/disable it using ctrl-alt-g. In that mode the grab gets activated when the x2go window gets focus. That means when the window is active alt-tab and other combinations will be grabbed by x2go while they will be interpreted by the local session when the x2go window is not active. This allows you to use alt-tab in an x2go session without the local session interfering. So I suggest you experiment with a mixture of alt-tab and ctrl-alt-g. If you see room for improvement here please let us know.
Uli
Thank you- hmm, it looks like using the autograb key combo (c-a-g) causes the entire window to disappear. In the session.log below, this shows up as a request to suspend the session. Is that expected behavior? I'm using the Fedora 32 XFCE spin, with Fedora's packaging of x2go, for both local and remote environments.
Info: using keystrokes file '/etc/x2go/keystrokes.cfg' Info: ignoring unknown keystroke action 'debug_tree'. Info: ignoring unknown keystroke action 'regions_on_screen'. Info: ignoring unknown keystroke action 'test_input'. Info: ignoring unknown keystroke action 'deactivate_input_devices_grab'. Currently known keystrokes: close_session : Ctrl+Alt+t switch_all_screens : Ctrl+Alt+f minimize : Ctrl+Alt+m resize : Ctrl+Alt+r defer : Ctrl+Alt+e ignore : Ctrl+Alt+BackSpace force_synchronization : Ctrl+Alt+j fullscreen : Ctrl+Shift+Alt+f autograb : Ctrl+Alt+g viewport_move_left : Ctrl+Shift+Alt+Left viewport_move_right : Ctrl+Alt+Right Session: Session resumed at 'Fri Jul 10 10:32:35 2020'. Info: Screen [0] resized to geometry [2560x1576] fullscreen [0]. cat: /proc/183021/environ: Permission denied Session: Suspending session at 'Fri Jul 10 10:32:54 2020'. Info: Waiting the cleanup timeout to complete. Session: Session suspended at 'Fri Jul 10 10:32:55 2020'.
On Fri, Jul 10, 2020 at 8:52 AM Ulrich Sibiller <uli42@gmx.de> wrote:
On Fri, Jul 10, 2020 at 2:41 PM Jonah Benton <jonah@jonah.com> wrote:
Thank you Uli, follow up below-
On Fri, Jul 10, 2020, 2:52 AM Ulrich Sibiller <uli42@gmx.de> wrote:
On Thu, Jul 9, 2020 at 10:54 PM Jonah Benton <jonah@jonah.com> wrote:
Hi folks,
I'm interested in using x2go to:
- connect into several individual accounts/machines at the same time
- use each remote machine desktop in full screen mode
- switch between remote full screen desktops using a specific key
combination, which would therefore not be sent to the remote
Is this possible?
In my initial perusal of man pages and testing I don't see a way to
do what seems to me to be the (probably wrong) solution- instruct the x2go-client (in either launch remote desktop mode, or desktop screen sharing mode) to not capture a specific key combination (like control-alt-right arrow and control-alt-left arrow) so that the parent desktop can handle them (e.g. switch between parent-side virtual desktops).
Well, switching between application windows is a task of your local window manager or, more precisely, its task switching app. The reason you cannot do this in fullscreen sessions is that a session running in fullscreen mode will grab the X server to get ALL keys. That means no other application will get notified of keypresses. The hotkeys ("keystrokes") will be processed by the nxagent and will not reach the session. All others will be forwarded to the session. We could add another keystroke, something like "passthrough" or similar to pass that keystroke to your local X server. But even then I doubt that would work at all because usually grabbing prevents such things from happening. The only other options was to explicitly disable the grab in fullscreen mode which will probably lead to making your local session unusable because a window that is covered by the x2go fullscreen needs some interaction but cannot be activated or similar.
A more pragmatic approach: do not run in fullscreen but use maximized windows instead. Then your local window manager/task switcher will happily fullfill your request to switch to another x2go session.
Uli
The explanation is very helpful and it along with running some experiments has clarified the mental model and convinced me of the futility of my imagined approach. Events are pushed to the client window without grab, but are pulled by the window with grab, acted on or not, and discarded.
So re using maximized windows- the grab behavior allows for key combinations like alt-tab, or copy paste, that are present both locally and remotely to be only processed remotely.
In the absence of grab, can I still achieve the ergonomics of working natively in the remote environment, as with alt-tab? For keys, would I need to bind each needed key combination in the remote environment to a key combination unused in the local environment? Or maybe only alt-tab and shift-alt-tab?
Or is there an "ungrab" but leave full screen, then "regrab" when necessary?
Hmm, some time I ago we implemented a feature called "autograb". In default setup you can can enable/disable it using ctrl-alt-g. In that mode the grab gets activated when the x2go window gets focus. That means when the window is active alt-tab and other combinations will be grabbed by x2go while they will be interpreted by the local session when the x2go window is not active. This allows you to use alt-tab in an x2go session without the local session interfering. So I suggest you experiment with a mixture of alt-tab and ctrl-alt-g. If you see room for improvement here please let us know.
Uli
Hmm, interesting. Ah, yeah, I know what the problem really is. NXCLIENT variable is wrong. I will provide a longer answer later.
Uli
Jonah Benton <jonah@jonah.com> schrieb am Fr., 10. Juli 2020, 16:42:
Thank you- hmm, it looks like using the autograb key combo (c-a-g) causes the entire window to disappear. In the session.log below, this shows up as a request to suspend the session. Is that expected behavior? I'm using the Fedora 32 XFCE spin, with Fedora's packaging of x2go, for both local and remote environments.
Info: using keystrokes file '/etc/x2go/keystrokes.cfg' Info: ignoring unknown keystroke action 'debug_tree'. Info: ignoring unknown keystroke action 'regions_on_screen'. Info: ignoring unknown keystroke action 'test_input'. Info: ignoring unknown keystroke action 'deactivate_input_devices_grab'. Currently known keystrokes: close_session : Ctrl+Alt+t switch_all_screens : Ctrl+Alt+f minimize : Ctrl+Alt+m resize : Ctrl+Alt+r defer : Ctrl+Alt+e ignore : Ctrl+Alt+BackSpace force_synchronization : Ctrl+Alt+j fullscreen : Ctrl+Shift+Alt+f autograb : Ctrl+Alt+g viewport_move_left : Ctrl+Shift+Alt+Left viewport_move_right : Ctrl+Alt+Right Session: Session resumed at 'Fri Jul 10 10:32:35 2020'. Info: Screen [0] resized to geometry [2560x1576] fullscreen [0]. cat: /proc/183021/environ: Permission denied Session: Suspending session at 'Fri Jul 10 10:32:54 2020'. Info: Waiting the cleanup timeout to complete. Session: Session suspended at 'Fri Jul 10 10:32:55 2020'.
On Fri, Jul 10, 2020 at 8:52 AM Ulrich Sibiller <uli42@gmx.de> wrote:
On Fri, Jul 10, 2020 at 2:41 PM Jonah Benton <jonah@jonah.com> wrote:
Thank you Uli, follow up below-
On Fri, Jul 10, 2020, 2:52 AM Ulrich Sibiller <uli42@gmx.de> wrote:
On Thu, Jul 9, 2020 at 10:54 PM Jonah Benton <jonah@jonah.com> wrote:
Hi folks,
I'm interested in using x2go to:
- connect into several individual accounts/machines at the same time
- use each remote machine desktop in full screen mode
- switch between remote full screen desktops using a specific key
combination, which would therefore not be sent to the remote
Is this possible?
In my initial perusal of man pages and testing I don't see a way to
do what seems to me to be the (probably wrong) solution- instruct the x2go-client (in either launch remote desktop mode, or desktop screen sharing mode) to not capture a specific key combination (like control-alt-right arrow and control-alt-left arrow) so that the parent desktop can handle them (e.g. switch between parent-side virtual desktops).
Well, switching between application windows is a task of your local window manager or, more precisely, its task switching app. The reason you cannot do this in fullscreen sessions is that a session running in fullscreen mode will grab the X server to get ALL keys. That means no other application will get notified of keypresses. The hotkeys ("keystrokes") will be processed by the nxagent and will not reach the session. All others will be forwarded to the session. We could add another keystroke, something like "passthrough" or similar to pass that keystroke to your local X server. But even then I doubt that would work at all because usually grabbing prevents such things from happening. The only other options was to explicitly disable the grab in fullscreen mode which will probably lead to making your local session unusable because a window that is covered by the x2go fullscreen needs some interaction but cannot be activated or similar.
A more pragmatic approach: do not run in fullscreen but use maximized windows instead. Then your local window manager/task switcher will happily fullfill your request to switch to another x2go session.
Uli
The explanation is very helpful and it along with running some experiments has clarified the mental model and convinced me of the futility of my imagined approach. Events are pushed to the client window without grab, but are pulled by the window with grab, acted on or not, and discarded.
So re using maximized windows- the grab behavior allows for key combinations like alt-tab, or copy paste, that are present both locally and remotely to be only processed remotely.
In the absence of grab, can I still achieve the ergonomics of working natively in the remote environment, as with alt-tab? For keys, would I need to bind each needed key combination in the remote environment to a key combination unused in the local environment? Or maybe only alt-tab and shift-alt-tab?
Or is there an "ungrab" but leave full screen, then "regrab" when necessary?
Hmm, some time I ago we implemented a feature called "autograb". In default setup you can can enable/disable it using ctrl-alt-g. In that mode the grab gets activated when the x2go window gets focus. That means when the window is active alt-tab and other combinations will be grabbed by x2go while they will be interpreted by the local session when the x2go window is not active. This allows you to use alt-tab in an x2go session without the local session interfering. So I suggest you experiment with a mixture of alt-tab and ctrl-alt-g. If you see room for improvement here please let us know.
Uli
Ok, thank you, it looks like more guidance will be very welcome; in looking through the source tree and docs I can guess at a link where there needs to be a tool referenced in the NX_CLIENT environment variable, but starting x2goclient as:
$ which nxdialog /usr/bin/nxdialog $ NX_CLIENT=/usr/bin/nxdialog x2goclient
does not yield different autograb behavior. Will continue to experiment but any additional details will be great, thanks again.
Jonah
On Fri, Jul 10, 2020 at 11:54 AM Ulrich Sibiller <uli42@gmx.de> wrote:
Hmm, interesting. Ah, yeah, I know what the problem really is. NXCLIENT variable is wrong. I will provide a longer answer later.
Uli
Jonah Benton <jonah@jonah.com> schrieb am Fr., 10. Juli 2020, 16:42:
Thank you- hmm, it looks like using the autograb key combo (c-a-g) causes the entire window to disappear. In the session.log below, this shows up as a request to suspend the session. Is that expected behavior? I'm using the Fedora 32 XFCE spin, with Fedora's packaging of x2go, for both local and remote environments.
Info: using keystrokes file '/etc/x2go/keystrokes.cfg' Info: ignoring unknown keystroke action 'debug_tree'. Info: ignoring unknown keystroke action 'regions_on_screen'. Info: ignoring unknown keystroke action 'test_input'. Info: ignoring unknown keystroke action 'deactivate_input_devices_grab'. Currently known keystrokes: close_session : Ctrl+Alt+t switch_all_screens : Ctrl+Alt+f minimize : Ctrl+Alt+m resize : Ctrl+Alt+r defer : Ctrl+Alt+e ignore : Ctrl+Alt+BackSpace force_synchronization : Ctrl+Alt+j fullscreen : Ctrl+Shift+Alt+f autograb : Ctrl+Alt+g viewport_move_left : Ctrl+Shift+Alt+Left viewport_move_right : Ctrl+Alt+Right Session: Session resumed at 'Fri Jul 10 10:32:35 2020'. Info: Screen [0] resized to geometry [2560x1576] fullscreen [0]. cat: /proc/183021/environ: Permission denied Session: Suspending session at 'Fri Jul 10 10:32:54 2020'. Info: Waiting the cleanup timeout to complete. Session: Session suspended at 'Fri Jul 10 10:32:55 2020'.
On Fri, Jul 10, 2020 at 8:52 AM Ulrich Sibiller <uli42@gmx.de> wrote:
On Fri, Jul 10, 2020 at 2:41 PM Jonah Benton <jonah@jonah.com> wrote:
Thank you Uli, follow up below-
On Fri, Jul 10, 2020, 2:52 AM Ulrich Sibiller <uli42@gmx.de> wrote:
On Thu, Jul 9, 2020 at 10:54 PM Jonah Benton <jonah@jonah.com> wrote:
Hi folks,
I'm interested in using x2go to:
- connect into several individual accounts/machines at the same time
- use each remote machine desktop in full screen mode
- switch between remote full screen desktops using a specific key
combination, which would therefore not be sent to the remote
Is this possible?
In my initial perusal of man pages and testing I don't see a way to
do what seems to me to be the (probably wrong) solution- instruct the x2go-client (in either launch remote desktop mode, or desktop screen sharing mode) to not capture a specific key combination (like control-alt-right arrow and control-alt-left arrow) so that the parent desktop can handle them (e.g. switch between parent-side virtual desktops).
Well, switching between application windows is a task of your local window manager or, more precisely, its task switching app. The reason you cannot do this in fullscreen sessions is that a session running in fullscreen mode will grab the X server to get ALL keys. That means no other application will get notified of keypresses. The hotkeys ("keystrokes") will be processed by the nxagent and will not reach the session. All others will be forwarded to the session. We could add another keystroke, something like "passthrough" or similar to pass that keystroke to your local X server. But even then I doubt that would work at all because usually grabbing prevents such things from happening. The only other options was to explicitly disable the grab in fullscreen mode which will probably lead to making your local session unusable because a window that is covered by the x2go fullscreen needs some interaction but cannot be activated or similar.
A more pragmatic approach: do not run in fullscreen but use maximized windows instead. Then your local window manager/task switcher will happily fullfill your request to switch to another x2go session.
Uli
The explanation is very helpful and it along with running some experiments has clarified the mental model and convinced me of the futility of my imagined approach. Events are pushed to the client window without grab, but are pulled by the window with grab, acted on or not, and discarded.
So re using maximized windows- the grab behavior allows for key combinations like alt-tab, or copy paste, that are present both locally and remotely to be only processed remotely.
In the absence of grab, can I still achieve the ergonomics of working natively in the remote environment, as with alt-tab? For keys, would I need to bind each needed key combination in the remote environment to a key combination unused in the local environment? Or maybe only alt-tab and shift-alt-tab?
Or is there an "ungrab" but leave full screen, then "regrab" when necessary?
Hmm, some time I ago we implemented a feature called "autograb". In default setup you can can enable/disable it using ctrl-alt-g. In that mode the grab gets activated when the x2go window gets focus. That means when the window is active alt-tab and other combinations will be grabbed by x2go while they will be interpreted by the local session when the x2go window is not active. This allows you to use alt-tab in an x2go session without the local session interfering. So I suggest you experiment with a mixture of alt-tab and ctrl-alt-g. If you see room for improvement here please let us know.
Uli
On Fri, Jul 10, 2020 at 6:33 PM Jonah Benton <jonah@jonah.com> wrote:
Ok, thank you, it looks like more guidance will be very welcome; in looking through the source tree and docs I can guess at a link where there needs to be a tool referenced in the NX_CLIENT environment variable, but starting x2goclient as:
$ which nxdialog /usr/bin/nxdialog $ NX_CLIENT=/usr/bin/nxdialog x2goclient
Very close! You need to change it in /usr/bin/x2gostartagent on the server:
Change export NX_CLIENT="${X2GO_LIB_PATH}/x2gosuspend-agent" to export NX_CLIENT="/usr/bin/nxdialog"
Uli
Thank you, unfortunately I am still seeing the same behavior. Starting x2goclient with:
$ NX_CLIENT=/usr/bin/x2gosuspend-session x2goclient
and logging in to the specific session creates a non-grabbed window that occupies the full desktop.
Using control-alt-g on that session window causes the window to disappear, with the session suspend logging in the session log below.
When I re-login to that remote session ("remote", as I'm just using another account on localhost for testing) from inside the x2goclient UI, the window reopens with grabbing behavior, and alt-tab rotates between windows in the remote session.
So the autograb toggle works, but it leads to session suspension, the reasons for which are not clear to me.
Thanks again for help, will continue to research on this side-
Jonah
==
Session: Resuming session at 'Fri Jul 10 14:06:28 2020'. Info: Proxy running in client mode with pid '977946'. Info: Using errors file '/tmp/.x2go-money/C-money-51-1594402387_stDXFCE_dp24/session.log'. Info: Using stats file '/tmp/.x2go-money/C-money-51-1594402387_stDXFCE_dp24/C-money-51-1594402387_stDXFCE_dp24/stats'. Loop: WARNING! Unrecognized session type 'unix-kde-depth_24'. Assuming agent session. Warning: Unrecognized session type 'unix-kde-depth_24'. Assuming agent session. Info: Waiting for connection from 'localhost' on socket 'tcp:*:47379'. Info: Accepted connection from '127.0.0.1'. Loop: Identified remote version '3.5.99'. Loop: Remote compatibility version '3.5.0'. Loop: Local version '3.5.99'. Info: Connection with remote proxy completed. Info: Using LAN link parameters 1536/24/1/0. Info: Using agent parameters 5000/0/50/0/0. Info: Using pack method '16m-jpeg-9' with session 'unix-kde-depth_24'. Info: Not using NX delta compression. Info: Not using ZLIB data compression. Info: Not using ZLIB stream compression. Info: Not using a persistent cache. Info: Listening to X11 connections on display ':51'. Info: Established X client connection. Info: Using shared memory parameters 1/1/0/0K. Info: Not using local device configuration changes. Info: keyboard blocking directory created: '/home/money/.x2go/C-money-51-1594402387_stDXFCE_dp24/keyboard' Info: Keycode conversion is off Info: re-reading keystrokes configuration Warning: Cannot read keystroke file '/home/money/.x2go/config/keystrokes.cfg'. Info: using keystrokes file '/etc/x2go/keystrokes.cfg' Info: ignoring unknown keystroke action 'debug_tree'. Info: ignoring unknown keystroke action 'regions_on_screen'. Info: ignoring unknown keystroke action 'test_input'. Info: ignoring unknown keystroke action 'deactivate_input_devices_grab'. Currently known keystrokes: close_session : Ctrl+Alt+t switch_all_screens : Ctrl+Alt+f minimize : Ctrl+Alt+m resize : Ctrl+Alt+r defer : Ctrl+Alt+e ignore : Ctrl+Alt+BackSpace force_synchronization : Ctrl+Alt+j fullscreen : Ctrl+Shift+Alt+f autograb : Ctrl+Alt+g viewport_move_left : Ctrl+Shift+Alt+Left viewport_move_right : Ctrl+Alt+Right Session: Session resumed at 'Fri Jul 10 14:06:29 2020'. Info: Screen [0] resized to geometry [2560x1576] fullscreen [0]. Session: Suspending session at 'Fri Jul 10 14:07:42 2020'. Info: Waiting the cleanup timeout to complete. Session: Session suspended at 'Fri Jul 10 14:07:43 2020'.
On Fri, Jul 10, 2020 at 1:03 PM Ulrich Sibiller <uli42@gmx.de> wrote:
On Fri, Jul 10, 2020 at 6:33 PM Jonah Benton <jonah@jonah.com> wrote:
Ok, thank you, it looks like more guidance will be very welcome; in
looking through the source tree and docs I can guess at a link where there needs to be a tool referenced in the NX_CLIENT environment variable, but starting x2goclient as:
$ which nxdialog /usr/bin/nxdialog $ NX_CLIENT=/usr/bin/nxdialog x2goclient
Very close! You need to change it in /usr/bin/x2gostartagent on the server:
Change export NX_CLIENT="${X2GO_LIB_PATH}/x2gosuspend-agent" to export NX_CLIENT="/usr/bin/nxdialog"
Uli