GNOME Bugzilla – Bug 338660
Alt Tab/F6/Esc fixups
Last modified: 2020-11-06 20:06:59 UTC
I'm going to use this bug to consolidate some remaining issues in bug 94682, and some related issues from bug 309481 and bug 311513, plus maybe a note or two of my own. Now, in bug 94682 a way was added to switch between windows of a single application (bound to Alt+F6) by default. This provides a way to keynav to windows that were inaccessible since the change in bug 106249 (which inaccessibility was filed as bug 311513). Remaining issues: (1) Alt+F6 isn't all that discoverable currently (alt-tab isn't either but it's much more well known) (2) Having to start one window switch operation, then end it, then switch to another is kind of annoying. Would be nicer to be able to e.g. Alt-Tab-Tab-F6-F6-F6 to get to the window you want. (3) Alt-tab doesn't switch between most recently used windows as expected (bug 309481) (4) Given that Alt+F6 currently cancels an Alt+Esc operation (see bug 94682 comment 32), it should also return the window to its original stacking order just like other ways of cancelling Alt+Esc operations. So, what I'd like to do: - Allow mixing either tab or esc (but not both) with F6 without cancelling the window switch operation, much like how Ray made it possible to change the keyboard resize grab_op type in bug 310888 (see process_keyboard_resize_grab_op_change()) [should fix #2 & #4] - When alt-tabbing (or alt-escing) select the most recently used window from the given application instead of always choosing the "main" window. [should fix #3] - Show a little "Press F6 to access other windows of this application" hint in the alt-tab popup or something similar when alt-tabbing. [should fix #1] Anyone see any problems with that?
*** Bug 311513 has been marked as a duplicate of this bug. ***
*** Bug 309481 has been marked as a duplicate of this bug. ***
Alt+F6? I guess that might be good for those who know about it, but I don't think it should be seen as a solution for any accessibility problem, because (a) most people won't know about it (even if it was mentioned in the help, which it isn't), and (b) it's unreachable. (I can't even reach Alt+F4 without crazy wrist-twisting, let alone Alt+F6.) I think people will try Alt+Tab, encounter bug 305259, think "huh, I can't tab to dialogs, that sucks", and give up. This seems to be the most urgent problem: Alt+Tab must tab to dialogs, and if that's not part of this bug then bug 305259 should be reopened. As for Alt+Esc, I'm not sure what it's supposed to do (it's not mentioned in the help either); in Ubuntu Dapper at least, it seems to behave identically to Alt+Tab. (I was thinking Alt+Esc would be a potential candidate for a universal "Close Window" keybinding, avoiding the problems of Ctrl+W being for deleting words and Alt+F4 being unreachable.) In the long run, I think there are too many flags that programs can set, which makes it impossible for Metacity to make windows accessible in a predictable way, and impossible for people to understand how a window will behave just by looking at it. I think this can be fixed by adding a couple of missing types to _NET_WM_WINDOW_TYPE, then ignoring _NET_WM_STATE_MODAL, _NET_WM_STATE_SKIP_TASKBAR, and _NET_WM_STATE_SKIP_PAGER as being redundant complications of _NET_WM_WINDOW_TYPE. But I guess that's out of scope here.
(In reply to comment #3) > This seems to be the most urgent problem: Alt+Tab must tab to dialogs, and > if that's not part of this bug then bug 305259 should be reopened. Yes, that's part of the bug; you might have missed it in my original explanation, so let me go into more detail. It might be different than you expect, so I'll make the explanation a little bit longer by including some rationale... First, the related background rationale: Dialogs are kept stacked above their parent window. Everyone seems to like this behavior. We also center the dialogs over their parent (if the toolkit doesn't already do so, though I suspect all of them do). Everyone seems to think this is correct behavior. But these two things mean that while the dialog is showing, it is difficult to work with the main window unless one manually moves either it or the dialog to a separate location. (Users could work with the main window while it is obscured, but it seems that very few would want to given that we raise windows on click as a side effect specifically because most users (the unwashed masses...) find it unintuitive to work with a window which is partially obscured). These three effects (dialogs always stacked above parent, dialogs centered over parent when placed, users don't like working with partially occluded windows) lead me to a third assumption: in most cases, we do users an injustice by having alt-tab go to the main window. It should go to the dialog instead. In most all cases the user will dismiss the dialog before trying to interact with the main window again. (In reply to comment #3) > Alt+F6? ... (a) most people won't know about it (even if it was mentioned in > the help, which it isn't) Partially covered in the original comment of the bug report, but that's just the lesser of two issues here. The deeper one is that Alt+F6 is currently needed to accomplish commonly wanted behavior, which I think is bad. > (b) it's unreachable. (I can't even reach Alt+F4 without crazy > wrist-twisting, let alone Alt+F6.) Alt+F7 for moving a window must be even worse. Let's nuke it! ;-) More seriously, I don't think Alt+F6 should be a commonly required operation -- it should only be used e.g. for switching _from_ a dialog to its obscured main window. > As for Alt+Esc, I'm not sure what it's supposed to do (it's not mentioned in > the help either); in Ubuntu Dapper at least, it seems to behave identically > to Alt+Tab. You don't have any windows overlapping?
Agreed on stacking and centering dialogs above their parent. > But these two things mean that while the dialog is showing, it is > difficult to work with the main window unless one manually moves either it > or the dialog to a separate location. This is part of why I have never (well, not since about 1999) believed there should be such a thing as a non-modal dialog. Either a window is an alert or dialog, in which case it should float on top and block its parent; or it's not, in which case it shouldn't float on top (palettes and bubbles excepted) and shouldn't block its parent. This is how Windows and Mac OS work (most obviously in Mac OS X's sheets). Sure, make a dialog's parent movable and resizable; but that's a luxury, not an accessible-at-all-costs requirement. > in most cases, we do users an injustice by having alt-tab go to the main > window. It should go to the dialog instead. That would be fine given the above, but the current behavior appears to be the opposite. I can Alt+Tab to the main window, but never to the dialog. > Alt+F7 for moving a window must be even worse. Let's nuke it! ;-) Actually, yes. Alt+Space M is quicker, no matter which hand/hands I'm using. > You don't have any windows overlapping? Yes, and now I've found a single difference. Alt+Esc temporarily unminimizes a minimized window when I cycle to it; Alt+Tab does not. But the window cycle order, and the end result, seem to be identical. Any more clues? :-)
(In reply to comment #5) > That would be fine given the above, but the current behavior appears to be > the opposite. I can Alt+Tab to the main window, but never to the dialog. Right, the fact that current behavior is wrong is a good reason to have a bug open. Like this one. ;-) > > Alt+F7 for moving a window must be even worse. Let's nuke it! ;-) > Actually, yes. Alt+Space M is quicker, no matter which hand/hands I'm using. Touché. However, IIRC, this keybinding is there for CUA compliance. > Yes, and now I've found a single difference. Alt+Esc temporarily unminimizes > a minimized window when I cycle to it; Alt+Tab does not. But the window cycle > order, and the end result, seem to be identical. Any more clues? :-) Just the previous one: make your windows overlap. But yeah, it's only different in the case of overlapping or minimized windows. They used to have other differences but now that I think about it, I believe this was merely because they were two different workarounds to a bug ("If we raise the window immediately then the stacking order gets messed up!" vs "I want to see the window I'm switching to!"). Now that we do the intelligent thing of undoing the raising/minimization once the user moves to a different window, I don't see the point in the Alt+Tab behavior anymore. I should probably just make it do what Alt+Esc does.
Created attachment 69005 [details] [review] You can start using alt-f6 after alt-Tab without letting go of alt (In reply to comment #0) > - Allow mixing either tab or esc (but not both) with F6 without cancelling > the window switch operation, much like how Ray made it possible to change > the keyboard resize grab_op type in bug 310888 (see > process_keyboard_resize_grab_op_change()) [should fix #2 & #4] This is a first attempt at doing this. The trouble is that alt-f6 is currently defined to mean "cycle through all the windows in the same group as window N", where window N is always the window that has focus. Here I introduce the concept of a richochet_window that can be used to specify a window to use as window N, and if left NULL will default to the window that has focus.
Oh, and I restricted this to letting users switch from alt-Esc or alt-Tab to alt-f6. Switching from alt-Tab to alt-Esc, etc., is still a cancel.
*** Bug 352213 has been marked as a duplicate of this bug. ***
Sorry for sucking on patch review. I seem to say that a lot, I know... The patch is built on the premise of ending the grab op and starting a new one when the user presses Alt+F6. Besides the fact that this introduces a race condition that I'd prefer not to have, I'd really prefer a structure similar to how Ray changes grab-op types in his patch in bug 310888 without ending and restarting the grab.
*** Bug 358072 has been marked as a duplicate of this bug. ***
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.