Re: panel focus

[Seth Nickell <snickell stanford edu>]

> > However I do think that if you click on the panel, your app window
> > should defocus; otherwise we are violating the premise that the panel
> > is just a "special app" rather than a part of the WM.
> 
> I think the more salient point here is that if we don't defocus the app
> window when a panel or panel object has focus, it gives a misleading
> visual cue that the app is still receiving keyboard focus, which it most
> certainly isn't-- the panel is, and no amount of jiggery-pokery will
> send your keypresses to the apparently-focused application.

No disagreement here. I don't think anybody is contending with the
notion that when the (keyboard, or otherwise) focus is on the panel, the
window should be drawn unfocused. The issue is *when* should the panel
be focused. My opinion on that is "as little as possible".

If we really need to focus the panel, for example so somebody can type
in a text box on the panel (say the command line applet), we have to
focus the panel, NBD. But in most cases we don't really need to focus
the panel. I'm not exactly sure how to give an abstract description of
when the panel should or shouldn't be focused, but I can give a list of
examples.

Cases where the focus should stay on the window that was active when the
panel operation was started:

Adjusting the volume with the volume control applet.
Pulling up the right click menu on any applet
Clicking a launcher on the panel or in the menus (eventually a new app
will come up, yes, but until such time I think the previously focused
window should be focused)
Clicking on the "Applications" menu and then pressing "esc"
Clicking "next track" on the CD player applet
Bringing up any menu on the panel and pressing "esc"

Cases where the panel should take the focus:

Clicking in a text box in an applet (say the command line applet)
Clicking directly on the panel itself (*not* dragging)
Whatever the magic keyboard shortcut is for focusing the panel

GNOME 1 *almost* does this, with the caveat that it temporarily
unfocuses the window while system modal things like menus are selected,
though the focus goes back to the window when you are done. The GNOME2
panel used to work like this until the keyboard nav and prelighting
changes were made. I would prefer that these work like application-local
menus (so the application stays focused), but I don't think this is
nearly as important as where the focus is when you are done.

Basically the long and short is that the panel would never take focus
unless it needs focus to allow you to use a particular widget in an
applet. This makes the panel seem light, and allows the user to mix
interaction with the panel with window interaction. The panel ain't a
window, and IMO has very little reason to have the heavy focus that a
window has, and makes the interface feel better if it doesn't have heavy
focus normally.

For users who do not need keyboard nav, I believe that a focus-avoiding
panel is much better than a panel that grabs focus. There's simply no
benefit to most users when the panel steals the focus from the window.
For users who need keynav to navigate the panel, they're going to be
using keyboard anyway, so having keyboard operations focus the panel
should be enough, right? I doubt there's going to be anyone who uses the
mouse to click on a panel applet to do something, and then really needs
to move around the panel using keynav.

Basically, I think this accessibility change is bad. I think the old
behavior was much better, and I don't think as much change was necessary
from the old behavior as was made. IMO, all you need is a way of
focusing the panel using the keyboard (which as I understand it is
necessary anyway), and this change shouldn't have to impact mouse usage
at all.

A side issue is how the panel indicates focus. I care much much less
about this issue if the panel weren't so eagre to grab focus, but its
worth noting that prelighting is broken if it passes it on to child
widgets (i.e. the applets). I don't know if its possible to prevent
this. GTK specifies that prelighting happens when "the mouse is over a
widget". Some applets, sanely enough, assume this behavior. So for
example menubars focus all their top level menu widgets when the panel
prelights! This will be a serious issue if we try to use a menubar
applet post GNOME 2.0. But once again, if the panel isn't so easy to
accidentally focus, I don't care very much.

cheers,

-Seth