Created attachment 78981 [details] [review]
patch

Don't call gdk_keyboard_grab(), but still send key events to DND widget as if it had keyboard grab.

Does this still allow you to cancel drags with Esc and to move the pointer using
arrow keys ?

To answer my own question, it will only if the drag source has the keyboard focus,
which is often the case, but not always. E.g with the patch, it will not be possible to cancel the drag of a launcher from the panel, since the panel does not (normally) take focus. 

I see. How about checking if the process has focus at the moment and grabbing keyboard if it doesn't? For "normal" cases when you do want Alt-Tab (e.g. drag from text widgets or from nautilus), the clicked window will focus first so it will work fine. Can't imagine what it will do in focus-on-hover mode.
Maybe get X focus and release it back in the end of drag?
It is a good thing to be able to do Alt-Tab during drag, with small monitor adn maximized windows it's really nice...

It technically works, but it still opens up wierd corner cases. E.g. you can press
Alt-F2 during the drag, causing the run dialog to pop up and steal focus from the drag source. Then you can happily use the keyboard to interact with the run dialog while the drag is still in progress.

(In reply to comment #5)
> It technically works, but it still opens up wierd corner cases. E.g. you can
> press
> Alt-F2 during the drag, causing the run dialog to pop up and steal focus from
> the drag source. Then you can happily use the keyboard to interact with the run
> dialog while the drag is still in progress.
> 

I'd say it's a feature, if you are able to do that - you drag, launch something and paste. Funny, but why not? This particular thing with Alt-F2 is not something "bad", i.e. it doesn't prevent user from doing usual DND, and it's not something user will see anyway. I think Alt-Tab + DND and ability to do funny things like this is better than no Alt-Tab + DND.

I played with this, and: making keyboard_grab() conditionally sucks - it feels really weird that you can do Alt-Tab in some cases and can't in other. Then, focus-under-mouse is not a problem because pointer is grabbed (at least kwin is clever enough not to switch focus). But, I can't make ipc_widget thing actually grab focus, is GtkInvisible not capable of having input focus?

What might work better is to use passive grabs, ie. call XGrabKey for the few keys that we want to handle during DND.

But the whole thing doesn't work too well with metacity anyway: 
Alt-Tab doesn't work during DND, neither does Ctrl-Alt-Left/Right (Switch Workspace), but Shift-Ctrl-Alt-Left/Right (Move to Workspace) does.

Created attachment 79255 [details] [review]
patch

Here's a patch using XGrabKey on X. Other platforms use keyboard_grab() since keyboard is never really grabbed there anyway (and on Win32 even DND isn't really working, dunno about Mac). The patch is ugly, but I didn't want to write some _gdk_x11_grab_key() because it would need to keep track of grabs then; it's much easier to call XGrabKey and XUngrabKey in one place. Maybe a general purpose gdk_grab_key() makes sense, dunno.

(In reply to comment #8)
> What might work better is to use passive grabs, ie. call XGrabKey for the few
> keys that we want to handle during DND.
> 
> But the whole thing doesn't work too well with metacity anyway: 
> Alt-Tab doesn't work during DND, neither does Ctrl-Alt-Left/Right (Switch
> Workspace), but Shift-Ctrl-Alt-Left/Right (Move to Workspace) does.
 
This is just plain metacity bug, I think. It can be fixed probably, but there's no point in fixing it if gtk grabs keyboard (unless one wants to make metacity kde-application-friendly). Besides, from what I heard on IRC it seems metacity broke Alt-Tab when dragging windows too, so it may be just a usual bug not related to DND at all (namely to what gtk does with keyboard on DND).

Can you file a metacity bug about that, and make this bug depend on it ?

It's http://bugzilla.gnome.org/show_bug.cgi?id=135056 . I don't see how this bug depends on that though, say I am not using metacity at all but still have the problem.

If anything, it'll remind me that I can't test this patch with metacity until the metacity bug is fixed

(In reply to comment #13)
> If anything, it'll remind me that I can't test this patch with metacity until
> the metacity bug is fixed

Does this mean that this is not going to be fixed until metacity bugis fixed? You can test the patch right now using another window manager. And I guess the metacity bug is not of top priority since GTK doesn't support Alt-Tab with DND.

The metacity bug you have noticed is probably that metacity tries to grab both the pointer and the keyboard for many of its operations even if there's no real reason it needs both.  Metacity aborts the operation (e.g. alt-tab) if it is unable to obtain either grab.  The relevant function is metacity/src/display.c:meta_display_begin_grab_op (and all places that call this function; stroll on over to metacity/src/common.h:MetaGrabOp for a quick summary of affected operations).

*** Bug 514790 has been marked as a duplicate of this bug. ***

I said this already on the metacity bug, but since we were just discussing this on IRC; I don't think anyone has proposed a metacity fix that isn't broken. Metacity needs a grab or the alt+tab popup would potentially get stuck. It doesn't work to just not grab.

Maybe there is some more complex fix, but I don't know. Nobody has proposed one over on the metacity bug afaics.

Owen speculated on IRC that GTK could XGrabKey() instead of grabbing, and perhaps metacity could do the same, I'm not sure. The metacity behavior would at least change because right now pressing any key or clicking the mouse kills the alt-tab.

There is a patch further up to make gtk use passive grabs. 
Alt-Tab still won't work because metacity also tries to grab the pointer...

There are other window managers than metacity...

I've committed a working version of your patch. 
Corresponding metacity patch attached to the metacity bug.