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

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

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

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

-- 
Matthew
Caution: keep out of reach of adults.

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability