Re: how to focus on desktop automatically if no windows open?

Elijah Newren wrote:...

WM_DESKTOP actually is inherently different from most
other windows in that sense because it has no window manager
Unless there are no icons on the desktop, we can focus an icon by default, which gives visual indication that the desktop window is "active". The user can still get to the desktop's context/right-click menu via Control-F10.

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).
I think so too - because as you say we already detect 'keynav mode'.

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.
Yes, this seems like a horribly broken application behavior.

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...)
As a11y requirements go, it's one of the few absolute ones (on a par with "must be able to do all tasks via keynav"). In most cases, there should be some widget with focus in any active toplevel window, in which case the widget should be focussed. If apps don't do this, then it's the app that is in violation of a11y requirements, not the desktop environment. There will always be a few broken apps, but we don't want to have a broken DE.

Apps whose primary dialogs request no decorations are probably not well behaved, I agree. It's up to the app to use no-decorations for functional, rather than purely aesthetic, purposes.
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

The preceding paragraphs sound like the right behavior to me. Seems like only in sort-of degenerate cases (like the no-initial-focus modal dialog, eccch) do we end up with "nothing focussed" from the end-user POV. This seems fine, since it means that in 'normal' situations the end-user is presented with a visible incidication of onscreen focus (implicitly requiring that there _is_ an onscreen focus).



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]