GNOME Bugzilla – Bug 123576
Alt+Esc+any leaves raised unfocused window on top
Last modified: 2005-01-24 06:08:05 UTC
I wasn't sure this was a bug at first. If while traversing windows with Alt held and repeated Escapes another key or a mouse button is pressed, then the traversal mode ends, raised windows stay raised, and focus stays where it was before the mode. So the unfocused windows are on top. If one of the left-on-top-unfocused windows is maximized, it completely obscures the focused window. Maybe any key other than Shift, Alt, and Esc should end the mode leaving stacking as it was before Alt+Esc was pressed? Leaving the stacking as altered on when Alt is released seems ok. Ctrl+Alt+Esc probably has the same problem. Alt+Tab and Ctrl+Alt+Tab just cancel the traversal when another key or a mouse button is pressed. Since nothing was raised, nothing changes.
Created attachment 35157 [details] [review] Revert to original stacking when cancelling an alt-esc operation This patch saves the stacking at the beginning of an alt-esc or alt-tab operation (it has to do both because we allow users to switch part way through an operation, e.g. alt-tab-tab-esc-tab), and then restores it if the operation is aborted via extraneous keypress or a buttonpress.
I normally wouldn't ping this soon, but you've responded to several other patches and comments that I submitted or added after this one...did the mail for this new patch fall through the cracks?
Comment on attachment 35157 [details] [review] Revert to original stacking when cancelling an alt-esc operation only gcc/c99 allow code before variable decls: + meta_topic (META_DEBUG_WINDOW_OPS, + "Syncing to old stack positions.\n"); + MetaScreen * screen; A macro for the "grab_op == one of four window traversal things" wouldn't hurt (I think we have a similar IS_KEYBOARD macro iirc) Be sure we free grab_old_window_stacking on display close (not sure there's an end_grab in that case - maybe there should be) this is strange: g_list_length (windows) != g_list_length (stack->sorted); ;-) What happens if windows are created/destroyed during the grab?
Created attachment 36405 [details] [review] Fixed up patch The g_list_length (windows) != g_list_length (stack->sorted); was supposed to be if (g_list_length (windows) != g_list_length (stack->sorted)) return; but I somehow botched it. I thought it'd be good to do a simple sanity check before attempting to change the stacking list, despite the fact that I didn't think they could really change. However, if they could, then we would be confronted with the fact that lists having the same length doesn't really mean the windows they contain are the same. So, just to cover the bases, I wrote a simple function in this new version to do the real full comparison. And, of course, I fixed up the other problems you pointed out as well.
I would key g_list_free (display->grab_old_window_stacking) off of whether the list was non-NULL, rather than the grab_op type. That way you can't get a certain class of bug (out-of-sync grab_op that create and free this) + while (tmp1 && tmp1->data == tmp2->data) { + if (!lists_contain_same_windows (windows, stack->sorted)) { brace on its own line ;-) don't get all Java on me.
Created attachment 36417 [details] [review] Key off display->grab_old_window_stacking being non-NULL, fix style Sorry about that--I keep switching projects I'm working on and occasionally forget to switch back to the style for the given project. I was thinking about bug 150910 (gnome-desktop, related to focus stealing prevention, and which I'm having a hard time cornering Mark into reviewing) for which I need braces on the same line, at about the same time as I was writing this patch up....
Comment on attachment 36417 [details] [review] Key off display->grab_old_window_stacking being non-NULL, fix style no problem, thanks
Heh, what timing... I had just barely typed the following: Since the last two changes you suggested were only minor, I went ahead and committed the fixed version so that it could be part of the tarball that's due soon. Kick me if I shouldn't have done that..especially if you want me to revert and/or re-release a tarball without this patch. Well, anyway, fixed now. :) [But you can still kick me if I was wrong to go ahead without waiting]