RFC: Making focus information visible for panes

[Matthew Woehlke]

Celeste Lyn Paul wrote:
> 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.
>> [snip]
>> 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? 

By "frame or pane", you must mean for tabs... Ok, for that, none that I 
know of, but without actually writing a hack I want to say it should be 
do-able... might require checking a parent or child for focus, but 
should be do-able. Do you need me to see if I can hack up 'plastik'?

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

Ok, well, no objections to you doing that, but this isn't the Trolltech 
list. :-)

>> 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 think we're in violent agreement? I have no objection to saying 
'styles in KDE core must implement this and turn it on by default'. Such 
a style *may* (not "shall") then provide a way to turn it off. 
Personally I would suggest such a way, but it isn't required.

> I find it kind of silly to push the 
> reponsibility of usability to style designers.

Because that's the most efficient, cleanest way of doing things.

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

Not sure, but to clarify: my suggestion of making it a policy would mean 
that all styles that are part of kdelibs or kdeartwork would be 
"required" to support this, and to enable it unless the user chooses to 
turn it off. I think maybe we're arguing terminology? Of course this 
also means that 'pure KStyle' would need to Do The Right Thing, which 
would be a very good incentive for derived styles to 'work well'.

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

As you point out, TB (and Windows) get your second example correct. In 
fact, I would argue that this particular case is not only a usability 
issue but an outright bug. (I might look into this with my own style if 
I get a chance, although I suspect it is KStyle that is the culprit.)

However, your first example is wrong: there is both a focus frame and 
text cursor in the QLineEdit, which has input focus. Also, I don't 
understand the part about highlighting the button that will respond to 
'enter'; in my experience this is done correctly. Perhaps you can 
clarify for me?

You do make some other excellent points (l10n for icons, for example) 
that are very good ideas and are not things that are handled by styles.

-- 
Matthew
This message will self destruct in five millennia.