On 11/11/05, Shaun McCance <shaunm@xxxxxxxxx> wrote: > On Fri, 2005-11-11 at 09:31 -0700, Elijah Newren wrote: > > 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. > > This seems to be the case with any icon view, or any non-editable > text view. It's not a problem inherent in WM_DESKTOP windows. > Rather, it's a problem with the type of widget desktops generally > happen to use. At least something will happen when the user hits > an arrow key or something. Well, there's a problem in representing which widget of a window has focus with various widget sets perhaps, but the window manager itself has a way of telling the user which window on the desktop has a widget with the focus; namely, the window decorations (and specifically, the titlebar). WM_DESKTOP actually is inherently different from most other windows in that sense because it has no window manager decorations. (Yes, this does open up a can of worms given that we do honor app requests to not have window manager decorations, like all those 1970s-reject-looking-media/music-players...) > For people using the keyboard intensively (including those using > it exclusively for a11y reasons), I think having focus go nowhere > is very rarely useful. That's pretty much the crux of my argument. > Having nothing focused means you have to explicitly Ctrl+Alt+Tab > before you can do anything. That seems to me like forcing users > to do something repetitively that the computer really could just > do for them automatically. Makes sense. Note, though, that both sloppy and mouse focus modes have a keynav/mousenav switch (which gets toggled automatically as the user interacts with the desktop) because the two navigation modes have inherently conflicting constraints. Thus if your argument is based on intensive use of keyboard navigation (which has the same invariants as click-to-focus but much different ones than sloppy or mouse focus), then we've reduced the problem to what the default should be for click-to-focus (and, in particular, we can ignore a lot of the potential objections I was raising for this requested behavior). > Your counter-case: > > > 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. > > I really can't think of a scenario where I would consider that > application to be behaving nicely. If accidentally activating > the dialog (say I hit space, because I'm typing something else) > would do something bad, then maybe the dialog just shouldn't > have a default button. And disable all hotkeys as well? Those could also be hit accidentally causing a bad action. And disable special keybindings like alt-f4 so that the user doesn't close an error message before getting to read it. And... well, if we're disabling everything, why not just defocus the stupid thing? > If the window never gets focus, how > would people with screen readers ever know it's there? via the demands-attention hint, of course. (The general "unexpected window tried to come up, let the user know without stealing focus" stuff we have) > Anyway, that's something of a different case. We're just Yes, I was following Bill's tangent. (Though an interesting one, I might add. We do suck at providing onscreen indications of focus in many cases, and if it's an accessibility requirement, then perhaps we need to put more thought and effort into it. And maybe even ignore application requests to not have window decorations ;-) Sorry, I just couldn't resist mentioning that...) > talking about the case where there are no "normal" windows > on the screen. Maybe I just closed all my apps, or maybe > I just switched to a clean workspace. For keyboard people, > having focus go off into limbo just isn't very useful. It > should go somewhere, and preferably somewhere that isn't > some invisible pseudo-window. That leaves the desktop and > the panel(s). And how-to-get-focus-right.txt basically says > the panel is "harder" to focus, so the desktop seems right. Saying that the focus needs to go somewhere doesn't make a whole lot of sense to me, actually. I don't see that. What does seem reasonable is that users have a trained expectation that something will be automatically focused for them. Indeed, we provided the training in the case of many windows open; when the user closes one of their windows, we automatically focus one of the remaining ones for them. Seems reasonable. The logic you followed for desktop vs. panels makes sense too. > I'm not trying to push the desktop as the focus target when > weird stuff happens, like no-initial-focus dialogs coming > on-screen. Just this: > > if (NoNormalWindows && NothingElseWeird) > FocusDesktop (); Okay, so when the current focus window becomes invalid (because it is minimized or destroyed or is hidden or is withdrawn or whatever), you're saying that we should try to focus the MRU window, otherwise the desktop window (otherwise the no-focus-window). Makes sense, BUT: What about a window becoming invalid due to workspace switch? If there is no (normal) window on the new workspace, should the desktop be focused? Even if using sloppy focus? (or only in sloppy focus when in keynav mode?) My guess at the workspace issue is the following: Since sloppy focus's focus-on-enter + don't-focus-on-exit behavior sets up the invariant that "the normal window containing the pointer is focused if there is one, otherwise the most recently used window has focus", and since we're effectively adding the desktop window at the very end of the MRU list in the special case of the focus window becoming invalid, it makes sense to do that not only for click-to-focus-mode but also for sloppy-focus-mode. Thus, do everything you requested, and on the specific case of a workspace switch with an "empty" desktop for click-to-focus or sloppy-focus, focus the "desktop" window. Sound reasonable? > It seems to me like a reasonable fallback. Don't put it in > the list of focus-getters for sloppy (that would effectively > turn sloppy into mouse focus). Don't put it in the Alt+Tab > or consider it in the recently-used window list. Just focus > it when all else fails. Yeah, I think putting the desktop in those lists would be nuts. I think your arguments seem reasonable, and I'm leaning towards the change now. Anyone have further comments, or should I code up the patch and run it by Havoc? Ought to be pretty simple... Cheers, Elijah _______________________________________________ gnome-list mailing list gnome-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gnome-list