Styled custom widgets

Girish Ramakrishnan girish at
Sat Aug 30 20:38:14 BST 2008


Thomas L├╝bking wrote:
> 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 > 
> *_CustomBase
> and
> bool QStyle::provides(ComplexControl/ControlElement/PrimitiveElelemt element)
> the extension would have to happen at compiletime

See you point but they cannot be added to Qt since it breaks BC. This
might be a problem from KStyle too. Of course, we can always ask them
add it as slots :-)).

> 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, 
> &styleSupportedPrimitives);
> this->supportedByStyle = 
> styleSupportedPrimitives.contains((int)KStyle::PE_WhatEver);

Another approach would be to add a SH_SupportsXXX for every PE_XXX or
CE_XXX. Providing a QList<int> feels very powerful but I really doubt
its usefulness beyond this use case (also one has to concat this list
with the parent style's list and all that). Instead,

if (style()->styleHint(SH_SupportsXXX)) {
} else {
    // fall back painting

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

IMHO, this just complicates matters more than it needs to be. I would
just go with SH_SupportsXXX approach.

That said, I think its a good idea overall and I think what you
suggested will work just fine.


More information about the kde-core-devel mailing list