Styled custom widgets
Girish Ramakrishnan
girish at forwardbias.in
Thu Sep 4 07:55:38 BST 2008
Thomas Lübking wrote:
> Am Tuesday 02 September 2008 schrieb Rafael Fernández López:
>> Hi,
>>
>>> 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
>>> }
>> I really think this is a good solution...
>
>
> The reason why i'd favor the runtime feature adding soution would be the
> question on how new items are added.
> Like if say k3b needs a new styled widget, they could just implement it with a
> fallack painting routine and see whether it gets adepted by styles, while the
> compiletime solution means: first they'll have to ask for a number in a kstyle
> extension to the enums. What will follow then is presumingly a long discussion
> about whether it's usefull and worthy to be added and then (iff), with the
> next KDE release it'll be (officially) supported and styles can start to adept
> it....
> That doesn't sound like much fun :-(
>
Well, instead of reserving enumerations in KStyle, you are now reserving
strings. We need to make sure that strings used by different
applications don't conflict. But that is easily overcome with a string
format like "appname.element".
As for your solution, at this point, I would like to point out adding
support for custom widgets in QStyle is not about adding PE_X, CE_X
enums. One needs to add support for querying element positions, hit
testing, sizes etc (which involves adding more enums like SC_, CC_, SE_).
Give that, you are going to have add support to query all the above
dynamically. I still prefer the SH_SupportsXX approach :) but I don't
really know about the release dynamics. So, if you still want to do a
dynamic string -> enum lookup, I would suggest:
1. Make sure the strings are namespaced ("appname.widget")
2. Create,
struct KCustomWidgetStyleOption: public QStyleOption
{
QString widgetName;
};
struct KCustomWidgetHintReturn : public QStyleHintReturn
{
QList<int> primtiveElements; // well defined order
QList<int> subcontrolElements;
// .. and so on ..
};
In the widget,
style()->styleHint(SH_CustomWidget, &customWidgetStypeOption, this,
&returnData);
Girish
More information about the kde-core-devel
mailing list