RFC: Making focus information visible for panes

[Matthew Woehlke]

Celeste 'seele' Paul wrote:
> On Monday 27 November 2006 19:34, Matthew Woehlke wrote:
>> Celeste Lyn Paul wrote:
>>> 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.  

As you may have noticed, I am. :-) At least, I'm a programmer that has 
occasionally tinkered with KDE, and have good knowledge of Qt styles and 
by extension a certain amount of understanding how Qt's drawing works.

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 
is styles need to do /better/. I'm all for making some sort of policy 
that styles must offer to do it a certain way, but if it is going to be 
at all invasive (as I think the current proposal is), then the policy 
should permit adding a user option to turn it off. Note that doesn't 
mean the policy must be to /require/ such an option, just to permit it.

> The point is something must be added.  Why would adding a properly planned 
> property to some class in the libs be a hack?

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

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

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.

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