Styled custom widgets
Girish Ramakrishnan
girish at forwardbias.in
Sat Aug 30 20:38:14 BST 2008
Hi,
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)) {
style()->drawControlElement(CE_XXX);
} 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.
Girish
More information about the kde-core-devel
mailing list