GNOME Bugzilla – Bug 660457
Allow Alt+Tab during Drag and Drop
Last modified: 2012-01-24 15:09:42 UTC
In GNOME 3 there is no taskbar, so drag and drop functionality between windows works only when you see both of them one next to another, there is no DnD to the window icon on the taskbar to bring that window in focus. Therefore, DnD should be able to interact with alt+tab... When we mouse-down an item and activate alt+tab window manager, mouse-over on an item in alt+tab window manager could get that window in focus (not bad at all?) so that when we mouse-up the key (with/without alt still pressed) , dragged item could be dropped into that window (with alt - default drop / without alt still pressed - onto exact drop location in that window). I think this could be done, and I hope you can see all the benefits from it... :)
(In reply to comment #0) > In GNOME 3 there is no taskbar, so drag and drop functionality between windows > works only when you see both of them one next to another, there is no DnD to > the window icon on the taskbar to bring that window in focus. Not true you can DND using the overview: 1) Drag to the hot corner 2) Hover over the window you want to drop to 3) The window will be activated 4) Drop
Hmmm... Great, I didn't know that... Anyway, my suggestion could be handy also... There are some patches that enable this in other desktop environments, while some have it by default...
Is this because mutter insists on getting a pointer grab for alt-tab ? I think I filed a patch for that long ago, never applied...
(In reply to comment #3) > Is this because mutter insists on getting a pointer grab for alt-tab ? Yes. > I think I filed a patch for that long ago, never applied... Never saw it ...
(In reply to comment #4) > (In reply to comment #3) > > Is this because mutter insists on getting a pointer grab for alt-tab ? > > Yes. > > > I think I filed a patch for that long ago, never applied... > > Never saw it ... bug 135056
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Is this because mutter insists on getting a pointer grab for alt-tab ? > > > > Yes. > > > > > I think I filed a patch for that long ago, never applied... > > > > Never saw it ... > > bug 135056 OK, this is not enough though. The shell does it's own grab when showing the altTab dialog but that's fixable.
Created attachment 197941 [details] [review] altTab: Don't refuse to work when a pointer grab is in place Allow push_modal to optionally only work with a keyboard only grab and use that in altTab as a fallback to allow switching windows while a pointer grab is in effect (like during DND operations).
Created attachment 197942 [details] [review] Allow keyboard ops to work without a pointer grab
Hmm this seems to only work with GTK2 apps like firefox. Matthias did anything in gtk3 change to make it conflict with that?
ah yes: grep for XINPUT2 in gtkdnd.c
*** Bug 660920 has been marked as a duplicate of this bug. ***
*** Bug 647109 has been marked as a duplicate of this bug. ***
*** Bug 621679 has been marked as a duplicate of this bug. ***
OK, this is for another topic, but I thought I could post it here... If someone thinks this should be in separate topic feel free to paste it... Window manager just crashed when I tried to extract from Archive Manager DND way to the hot corner, to another workspace and during getting window (file manager) focused due to holding pointer over it everything crashed. Title bars gone missing, upper bar also, all windows got restored on that workspace and I could get focus to them by clicking on them but their arrangement couldn't be changed. Alt+F2 didn't work (not even invisibly) so I decided to reboot.
(In reply to comment #14) > OK, this is for another topic, but I thought I could post it here... If someone > thinks this should be in separate topic feel free to paste it... > Window manager just crashed when I tried to extract from Archive Manager DND > way to the hot corner, to another workspace and during getting window (file > manager) focused due to holding pointer over it everything crashed. Title bars > gone missing, upper bar also, all windows got restored on that workspace and I > could get focus to them by clicking on them but their arrangement couldn't be > changed. Alt+F2 didn't work (not even invisibly) so I decided to reboot. This is a different bug, please file it and attach a backtrace of the crash.
Review of attachment 197941 [details] [review]: One suggestion and a couple of style nits, but looking good otherwise. I fear that the problem with Xinput2 is not fixable until mutter itself is ported to Xinput2 (just a hunch, feel free to prove me wrong); work for that is underway in the wip/xinput2 branch, but I don't know how "wip" it is ... ::: js/ui/main.js @@ +672,3 @@ * + * @keyboard_only is optionally used to initiate a keyboard grab but + * without grabbing the pointer. Should be keyboardOnly according to our style. But to be honest, boolean parameters are rather hard to read anyway, so I suggest using modalOptions instead: Main.pushModal(actor, global.get_current_time(), Meta.ModalOptions.POINTER_ALREADY_GRABBED); is much clearer than Main.pushModal(actor, global.get_current_time(), true); @@ +682,2 @@ if (modalCount == 0) { + if (!global.begin_modal(timestamp, keyboard_only != undefined && keyboard_only)) { Uhm - why the check for undefined? ::: src/shell-global.c @@ +871,3 @@ { + return meta_plugin_begin_modal (global->plugin, global->stage_xwindow, None, + keyboard_only ? META_MODAL_POINTER_ALREADY_GRABBED : None, Don't rely on None == 0 ::: src/shell-global.h @@ +41,3 @@ gboolean shell_global_begin_modal (ShellGlobal *global, + guint32 timestamp, + gboolean keyboard_only); Misaligned parameter name
Review of attachment 197942 [details] [review]: LGTM
(In reply to comment #16) > Review of attachment 197941 [details] [review]: > > One suggestion and a couple of style nits, but looking good otherwise. > > I fear that the problem with Xinput2 is not fixable until mutter itself is > ported to Xinput2 (just a hunch, feel free to prove me wrong); work for that is > underway in the wip/xinput2 branch, but I don't know how "wip" it is ... Discussion on IRC indicated that it is fixable in gtk itself but have not really looked into it. > ::: js/ui/main.js > @@ +672,3 @@ > * > + * @keyboard_only is optionally used to initiate a keyboard grab but > + * without grabbing the pointer. > > Should be keyboardOnly according to our style. But to be honest, boolean > parameters are rather hard to read anyway, so I suggest using modalOptions > instead: > > Main.pushModal(actor, global.get_current_time(), > Meta.ModalOptions.POINTER_ALREADY_GRABBED); > > is much clearer than > > Main.pushModal(actor, global.get_current_time(), true); OK, makes sense. > @@ +682,2 @@ > if (modalCount == 0) { > + if (!global.begin_modal(timestamp, keyboard_only != undefined && > keyboard_only)) { > > Uhm - why the check for undefined? To make it optional, could just really on the fact that undefined and false are "almost" the same I guess ... > ::: src/shell-global.c > @@ +871,3 @@ > { > + return meta_plugin_begin_modal (global->plugin, global->stage_xwindow, None, > + keyboard_only ? > META_MODAL_POINTER_ALREADY_GRABBED : None, > > Don't rely on None == 0 Oh ... wasn't intentional.
Comment on attachment 197942 [details] [review] Allow keyboard ops to work without a pointer grab Pushed as 9d4f3c5842
Created attachment 199590 [details] [review] altTab: Don't refuse to work when a pointer grab is in place Allow push_modal to optionally only work with a keyboard only grab and use that in altTab as a fallback to allow switching windows while a pointer grab is in effect (like during DND operations).
Review of attachment 199590 [details] [review]: Looks good. ::: js/ui/main.js @@ +672,3 @@ * + * @options is optional parameter that can be used to to indicate that + * the pointer is already grabbed by passing in a Meta.ModalOptions Reads a bit funny. How about @options: optional Meta.ModalOptions flags to indicate that the pointer is alrady grabbed
Attachment 199590 [details] pushed as f4d8a35 - altTab: Don't refuse to work when a pointer grab is in place
*** Bug 668581 has been marked as a duplicate of this bug. ***