RFC: Making focus information visible for panes
mw_triad at users.sourceforge.net
Tue Nov 28 16:55:45 GMT 2006
David Faure wrote:
> Matthew Woehlke wrote:
>> how would you go about implementing it in kdelibs?
> In KTabBar.
>> If you did that, it would be hack-ish
> Not really. The widget can adjust the palette before calling the style,
> if we're only talking about changing a color and not the shape or anything else in the drawing.
Hmm, ok that could *work*, but it still has the potential of causing
problems with a style that relies on the palette to remain consistent
within an application. Right now I would still consider modifying the
palette on a per-widget basis to be something of a hack. If you make it
policy, then it's a known behavior, and "good" styles would cater to it,
>> and wouldn't work for Qt-but-not-KDE applications.
> True, of course. However this has not stopped us in the past, for many things ;)
...if you make this a style policy, then Qt-only applications WILL
receive the full benefit. So I still don't understand the objection to
>> it would override functionality that styles are *supposed* to address
> Styles use the palette given to them... So I disagree. Color is the palette's job, not the style's.
No, now you're talking about a different issue. I am suggesting that
styles should be responsible for how a widget with keyboard focus is
To respond to your comment, however, it is a style's job to work *with*
the palette it is given (which is expected to be homogeneous across at
least the application). From there, it can choose to alter the palette
(as *most* do), or to ignore it entirely (not that doing so would ever
be a good idea, but it *could*).
Caution: keep out of reach of adults.
More information about the kde-core-devel