panel focus indication

[Bill Haneman <bill haneman sun com>]

Hi Folks:

[This message is in reply to the recent/current thread that led to the
removal of visual focus indication from the GNOME 2 panel.]

The panel, like everything else, must be keyboard navigable.  That's a
requirement for accessibility and is a significant part of the broader
usability picture.  In order for keyboard navigation to work properly
one needs clear visual focus keyboard focus indication at all times.  On
these items I think we are likely to be in agreement.

But I think that most if not all of the other proposals I have heard for
dealing with this issue fail to address the accessibility problem we are
trying to solve.  Consider this:

(1) users who have poorer-than-average vision will not be 
    able to see a thin focus line very well; it 
    seems agreed (from other postings) that
    the "focus line" proposal would fail to give 
    a clear focus indication
    even to a user with good vision.

(2) other parts of our UI toolkit don't always use 
    the built-in engine focus indication (for instance, 
    text fields and splitter bars); if we
    try to do this with panel we'll have to pad the 
    panel a lot when the focus line thickness is large, 
    and even then we won't have addressed (1)
    above or (3) below;

(3) for the rest of GNOME, the toplevel window where 
    focus lives gets highlighted clearly by the window 
    manager theme, so that the user must only focus his 
    or her attention within that window for a more specific
    keyboard focus indication.  But a "gtk-like" focus-line    
    approach to focussing the panel fails to do this 
    since there is no decoration.. another means of drawing the   
    user's attention to the panel is required. 
    This issue holds even when a panel child has focus, 
    which was one reason for the   
    "prelight-stays-on-when-child-is-focussed" behavior.  
    This one is not just an accessibility issue, it would 
    be a usability problem for all keyboard-navigation users.

Semantically I think GTK_STATE_SELECT makes sense for this, and is what
is used for splitter bars; but in the default GTK theme this looks
pretty ugly.  But this is easy to override for the panel however, in a
gtkrc file, it's just a matter of choosing a default (now).

I don't agree that bug reports and complaints constitute proof that
something is a bug; certainly this point of view is not being followed
uniformly elsewhere in GNOME!  If panel prelighting (or use of the
SELECTED GTK_STATE, which is arguably more consistent semantically)
generates bugs it will not be the first feature of GNOME that does so.
Of course we should try to address the issues nonetheless... And I agree
with Calum that most of the complaints are probably being generated by
"real" bugs, i.e. prelighting behavior that is neither
required nor clearly appropriate.  We should fix that behavior, not pull
out a lynchpin of our accessibility support because people are
complaining about a side effect!

I also don't think this is puntable.  I question whether the release
team should have allowed this to be pulled without a committment to put
in a workable alternative before 2.0.0, since trying to add good
keyboard navigation focus indication post-2.0.0 would clearly generate
even more bug reports and complaints.

In all of this we have to work with the limitations of the now-frozen
GTK+ 2.0.  So we can't do anything like add a GTK_STATE_FOCUSSED, etc,
or muck with the focus engine.

In GNOME 1.4 the panel doesn't prelight at all when the mouse is over
it.  Therefore I think there is no good argument against modifying the
prelight state theme colors for the panel widget class, so that whatever
focus indication is given is both visible to the "ordinary" user (i.e.
user of the default theme) and is less jarring so that it generates
fewer complaints.  This has the advantage of being themeable without any
theme/style changes, easily implemented, and of course could "be turned
off" via the theme by choosing color settings that made the colors for
"prelight" and "normal" the same for the panel.

As for the desired behavior, I agree that it may not be appropriate to
focus the panel when clicking on children; it might not be appropriate
to focus the panel when clicking at all, and only give the panel
explicit keyboard focus (with visual indication) when it has been
explicitly focussed via the keyboard.  The fact that sawfish doesn't
have a keybinding for this yet is clouding the issues I fear.  Of course
there are some applets that may need keyboard focus, and they should
receive it on click in that case.

TO sum up:

* panel focus indication during keynav is a must, 
  and we should add it
  now to avoid worse complaining later;

* panel focus on click is the main complain-generator, 
  and doesn't seem necessary to me;

* panel focus indication needs to be bolder than for 
  plain widgets due to the absence of window decorations;

* focus-line approaches to panel visual focus indication 
  suffer from both lack of clarity and the need to 
  pad the panel size;

* we can easily override the PRELIGHT colors for the 
  panel to reduce the perceived problem for users who 
  don't need bold highlighting, via a trivial RC-file 
  addition.

I believe that the previous behavior (with some fixes if possible) can
and should be reinstated in combination with an rc-file entry such that
the complaints about this "bug" go away, while meeting our needs.

Regards,

Bill

p.s. - I will have very limited access to email for the next few days,
apologies.