RFC: Making focus information visible for panes

[Celeste Lyn Paul]

On Monday 27 November 2006 20:15, Matthew Woehlke wrote:
> Just to be clear, I'm not disagreeing. I'm just saying that (IMO, and
> perhaps a NSHO by now) the Right Way to do it is to require style
> designers to do it.

...

> As for implementation, styles already have the capability to do this (as
> has been noted, many *do* it, just not "well"), so what needs to happen

which styles implement frame or pane highlighting? 

> ...It is a hack because you are trying to circumvent the intended
> function of an existing class, which is rarely a good idea. At *best*,
> trying to do this outside of the style code is likely to cause issues,
> plus it won't work on Qt-but-not-KDE applications (whereas styles work
> on both). The fact that Qt assistant is being used as an example should
> already tell you that this is not something you can fix inside kde,
> unless you are fixing something (styles) that Qt uses from dynamically.
>
> Otherwise you need to be talking to Trolltech.

I dont see why that isnt an option, there is an obvious need

> You'd have to point me at those, but by "feedback" do you mean e.g. the
> different-colored frames as drawn by the plastik style in kde3? This is
> "libs-related" in as much as plastik comes from kdelibs, but this is
> still exactly what I have been saying that the *style* needs to fix it,
> not something outside the style.

Why can't we force a default for it to be on and then let the style designers 
do whatever they need with it? I find it kind of silly to push the 
reponsibility of usability to style designers.  just because they can, doesnt 
mean they should. the kde default or highly promoted styles should be models 
of good behavior, not exceptions.

Has this become an argument about defaults?

FYI:
http://wiki.openusability.org/guidelines/index.php/Libs#Visualisation_of_Focus

-- 
Celeste Lyn Paul
KDE Usability Project
usability.kde.org