RFC: Making focus information visible for panes

[Celeste 'seele' Paul]

On Monday 27 November 2006 19:34, Matthew Woehlke wrote:
> Celeste Lyn Paul wrote:
> > On Monday 27 November 2006 19:11, Matthew Woehlke wrote:
> >> Jaroslaw Staniek wrote:
> >>> The problem is that users can never get a hint where the focus is (main
> >>> pane or the side pane). My proposal is to require (from app authors and
> >>> from KDE Style creators) to show the focus by highlighting the current
> >>> tab (with KDE Highlight color, currently blue) if it's focused, and
> >>> highlight the KMainWindow's dock's header in the same way.
> >>
> >> Isn't this something handled by the qt-style (QStyle/KStyle) being used?
> >> [snip]For example, Plastik draws a highlight-colored box around
> >> textboxes, etc that have keyboard focus. I don't know of any reason why
> >> a qt-style can't do the same thing for tabs or other widgets. You can
> >> certainly make this policy (although I would strongly recommend you
> >> allow it to be a configuration option in the style) but it is still up
> >> to qt-style writers to implement it.
> >>
> >> IMO this is something you should never, ever write hacks to address.
> >> Overriding the user's choice of qt-style should only be done out of
> >> extreme necessity.
> >
> > It _should_ be mandatory, added in to the kdelibs, and not handled by the
> > style at all
>
> It can be a mandatory *policy* (but I'm likely to file a bug report if I
> can't turn it off; that would be uncalled-for), but how would you go
> about implementing it in kdelibs? If you did that, it would be hack-ish,
> it would override functionality that styles are *supposed* to address,
> and wouldn't work for Qt-but-not-KDE applications.
>
> ...unless you meant it should be in KStyle which IIRC is in kdelibs and
> is the base class for *some* Qt styles (which would still allow styles
> to override the behavior, which is IMO a Good Thing).

I'm not a developer so I don't know how how it is implemented.  What needs to 
happen on the user's end is that some kind of clear indicator must be added 
to show what has focus.  

The example we always cite is in Kmail.  When a certain pane has focus, there 
needs to be a CLEAR indicator what is selected.  A practically invisible 
marquee doesnt count because you still can't tell which selected item has 
keyboard focus (this is an accessiblity and usability issue).  Previous 
suggestions included drawing a border around frames, putting a highlight on 
tabs and other widgets, etc.

The point is something must be added.  Why would adding a properly planned 
property to some class in the libs be a hack?  We have feedback properties 
for text boxes and other widgets, how is this any different? This, by the 
way, was on the list of several libs-related issues which were brough up 
during KDE4 Core.

~ Celeste

-- 
Celeste 'seele' Paul
www.obso1337.org