Using KColorScheme in style only (Was: fix frameworks-kactions compile error)

[Stephen Kelly]

Kevin Ottens wrote:
> On Wednesday 11 April 2012 23:34:18 Stephen Kelly wrote:
>> [...]
>> At the center of the questions of what to do with KUrlLabel and
>> KCapacityBar are the question of what to do about their KColorScheme
>> dependency. Their use of KColorScheme seems to me like something that
>> should be handled by the style instead (otherwise, for example,
>> QProgressBar wouldn't look consistent with a KCapacityBar with its
>> backgrounds and fill etc). Oxygen may already even handle a KCapacityBar
>> (I'm not certain):
>> 
>> kde-workspace/kstyles/oxygen{master}$ git grep CapacityBar
>> oxygenstyle.cpp:        CE_CapacityBar( newControlElement(
>> "CE_CapacityBar" ) )
>> oxygenstyle.cpp:        if( element == CE_CapacityBar )
>> oxygenstyle.cpp:            fcn = &Style::drawCapacityBarControl;
>> oxygenstyle.cpp:    bool Style::drawCapacityBarControl( const
>> QStyleOption* option, QPainter* painter, const QWidget* widget ) const
>> oxygenstyle.h:        virtual bool drawCapacityBarControl( const
>> QStyleOption*, QPainter*, const QWidget* ) const;
>> oxygenstyle.h:        QStyle::ControlElement CE_CapacityBar;
>> 
>> 
>> KColorScheme is very different from QPalette. It seems to have 4
>> dimensions that QPalette doesn't have. I'm all for configuration, but I
>> think it should have an affect in the style, not in the widgets
>> themselves. Any thoughts?
>> 
>> Would it be possible to remove the use of KColorScheme from these widgets
>> in general?
> 
> I'm unfortunately completely ignorant regarding KColorScheme... I agree it
> should probably not leak into our widgets and be used by the styles only
> though.

Hugo, any ideas/comment on this? The background is here:

http://thread.gmane.org/gmane.comp.kde.devel.frameworks/473/focus=485

Thanks,

Steve.