On 11/11/05, Bill Haneman <Bill.Haneman@xxxxxxx> wrote: > Elijah Newren wrote: > >It's the designated no-focus-window (a window created by Metacity that > >the user never sees but is around to ensure that global keybindings > >work...). That window can also get focused when certain bugs (e.g. > >X11's utterly stupid RevertTo behavior) are worked around. > > > I think that the presence of an invisible no-focus window may be an > accessibility violation (i.e. may violate '508' paragraph 1194.21c). We > might have to go to the explanatory "guidance" documents to be sure; > basically a "well-defined, onscreen indication" of focus must always be > present. Now, if there IS no focus, is the absence of a well-defined > onscreen indication a bug? Perhaps the absence of focus is itself a > violation, the correct interpretation is not immediately apparent. Okay, but that doesn't really help with the should-we-focus-the-desktop-or-not question. There is no real way to indicate that the desktop window has focus. Unless a "normal" window (e.g. not a panel and not the desktop) exists, there is no way to really comply with that requirement currently. So this seems to merely point at a deeper problem somewhere. Further, it sounds like we may have to special case accessibility, because the no-focus-window is the only thing that makes any usability sense in certain cases. You claim that sloppy and mouse focus are "broken by consensus" (of which I'm not a part, though I do understand that they lead to difficult design decisions which make click-to-focus a fairly obvious choice of default for users), so I'll just point out the one case in click-to-focus where this is true. It's possible this case isn't relevant to accessibility, though I don't see why it wouldn't be, but if so it just means we need to special case things. Anyway the case: If a modal dialog to an app which has focus appears and the author explicitly requests that the modal dialog not get focus when it is launched, then the only sane choice for focus is the no-focus-window. Leaving the window that had focus with focus would be horribly misleading because the app will ignore keyboard input to that window. Focusing the modal dialog would be wrong because it is an unexpected popup and the user could accidentally dismiss the important warning/error it contains--or even worse, select an inappropriate action that they didn't want merely because they happened to be typing at the time when the window appeared. Focusing a different window on the screen would likewise be wrong because user keystrokes shouldn't be transferred to some other random application just because of the appearance of an unexpected modal dialog. By deduction the correct thing usability wise in this case is for "nothing" to have focus but to allow global keybindings (such as alt-tab) to work. > My view/guess is that there should always be some keyboard focus (i.e. > the 'no focus' case should not be allowed), and therefore some onscreen > indication must always be provided. The problem with the status quo is > that the case of "no onscreen object is focussed" is not distinguishable > to the end user from the case of "onscreen focus is not correctly > indicated". Yes, and because they aren't distinguishable, this should not be used as rationale for setting focus on the desktop or the panel because that wouldn't solve this particular problem at all. This problem is deeper as we also can't currently comply with it when the user manually focuses a panel or "desktop" window. We'd need to figure out how to fix those first. > I understand the consistency problems with focussing the desktop by > default, but then again sloppy focus is broken anyway by consensus > (doesn't mean it's wrong to use it :-) ). I, too, would expect that the > desktop would get focus if all windows were de-focussed/closed, because > indeed the desktop window DOES have special semantics from the end user > point of view. I think that focussing the DESKTOP-type window in the > absence of other focus, as the last case in the else (if you will) is a > reasonable behavior, and I don't think the consistency issues with > sloppy focus are actually that problematic (i.e. "focus-follows-mouse > only applies to 'regular' windows" seems like a sane policy) It's possible you have a complete picture of what should happen in all cases so that we don't end up with strange inconsistencies, but I don't see what that picture is. You'll need to read through http://cvs.gnome.org/viewcvs/metacity/doc/how-to-get-focus-right.txt?view=markup and tell me what you think needs to be tweaked, how it needs to be tweaked, and why. In particular, let me point out the following in regards to sloppy focus: - sloppy focus means focus the window when the mouse enters (unless there is an active grab such as the case of a menu in an app being open...) Now, think about what happens when you switch desktops. What window should gain focus? The window under the mouse, right? Now, what about when you close a window? Which window should get focus? The one under the mouse, right? At one time, both of the above questions were done incorrectly in Metacity (the window on top was given focus). The "obvious" answers, however, introduced new bugs, such as bug 133120. ("User opens a window--the only one on that workspace--then moves the mouse out of it. The window still has focus in sloppy focus mode. User switches workspaces, switches back, and no window has focus") I believe you are introducing similar inconsistencies with this change; maybe everything can be made consistent but I need the answers to those other questions. In particular, I believe that focusing the desktop window in either mouse or sloppy focus mode unless explicitly requested by the user is wrong. I'm not so sure about click-to-focus. I'm willing to be persuaded for any focus mode, but I need the big picture. Cheers, Elijah _______________________________________________ gnome-list mailing list gnome-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gnome-list
