Styled custom widgets

Thomas Lübking thomas.luebking at
Sat Aug 30 15:41:05 BST 2008

KDE ships several custom widgets that require a unique look.
Currently they're usually (partially) style controlled painted or the painting 
is "hardcoded" inside the widget.
Latter one can look alien, out of time (remember that KeyButton in KDE3?) or 
just doesn't catch all environments (color combinations)
Styles could try to eat the paintevent, but this is hackish and can be 
a) impossible as not all required informations are public
b) "dangerous" as "while we're at it" could perform unexpected thigs on the 

Unfortunately QStyle currently doesn't provide functions to runtime extend the 
primitives and (complex)controlelements.
So as long as noone can convince TrollTech to add 
int QStyle::element(const QString&) // creates an atomic element id > 
bool QStyle::provides(ComplexControl/ControlElement/PrimitiveElelemt element)
the extension would have to happen at compiletime

(extending KStyle by the above would be another option, but requires catching 
plain Qt linking styles to prevent segfaults. Also it would require linking 
the style against kdelibs for hardly any real reason and may require 
distributors to maintain two versions of styles - whatsoever...)

I suggest to reserve the area > 0xff000000 (0xf0000000 is *_CustomBase, 
meaning that every smartass will use 0xf0000001, 0xf0000002 a.s.o. for their 
application specific elements - in case there are...) and abuse 
QStyle::styleHint() to ask styles for support, like
#define SH_SupportedPrimitives 0xff000001
#define SH_SupportedConltrols 0xff000002
#define SH_SupportedComplexConrols 0xff000003

QStyle::styleHint() returns '0' (i.e. false...) by default and also supports 
QVariants (including QList<int> ...) as returndata.
So on constructing the widget and QEvent::StyleChange one could query and 
cache the support by e.g.
QList<int> styleSupportedPrimitives;
style()->styleHint(SH_SupportedPrimitives, 0, this, 
this->supportedByStyle = 

An abstraction class "KCustomStyleWidget" could provide this and handle 
painting so the widget just implements 
KCustomStyleWidget::fallbackPaintEvent() on the painting side (as i think 
multiinheriting QObjects isn't possible?! it may however be essier to inherit 
QPushButton and implement the above there)


More information about the kde-core-devel mailing list