gtk3: New Folder dialog from Templates dialog doesn't get keyboard focus

ctrl+shift+N, and click new folder, no keyboard input is accepted.

The dialogs don't get keyboard events, because the keyboard events
go to the top level window because of...

commit 011ce226e89ecabaf621603d692547c88061eaba
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Tue Jan 19 13:22:10 2016 +0000

Resolves: tdf#99604 ungrab modal dialogs

(should be tdf#96604) which stripped away the grab from the sub dialog

but I did that because menu dropdowns from comboboxes inside modal
dialogs didn't receive mouse focus otherwise.

I had set our "modal" dialogs to be truly modal and triggering that
problem with

commit 8d5822983e9b6a1e04874ce4d2c807fd0cf1ee04
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Mon Dec 14 11:36:50 2015 +0000

Related: rhbz#1290014 gtk3: use gtk_window_set_modal on modal dialogs

which makes modal dialogs (which are most of them) place correctly
under wayland. Modeless ones are still uselessly shoved far to the
left, but this makes things near usable and gives the same "graying
into the bg" effect for the main window as other gtk apps

which I still contend is "a good thing"

if we stop removing the grab from the modal dialog, then we need to grab
the keyboard and mouse on to the menu on showing those. This then runs
into the problem that sometimes we want the keyboard to go to one window
and the mouse to go to another, i.e. mouse to the floating menu and the
keypresses to its parent combobox.

Which was the joy of...

commit 27e0fee7da99f3df722668d132bc034bef421514
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Fri Mar 27 15:28:28 2015 +0000

gnome#745909 grab/ungrab keyboard for menus

and subsequent fix of

commit 57ec66e294b1405a85029aa1f1c0e9485ad4e5b4
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Thu Jul 23 09:55:01 2015 +0100

Resolves: tdf#92689 grab keyboard focus to parent, not to earlier generations

so...

lets drop the ungrab on modal dialog attempt and leave that alone. That means
that the keyboard focus travels around the modal dialogs stack correctly.

For the mouse and keyboard events in menu problems, instead gtk_grab_add on the
menu itself, and convert the separate grab of keyboard and mouse to different
places with a single grab of everything to the menu, and in the keyInput of
such menus where the keyInput would have gone to their parent in the past,
forward it on ourselves directly.

Using the gtk_grab_add makes the bOwnerEvents mode of mouse grabbing not work
correctly anymore. So throw my hat at it, and instead use the simpler mouse
grabbing where all events go to the menu, and doesn't send the events outside
of it to the parent, the side effect is that now clicking outside the menu
doesn't make it go away automatically because its the parent window which used
to do that.

So instead of dismissing the menu within the gtk plugin when the button click
is outside the application, take it onto ourselves to dismiss the menu when the
button click is outside the menu.

and ditch some metacity hack around thing at this point too

I hate this crap

Change-Id: If10e758585f156b33680b8d40355302cc1ae72f3

1 files changed, 1 insertions, 0 deletions

diff --git a/vcl/inc/unx/gtk/gtkframe.hxx b/vcl/inc/unx/gtk/gtkframe.hxx
index 3610addde351..f033efff2506 100644
--- a/vcl/inc/unx/gtk/gtkframe.hxx
+++ b/vcl/inc/unx/gtk/gtkframe.hxx
@@ -271,6 +271,7 @@ class GtkSalFrame : public SalFrame
     static void         gestureSwipe(GtkGestureSwipe* gesture, gdouble velocity_x, gdouble velocity_y, gpointer frame);
     static void         gestureLongPress(GtkGestureLongPress* gesture, gpointer frame);
 #endif
+           gboolean     handleKey(GtkWidget* pWidget, GdkEventKey* pEvent);
 #else
     static gboolean     signalExpose( GtkWidget*, GdkEventExpose*, gpointer );
 #endif