RFC: Making focus information visible for panes
Celeste 'seele' Paul
seele at obso1337.org
Tue Nov 28 00:50:52 GMT 2006
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 'seele' Paul
More information about the kde-core-devel