wxGTK with GTK3: Menu shortcuts don't work when some (most?) controls are focused

My app has a wxAUI frame with several panes and one of them contains a 
wxTreeCtrl. The frame has a menu bar with a menu item with a Ctrl+N 
shortcut, that only works before clicking on the wxTreeCtrl.
I've found that the issue is driven by the currently focused control; if 
the control recognizes Ctrl+N as a valid key for some action it will 
consume the key press and prevent the menu shortcut from triggering. The 
same code on wxMSW works without issues.
This is a common problem from what I gather from this issue and others 
found in here and online. So far I've only reiterated a common symptom, 
but I've also tried to understand the reason, which has other implications.
So I've debugged the code and found that the main issue is this piece of 
code on gtk/toplevel.cpp/wxgtk_tlw_key_press_event():

// By default GTK+ checks for the menu accelerators in this (top level)
// window first and then propagates the event to the currently focused
// child from where it bubbles up the window parent chain. In wxWidgets,
// however, we want the child window to have the event first but still
// handle it as an accelerator if it's not processed there, so we need to
// customize this by reversing the order of the steps done in the standard
// GTK+ gtk_window_key_press_event() handler.

|if ( gtk_window_propagate_key_event(window, event) ) return true; if ( 
gtk_window_activate_key(window, event) ) return true; |

This code is the reason why the controls take precedence over the 
mnemonics and menu shortcuts; if the key press is handled by any control 
on the focus chain then the menu shortcuts cannot work. This is an 
architectural choice.
This choice opens another can of worms that make menu shortcuts 
completely unusable on wxGTK; GTK allows the definition of key bindings 
on a theme file, which can be swapped in and out by the user at any 
time. If a key binding is defined for a control focused on a frame with 
a menu shortcut and conflicts with that shortcut then it will take 
precedence, as the key binding will be enforced while propagating the 
key press, preventing the menu shortcut from working.
So on wxGTK it becomes possible for a theme file to break menu shortcut 
handling.
I think this is unfortunate, but there is a workaround which does not 
imply handling key presses on the focused controls; there's already a 
wxAcceleratorTable class that can be used to define accelerators which 
will be enforced even before key bindings.
Since on my app I'll need to write additional code to generate and apply 
accelerator tables to support the menu shortcuts on wxGTK I'd like to 
know beforehand if there's any known issue with this class that may 
create further problems down the line.

P.S. I've also posted this query as a comment to issue 22625

-- 
Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.
--- 
You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/ba34b071-f334-cc56-b2d1-1a782877cda2%40gmail.com.