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