Re: panel focus

[Seth Nickell <snickell stanford edu>]

On Mon, 2002-03-04 at 02:15, Bill Haneman wrote:
> Seth Nickell wrote:
> > 
> > Every person I've had upgrade to GNOME 2 has commented on the weird
> > "panel gets lighter" thing to me.
> > 
> > Additionally, this has a not insignificant usability cost because it
> > means when you use the panel your current focused window almost always
> > ends up unfocused. This makes the panel feel like a window, which it
> > shouldn't. I don't know how to describe this except that it makes the
> > panel feel "heavy" somehow that it steals focus from windows.
> > 
> > Compare this to GNOME1 where focus is temporarily snatched from the
> > window, but as soon as you are done it goes back to the window. Feels
> > *MUCH* more natural.
> > 
> > Is there a reason mouse clicks should ever focus the panel like this?
> > People who are seriously going to be using keyboard nav for the panel
> > probably aren't going to be using mice. Can we only do this weird focus
> > voodoo on keyboard activation? i.e. you can only focus the panel using
> > the keyboard (or maybe mouse clicks *directly* on the panel with no
> > dragging or anything).
> 
> Well, for one thing I don't believe that a mouse click on an applet
> should focus the panel; e.g. the panel should only get "lighter" if
> you click on the panel itself or keynav to it, not if you focus
> a child of the panel.  If the current behavior doesn't match this, then
> I think it should be reconsidered; I don't see a downside to your last 
> sentence.

For example... Right click on any applet, press esc. The panel is left
focused rather than the window you were working in.

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

Where did this premise come from? I don't want the panel to act like a
special app. It already violates most of the concepts of a windowed
application, and I think its confusing to tell users "actually, its a
window". That's an implementation detail. The panel is part of the
desktop. Its behavior differs from "normal" apps in a lot of ways: You
can resize it. It has no window borders. Its always on top (well, at
least usually). In metacity (which is closest to the long term behavior
I'd like to see) maximized windows don't cover panels. Etc etc. 

Its not a window, or a special app, its a part of the desktop which is a
distinct category shared only with the nautilus desktop (not file
manager windows, note). In some sense its a part of every window, since
it shouldn't grab focus from windows.

> > For non-disabled users this focus stuff is a significant net loss, so
> > I'd like to find a solution that doesn't mess with normal users at all
> > but still leaves the panel accessible. It seems restricting focusing of
> > the panel to keyboard mechanisms would work.
> 
> I am concerned about the inconsistency implications of this, but as I
> said
> I don't have a problem with only giving the panel background "visual
> focus
> indication" if you click/nav to the panel and not a panel child.

That seems fine. The panel *is* inconsistent. It shouldn't behave like a
normal application (or even a special application) because it isn't one.
Its not a window. Its more like stuff that sticks to the edges of the
space where you can put windows. If you think of a "viewport" analogy,
its like stuff that's glued to the edges of the viewport, not something
beneath the viewport you look down on. ;-) It should interact and
interfere minimally with the workspace.

-Seth