RFC: Making focus information visible for panes
mw_triad at users.sourceforge.net
Tue Nov 28 01:15:38 GMT 2006
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.
This message will self destruct in five millennia.
More information about the kde-core-devel