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

[Elijah Newren <newren gmail com>]

On 11/11/05, Bill Haneman <Bill Haneman sun com> 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