GNOME Bugzilla – Bug 135056
Alt-Tab doesn't work during drag-and-drop (nor does workspace switch, etc.)
Last modified: 2014-06-04 06:54:58 UTC
Alt-Tab functionality is not available while dragging a file from a nautilus window. My expectation is that I would be able to start a drag operation, bring the drop target window to the front using alt-tab, then drop the file into the target window. What actually happens is that during a drag operation metacity's window switcher dialog does not appear when alt-tab is pressed.
Similarly, you can't use a key combo to switch desktops.
I don't think that it's possible to fix this without some sort of really complicated window manager protocol, since in dnd the window has a grab.
I find myself dreading the use of drag and drop between windows because of these two issues. Personally I do not have a "Window List" utility on my only panel. Instead I prefer to use many workspaces to avoid minimising things, Alt+Tab to switch windows if they get covered and a nice small "Window Selector" utility for the rare minimised windows. Thus if I need to drag and drop between windows I think I need to first make sure that the windows are both on the same workspace and the target area needs to be visible even when the source window is on top. This normally means unmaximising and shuffling windows to prepare for a drag and drop operation. Alt-Tab would be useful as would handling drag and drop with the "Window Selector" in the same way as with the "Window List". I don't have enough hands to use Ctrl+Alt+{Up,Down,Left,Right} to switch workspaces while dragging but dragging onto the "Workspace Switcher" utility to cause a workspace switch would be great.
*** Bug 145329 has been marked as a duplicate of this bug. ***
*** Bug 325943 has been marked as a duplicate of this bug. ***
*** Bug 340792 has been marked as a duplicate of this bug. ***
Looking for that Alt+Tab switch while dragndrop in gnome @ least since 2.10. It's keeping me kind of unsatisfied with gnome while the other desktops (kde, osx, xp) support that semi-standard functionality. Ppl I showed linux with gnome as desktop (yes I do linux-promotion in my neighbourhood) are pretty quickly coming back to the point of asking why that function is not available. So as I know about the drag over windows list till window pops up, I tell them this as a workaround. But its not really the same handy and quick as a real Alt+Tab Window switch to bring the desired app to the foreground. Just wanted to point out that pretty old bug/missing feature, telling that there is quite some ppl looking out for it, on that great desktop.
*** Bug 343422 has been marked as a duplicate of this bug. ***
It Is wery usefull thing Is there any chance, that we will see this feature in nearest future?
*** Bug 373077 has been marked as a duplicate of this bug. ***
*** Bug 380783 has been marked as a duplicate of this bug. ***
See http://bugzilla.gnome.org/show_bug.cgi?id=390312 for gtk side of this problem. GTK grabs keyboard at the moment but that can be fixed. QT applications do not grab keyboard on DND right now if you need to test it without newest patched GTK.
I'd think gtk bug blocks fixing this one, not vice versa. Gtk could be fixed right now, without waiting for metacity.
I marked this as blocking another metacity bug, not the gtk bug. ;-)
Sorry, paranoia. For some reason I decided the email from bugzilla was about gtk bug.
*** Bug 476956 has been marked as a duplicate of this bug. ***
Is it possible to fix this now? Sorry for a lame question :) I'm just a gnome user.
*** Bug 525556 has been marked as a duplicate of this bug. ***
@thomas: i don't consider this as a 2.24 blocker, we have all survived this bug for the last years... feel free to set a target milestone instead.
I am quite fed up with this problem, and I doubt whether anybody is willing to fix this... dunno why... this does seem like a pretty big usability problem to me. I want to fix this. But the problem is I have no experience at all in any kind of open source project, let alone GNOME. But I know C, and some Python. No GUI programming experience. If you think that it is possible for me to fix this and if anyone is willing to volunteer to do some initial handholding, I can try to fix this thing. I can devote around 3-4 hours every Saturday for this purpose. If any of you is willing to help me, please let me know. This bug is bugging me for quite sometime now...
Santanu: It is actually on my priority list, but there's a lot of other things on the list above it. (There's basically just me and Elijah actively fixing Metacity at present, and Elijah's very busy on other projects too.) I would be delighted if you could do some work on this bug! I will try to put together a list of likely places that need investigating and append it here; most Saturdays I could spare the 3-4 hours to talk it over in real time, but we have house guests this weekend. What time zone are you in? In the meantime, take a look at the code overview and the other files in the "doc" directory, and get a feel for how the code is laid out. Some of those files may be a bit out of date, but they give the right sort of idea. Thanks again.
Thomas: Thanks for offering to help me with this. I would really like to help in any way possible to fix this bug. I am in India, so time zone is IST (+5:30hrs). I can start from next Saturday (19th April). For this purpose I have to come to the university on Saturday (since I have no net connectivity where I stay). I can be present for discussing with you anytime from 11:00am to 8:00pm IST. Please let me know if you can be online during any portion of this time. I don't know whether IRC chat would be possible (since we are behind proxy that blocks everything except http and https)... maybe gmail! Anyways, in the meantime, I will download the Metacity code and go through the relevant portions you mentioned.
That's wonderful (but don't come on this Saturday, the twelfth, if you want to talk to me, because we have house guests and I'll be busy all day). I am in Philadelphia at the moment, which is -5:00hrs. I am on gmail, yes: I'm marnanel @ gmail. I wish universities wouldn't block things like IRC :( I learned more from IRC when I was a student than from many of my classes.
Created attachment 109876 [details] [review] (trivial) patch for bug #135056 I am attaching my (trivial) patch for this bug. After applying this patch: 1. One can open two nautilus windows (probably in such a way that they completely cover each other), and then click on a selection in one of the windows and (without releasing the mouse button, and without starting a drag operation), use Alt+Tab to switch to the other nautilus window (or any other relevant window which can accept the selection) and then drag and drop it there. 2. If one is using any non gtk application, then one can start a drag operation in one window, use Alt+Tab to switch to a different window and drop it there. I have only tried it on two dolphin (the KDE file manager) windows on my system. (Using keyboard shortcuts to switch to a different workspace while dragging a selection on one window and then dropping the selection to another window on the other workspace has always been possible if the window concerned are not gtk based.)
Hm, I think it's an improvement, certainly. But what's stopping us grabbing during drag-and-drop operations with GTK apps that *isn't* with non-GTK apps?
Thurman: I believe this is somewhow related to the gtk bug #390312 (comment #12). I think that metacity is not getting any information about the keyboard events occuring within the frame where DND has been started. Anyway, I should not say much without proof. I will try to find that out using meta_warning in a few days and post here.
I did some work regarding the above (comment #26 ), but the details are a bit long. So, I posted them at http://paste.ubuntu.com/9691/ Do let me know if my method seems wrong. Also let me know if I should be posting such comments here in the future.
Can this be fixed in Gnome 2.22.x update or are we waiting for some new gnome release?
Santanu: I think it would have been quite appropriate to post that as a comment here. I'll save you posting it again: --------------- Since this post is going to be a bit long, I don't know whether I should be posting this as a bugzilla comment. So, I am pasting here. If you think I should be posting this as a comment at bugzilla, do let me know. Anyways, here goes... While trying to find out why during drag operations on GTK based apps all keyboard operations fail, I decided to follow two approaches, both using my patched (http://bugzilla.gnome.org/attachment.cgi?id=109876&action=view) version of metacity. Approach#1: =========== I modified the display.c file to put the following lines at the start of the event_callback function: --------------------- if (grab_op_is_keyboard(display->grab_op)) { meta_warning("SANTANU: KEYBOARD OPERATION RECEIVED\n"); } --------------------- Then I compiled and started this version of metacity. After that I started a nautilus window (a GTK based app), and a dolphin window (representing a non-GTK app). Then after starting a drag operation on a selection inside the nautilus window, I pressed Alt+Tab. No output from the meta_warning line. From this I conclude (correctly?) that metacity is not getting that event information. Next I did the same thing inside the dolphin window, and once I pressed Alt+Tab while dragging, I got a number of meta_warning messages from my introduced line. My conclusion: In case of GTK apps, metacity is not getting any keyboard events while dragging inside a GTK app. Approach#2: =========== I started a nautilus window, collected its window id using xwininfo, and started xev to monitor this window. I noticed that As soon as I start a drag operation on a selection, I get a FocusOut event, and no event information (even if I drag the selection to a different window, I don't get a LeaveNotify event) via any keyboard combinations like Alt+Tab until I end the drag operation, when I get a FocusIn event information (probably bacause I ended the operation in the same window where I started it). When I do the same in a dolphin window, while starting a drag operation, I do not get any FocusOut event. And while the drag operation is in progress, if I press any key (not even a combination such as ALt+Tab), I get this type of information from xev: -------------------- PropertyNotify event, serial 16, synthetic NO, window 0xa00007, atom 0xfb (_NET_WM_USER_TIME), time 2553106035, state PropertyNewValue -------------------- I get the FocusOut event only when I use something like Alt+Tab that causes the focus to shift to a different entity on the display. My Conclusion: Same as above (in Approach#1). Something is probably wrong in GTK's implementation of DND for which metacity, compiz, xfwm, etc. are having this unexpected DND/Alt+Tab behavior. But this is just my inexperienced conclusion. Please let me know if there is something wrong with my approach. I am not not even sure at this moment what exactly is meant by things like PropertyNotify event, but I can somewhat guess what FocusOut event means.
Thomas: Thanks.
The patch here doesn't look OK to me; if you pop up alt+tab without a grab, there's no guarantee afaik you'll ever get any of the events that pop it down again. So the alt+tab mode can get "stuck" There's a reason for the grabbing, it isn't just there for no reason ;-)
Created attachment 136114 [details] [review] allow keyboard ops to work without a pointer grab
Here is a minimally-invasive patch that makes dnd and workspace-switching / focus-cycling work together. It still tries to get a pointer grab, but allows keyboard ops to proceed without one. This has been tested to work with a corresponding change to make GTK+ use passive key grabs for its keynav needs during dnd.
Matthias: I'm trying to test this patch. Is it supposed to make alt-tab work during drag-and-drop? It doesn't seem to.
Yes, it works here. Start a drag, press alt-tab to bring the window up front that you want to drop in, then drop. You need GTK+ 2.17.2 at least, I guess.
Ping. If this patch works and has been reviewed, couldn't it be merged to master and stable?
We are shipping it in Fedora and it works fine as far as I can tell.
This has also been reported on Launchpad in Ubuntu at <https://launchpad.net/bugs/488139>. What are the thoughts of the maintainers on the patch that Fedora is shipping?
I can confirm that this patch works great. The only small thing that might me considered is that the drag'n'drop process will think that you are holding down [ALT] if you don't move the pointer after you have switched windows with [ALT] + [TAB] (Yes, I released both keys).
Created attachment 197940 [details] [review] Allow keyboard ops to work without a pointer grab
Comment on attachment 197940 [details] [review] Allow keyboard ops to work without a pointer grab Wrong bug.
So, we're talking about a 8 year old bug here... In plus, the bug has a patch attached (for more than 3 years) The patch is shipped by major distros: - Fedora - openSUSE - Ubuntu Wouldn't it be time to just merge the patch then, and allow downstreams to drop it in their packages?
This patch is included[1] in mutter (the successor of metacity), I tried it on fedora 19 and it's working fine (I dragged text from gedit to nautilus via ALT+TAB). So it would be cool if someone could commit it to metacity as well to close this bug. [1] https://git.gnome.org/browse/mutter/tree/src/core/display.c#n4138
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.