GitLab

Steps to reproduce

1. Create an app with two TopLevel windows (sample code attached)

#include <gtk/gtk.h>

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

  gtk_init(&argc, &argv);

  GtkWidget* first = gtk_window_new(GTK_WINDOW_TOPLEVEL);
  gtk_window_set_title(GTK_WINDOW(first), "first");
  GtkWidget* second = gtk_window_new(GTK_WINDOW_TOPLEVEL);
  gtk_window_set_title(GTK_WINDOW(second), "second");

  gtk_widget_show(first);
  gtk_widget_show(second);

  gtk_main();

  return 0;
}

	gcc app.c `pkg-config --cflags --libs gtk+-3.0` -o app

2. Run it on MacOS
3. Try to switch between application windows using standard osx key binding (CMD+`)

Current behavior

There's no reaction whatsoever. Event is swallowed by GTK and no default action is triggered.

You can observe it on this video (first I show stable gtk, then I show customized version I prepared to overcome the issue):

Cmd+` Issue

Expected outcome

Active application window should change each time you hit CMD+`

Version information

3.24

Additional information

The origin of the issue for me is this ticket on xpra bug-tracker:

https://xpra.org/trac/ticket/708

I digged into this problem only to find out that xpra has nothing to do with swallowing the event and in fact it's GTK which does not propagate event back to the system if event was NOT handled.

I prepared some workaround for the problem which works like this:

At the bubbling phase of keyboard events see if the event was handled, if not send the native event back to the OS for some default behavior.

I implemented it by adding new GdkDisplayClass method called "event_propagate_native". By default it does nothing but returning "FALSE" (meaning event was not handled). However Quartz implementation forwards keyboard events back to the system which makes the shortcuts like CMD+` work just fine. I got the inspiration from chromium where that's the way they handle it (by passing the native keyboard events back to NSApp).