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

[Elijah Newren <newren gmail com>]

On 11/14/05, Bill Haneman <Bill Haneman sun com> wrote:
> Elijah Newren wrote:...
>
> >WM_DESKTOP actually is inherently different from most
> >other windows in that sense because it has no window manager
> >decorations.
>
> 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.

We'd need to patch nautilus in order to get that behavior (so someone
would need to file a bug...); they don't focus an icon by default when
the window becomes focused.  You can check this by just hitting
ctrl-alt-d; Metacity explicitly focuses the desktop window when you do
that.

> >>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.

Actually, this reminds me of a fairly closely related issue in an
existing bug, http://bugzilla.gnome.org/show_bug.cgi?id=303136:

The sticky and slow keys features get turned on automatically by
pressing shift 5 times or holding shift down for 8 seconds.  I have
done both at times without meaning to (especially the later since
testing out snap moving/resizing in metacity doesn't grab the shift to
prevent whatever-it-is from turning on the accessiblity stuff; this
isn't the only case though).  The important point to note is that

  These features get turned on automatically and totally BREAK the keyboard for
  most users--though a dialog does appear to warn the user about what happened.

This is by necessity, though, as you point out in that bug.  But if
the user tries to interact with any application they're going to be
very perplexed (they really should respond to the dialogs first,
meaning that the dialogs should in some sense be some approximation to
system modal, as also discussed in that bug).  Now these dialogs are
not expected for anyone who hasn't used these features before; they
appear out of the blue.  If those windows get focus, they can be
accidentally dismissed (and indeed, I have done so).  If that happens,
the user's keyboard is busted and they have no discoverable clue about
how to fix it.  It's a usability nightmare.  Luckily for me when I
accidentally triggered this (both the dialog appearing and
accidentally dismissing it), I had already read that bug report and
realized after a minute or two what had happened.

The only solution I can think of to prevent this problme that Matthias
reported, is to make those dialogs "somewhat system modal" (as
described in the bug) AND to ensure that they do NOT get focus when
launched (require the user to alt-tab to them).  That sounds like it'd
break accessibility, according to you.  But it may be a huge problem
for everyone else without this or some other solution.  Have any
bright ideas?

> >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?
> >
> 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).

Okay, I'll code up a patch then, after I get some more
constraints_experiments stuff out of the way.  It'll appear at
http://bugzilla.gnome.org/show_bug.cgi?id=317405.

Cheers,
Elijah