xpra icon
Bug tracker and wiki

Opened 3 years ago

Last modified 12 months ago

#708 new defect

Cannot switch window focus using keyboard on OS X

Reported by: jbylsma Owned by: ddally
Priority: major Milestone: future
Component: client Version: 0.14.x
Keywords: osx keyboard Cc: derekdally@…

Description

Cmd-` (backtick) is the default OS X binding for "Move focus to next window." However, this behavior does not work with current (0.14.x) xpra OS X client. Other low-level (lower-level?) keyboard shortcuts work, such as hiding all xpra windows with Cmd-h and quitting xpra with Cmd-q.

In my amateur investigation with -d keyboard and xev, it looks like Cmd-` is being sent to the server and not being processed locally.

So far, I've tried toggling swap keys, as well as binding "Move focus to next window" to other, non-modifier keyboard shortcuts (F19, NumPad?'s *).

Perhaps silly, but I have confirmed that switching windows works with the Windows and Linux clients.

Thank you!

Attachments (1)

propagate-keyboard-events.patch (737 bytes) - added by Antoine Martin 3 years ago.
lets keyboard events reach the standard gtk.Window code

Download all attachments as: .zip

Change History (22)

comment:1 Changed 3 years ago by Antoine Martin

Keywords: osx keyboard added
Owner: changed from Antoine Martin to Antoine Martin
Priority: majorminor
Status: newassigned

I believe that this is a GTK toolkit issue, there is nothing in our code that could intercept keyboard events meant for the host OS.

From what I am reading, it looks like toolkits need to re-inject keyboard events back into the host OS (very strange way of doing things on osx), and for some reason either the other other events don't get passed on, or GTK correctly passes them back to the OS. Just not this one.

Links:

I will try to get a bug report upstream.

Changed 3 years ago by Antoine Martin

lets keyboard events reach the standard gtk.Window code

comment:2 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to jbylsma
Status: assignednew

@jbylsma: I have OSX 10.5.8 in a VM and command + backtick doesn't do anything here, it could be the odd virtual machine keyboard mapping, or the fact this is an older version of OSX.
In any case, I am unable to test the patch above... But maybe you can?
I don't see any mention of such a bug against gtk-osx, so this may well be all we need to do. I just can't tell.

@afarr: can you make a build with this patch applied? or even just help me figure out if this key combination is even meant to do anything?

comment:3 Changed 3 years ago by alas

I'll see about trying to arrange a patch (still having issues with my build vm, which I haven't found enough time to sort out).

I was able to figure out what the command- seems to do. With a 10.6.8 OSX machine the command-tab opens a slide-show for selecting between active applications, with each press of the tab button advancing left to right through the slide-show. With the command button still pressed and the slide-show still displaying, the key allows you to reverse direction and go right to left through the list.

The command-` combination, in itself, doesn't seem to do anything much: with focus on a terminal window it makes the global menu window option flash, and with focus on a finder window it seems to toggle the focus off/on (though not to other finder windows, oddly enough).

I'm guessing he wants the ` key to allow reverse tabbing through xpra session applications?... just a guess though really.

comment:4 Changed 3 years ago by Antoine Martin

Owner: changed from jbylsma to alas

(re-assigning)

comment:5 Changed 3 years ago by J. Max Mena

Retested with an OSX 10.10.1 r8647 client against a Fedora 20 r8661 server:

Command + ` functionality does not work in Xpra. I have a feeling it's because the host OS doesn't recognize the command as a valid keyboard shortcut so it doesn't know what to do. For what it's worth the Python keyboard helper produces the following output with the Command and ` keys(no special print with both depressed):

Client:

down/up Meta_L [blank] 65511 55 1 0 ['2'](on up, [] on down)
down/up grave ` 96 50 50 0 0 [](on down and up)

Server(Through Xpra):

down/up Control_L 65507 37 1 0 ['2', 'C'] (down and up)
down/up grave 96 49 0 0 ['2', 'C'] (down and up)

edit:
A quick google search produces the following webpage that may be of use:

https://wiki.gnome.org/Projects/GnomeShell/CheatSheet

Last edited 3 years ago by J. Max Mena (previous) (diff)

comment:6 Changed 3 years ago by Antoine Martin

Milestone: future

I've tried again with virtualbox, no go. I even tried passing through some USB keyboards to the guest, the first one didn't work, with the second one my virtual machine got stuck and had to be rebooted...
So I can't do anything about this right now.

comment:7 Changed 2 years ago by Antoine Martin

See also #906.

comment:8 Changed 2 years ago by J. Max Mena

Owner: changed from alas to Antoine Martin

(Ceremonial re-assign; totally not doing this so it looks like I am getting something done. In reality, it was left to afarr by accident; I forgot to re-assign back to you.)

For what it's worth:

You can get identical behavior(what the original ticket is looking for) in XFCE with the meta + tab command. This works as expected in Fedora.

comment:9 Changed 13 months ago by ddally

I'm able to reproduce this issue with the 0.17.4 Mac client (macOS Sierra) and 0.17.6 server on Ubuntu 16.04. It's not a major problem but it does make dealing with a large amount of remote windows a little more difficult.

Any ideas of what I might try? Happy to gather logs, try test cases, etc.

comment:10 Changed 13 months ago by ddally

Cc: derekdally@… added

comment:11 Changed 13 months ago by ddally

Priority: minormajor

I bumped the priority of this ticket to 'major', as it's somewhat of a headache once a larger number of remote windows are opened. Is anyone else seeing this issue with Mac clients (or NOT seeing the issue with Mac clients)? I'd be happy to help troubleshoot/capture logs.

Thanks,
Derek

comment:12 Changed 13 months ago by Antoine Martin

Owner: changed from Antoine Martin to ddally

@ddally: can you try this patch: attachment/ticket/708/propagate-keyboard-events.patch (just add those two lines)
I don't have Mac hardware with me at the moment and the VM I have with me (10.5.8) doesn't do anything when I hit this key combination.. so I cannot test this. FWIW: Command+Tab does work here.

See also #906.

Last edited 13 months ago by Antoine Martin (previous) (diff)

comment:13 Changed 13 months ago by ddally

Hi -

I applied this patch and reattached the client. Command+` still doesn't have an effect. I tested on an (unpatched) Linux client and see the behavior I'd expect (cycling through Xpra windows).

I tried a couple of other Control and Alt-based key combinations to see if any would provide the same functionality, but none seem to.

comment:14 Changed 13 months ago by Antoine Martin

OK, just another idea: can you try adding return True or return False at the end of those two key event handling functions?
True means we have handled the event so that's unlikely to help, False is the default return value.. so that's also unlikely to help. But worth a try.

comment:15 Changed 13 months ago by ddally

Hi -

I'm trying to collect some logs on the server side, similar to what @maxmylyn had done earlier with the -d keyboard flag. I'm starting with the working Linux server/Linux client setup, but the lines that are output in the log aren't consistent from one keypress to the next.

Here's a chunk of the logs for the window-switching usecase (Linux client):

2016-11-15 07:23:21,137 handle_key(3,0,Alt_L,65513,64,['mod1']) keyboard_sync=True  
2016-11-15 07:23:21,137 handle keycode unpressing 64: key Alt_L
2016-11-15 07:23:21,137 fake_key(64, False)
2016-11-15 07:24:05,424 get_keycode(64, Alt_L, []) native keymap, using unmodified keycode: 64
2016-11-15 07:24:05,424 filtered_modifiers_set([])=
2016-11-15 07:24:05,425 filtered_modifiers_set([])=
2016-11-15 07:24:05,425 handle_key(3,1,Alt_L,65513,64,[]) keyboard_sync=True
2016-11-15 07:24:05,425 handle keycode pressing 64: key Alt_L
2016-11-15 07:24:05,425 fake_key(64, True)
2016-11-15 07:24:05,635 _clear_keys_pressed()
2016-11-15 07:24:06,068 filtered_modifiers_set([])=
2016-11-15 07:24:06,068 filtered_modifiers_set([])=  

In the Linux client use case, toggling between windows in the same application works with Alt+Backtick. However, in the logging, I don't see any relevant lines related to the backtick key being depressed. The "_clear_keys_pressed()" and "filtered_modifiers_set([])" are the only lines that appear when backtick is pressed.

Once I understand the logging, I'll hopefully be able to collect/diagnose the Mac use case.

comment:16 Changed 13 months ago by Antoine Martin

The reason why you're not seeing those keys is that the Linux desktop intercepts them before the client application can see them.

In the macos case, the OS doesn't intercepts them, so either we have to tell it that we didn't handle the keys (return True / False) or we have to re-inject those events into the OS.

For debugging, it's probably best to just log the client side.

comment:17 Changed 13 months ago by ddally

Hi -

I tried with both return True and return False. Unfortunately no luck there. Will try to capture some Mac client side keyboard logs.

comment:18 Changed 13 months ago by Antoine Martin

Asked the gtk-osx mailing list and here's the reply: Command+Backtick shortcut intercepted:
Yes, it seems to be generally true.

I don't know offhand how switching windows in response to cmd-backtick is implemented in Cocoa (or ctrl-tab Gnome, for that matter), but I suspect that it's handled by the NSApplication object and that it requires that the Windows menu be managed by that object. There's nothing in GtkosxApplication? to do that. I think that's more likely to be the problem rather than that cmd-backtick is getting eaten by Gtk-2.

As long as your application uses GtkActions? you can configure shortcuts with an accel map. This is demonstrated at line 877 of test-integration.c.

Looks like the fix needs to go in gtk-osx...

Last edited 13 months ago by Antoine Martin (previous) (diff)

comment:19 Changed 13 months ago by ddally

Hi -

Here are the logs on the Mac client side:

2016-11-15 21:05:03,341 mask_to_names(<flags 0 of type GdkModifierType>)=['mod2']
2016-11-15 21:05:03,341 parse_key_event(<gtk.gdk.Event at 0xdf1acc8: GDK_KEY_PRESS keyval=Meta_L>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': True, 'keyval': 65511, 'keycode': 55}>
2016-11-15 21:05:03,341 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (660, 488), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': True, 'keyval': 65511, 'keycode': 55}>) wid=3
2016-11-15 21:05:03,342 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': True, 'keyval': 65511, 'keycode': 55}>)
2016-11-15 21:05:03,460 mask_to_names(<flags GDK_MOD2_MASK | GDK_META_MASK of type GdkModifierType>)=['mod2']
2016-11-15 21:05:03,461 parse_key_event(<gtk.gdk.Event at 0xdf1acc8: GDK_KEY_PRESS keyval=grave>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '`', 'keyname': 'grave', 'pressed': True, 'keyval': 96, 'keycode': 50}>
2016-11-15 21:05:03,461 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (660, 488), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '`', 'keyname': 'grave', 'pressed': True, 'keyval': 96, 'keycode': 50}>) wid=3
2016-11-15 21:05:03,461 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '`', 'keyname': 'grave', 'pressed': True, 'keyval': 96, 'keycode': 50}>)
2016-11-15 21:05:03,555 mask_to_names(<flags GDK_MOD2_MASK | GDK_META_MASK of type GdkModifierType>)=['mod2']
2016-11-15 21:05:03,555 parse_key_event(<gtk.gdk.Event at 0xdf1acc8: GDK_KEY_RELEASE keyval=grave>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '`', 'keyname': 'grave', 'pressed': False, 'keyval': 96, 'keycode': 50}>
2016-11-15 21:05:03,555 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (660, 488), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '`', 'keyname': 'grave', 'pressed': False, 'keyval': 96, 'keycode': 50}>) wid=3
2016-11-15 21:05:03,556 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '`', 'keyname': 'grave', 'pressed': False, 'keyval': 96, 'keycode': 50}>)
2016-11-15 21:05:03,603 mask_to_names(<flags GDK_MOD2_MASK | GDK_META_MASK of type GdkModifierType>)=['mod2']
2016-11-15 21:05:03,603 parse_key_event(<gtk.gdk.Event at 0xdf1acc8: GDK_KEY_RELEASE keyval=Meta_L>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': False, 'keyval': 65511, 'keycode': 55}>
2016-11-15 21:05:03,603 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (660, 488), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': False, 'keyval': 65511, 'keycode': 55}>) wid=3
2016-11-15 21:05:03,604 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': False, 'keyval': 65511, 'keycode': 55}>)

It looks like John's suggestion would be to add an accel map for MacOS builds. The toggling of windows within an application seems like a general-enough use case that it'd be something that GTK should abstract away, no?

What would be a good example of another GTK-based MacOS app to test? I had thought that Pidgin would be a good option but it looks like it's not supported (or at least not recommended) for MacOS.

comment:20 Changed 13 months ago by Antoine Martin

Other apps that use gtk-osx with pygtk2 - AFAIK:

etc..

comment:21 Changed 12 months ago by ddally

Hi -

Here's a minimal program to demonstrate the behavior:

#include <gtk/gtk.h>

int main(int argc, char* argv[]) {

  gtk_init(&argc, &argv);

  gtk_widget_show(gtk_window_new(GTK_WINDOW_TOPLEVEL));
  gtk_widget_show(gtk_window_new(GTK_WINDOW_TOPLEVEL));
  
  gtk_main();

  return 0;
}

Toggling windows works with a Linux-based Xpra client, but not a Mac-based one. Another possibly interesting note is that window cycling does work correctly with XQuartz (vanilla X forwarding as opposed to Xpra) from a Linux machine.

It does seem that if GtkosxApplication? provides the translation from GTK to NSApplication that that would be the logical place for the window toggling functionality to exist.

Is toggling windows within an application a seldom-used use case? I would have thought that it would be core functionality for gtk-osx.

Thanks,
Derek

Note: See TracTickets for help on using tickets.