[X2Go-User] Configure x2go-client to not forward specific key combinations?
Ulrich Sibiller
uli42 at gmx.de
Fri Jul 10 14:52:41 CEST 2020
On Fri, Jul 10, 2020 at 2:41 PM Jonah Benton <jonah at jonah.com> wrote:
>
> Thank you Uli, follow up below-
>
> On Fri, Jul 10, 2020, 2:52 AM Ulrich Sibiller <uli42 at gmx.de> wrote:
>>
>> On Thu, Jul 9, 2020 at 10:54 PM Jonah Benton <jonah at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x2go.org/pipermail/x2go-user/attachments/20200710/ff78de11/attachment.htm>
More information about the x2go-user
mailing list