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.