summaryrefslogtreecommitdiff
path: root/jurt/com/sun/star/lib/uno/environments/remote/IThreadPool.java
diff options
context:
space:
mode:
authorCaolán McNamara <caolanm@redhat.com>2016-05-04 16:29:35 +0100
committerCaolán McNamara <caolanm@redhat.com>2016-05-05 11:04:54 +0100
commit72e6a1365cb08986b542a5beb797634bca62d85b (patch)
tree51180195474cb1712672d4a9d060a41b2a11bfe2 /jurt/com/sun/star/lib/uno/environments/remote/IThreadPool.java
parent92f9ac2e2bee7021101e7a9fb2d5d7bfbc03fb48 (diff)
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
Diffstat (limited to 'jurt/com/sun/star/lib/uno/environments/remote/IThreadPool.java')
0 files changed, 0 insertions, 0 deletions