"propertyspecifications" for inheritted properties of custom widget plugin.

[yoav]

When defining a custom widget plugin you need to implement the domXml() method. In this method you may define some information about the properties of your widget so the designer will know how to treat these properties.
See: http://doc.trolltech.com/4.6/designe...m-widgets.html
Search for "propertyspecifications".

[high_flyer]

Heh, the trolls have been adding so much so fast, I have trouble keeping with all the new stuff...

Well, if your custom widget is derived from other custom widgets which specify domXml() (i.e domXml() returns a not empty string) your subclasses in did should inherit it...
May me you need to explicitly call the MotherClass::domXml() in your current class, or, make the domXml() virtual in the Mother class.

[yoav]

Hi, my base custom widget doesn't have a plugin and therefore doesn't specify a domXml(). So I can't do that. I can't really do this since the base custom widget is an abstract class, so there's no real point in having a plugin for it. In any case I created a plugin for it, just to test your theory and it still didn't solve my problem.
There should be some way to define property specifications for properties from arbitrary classes which are then used by any widget plugin of widgets that inherit these classes.
I hope someone can figure out how to do this, cause copy-pasting the property specifications to all widget's is really annoying and bug prone.

[high_flyer]

Lets break the problem down.

my base custom widget doesn't have a plugin and therefore doesn't specify a domXml().

Well that conflicts with

This base custom widget (which inherits QWidget) has some properties which I want available in the designer,

which you wrote originally.
But I take it that your custom widget does inherit from some other custom widgets which does implement domXml(), otherwise the whole problem of copying it would be raised, right?

So, the thing we have at hand is having a class inheriting implementation of a mother class, which should be solved with what I wrote before.
Creating a plugin for the abstract class will not help, if the abstract class returns an empty string from domXml(). - and if it does, then you don't have anything to inherit from it...

Ofcourse, you could use the old Q_PROPERTY in your subclass header file.

[yoav]

My base widget doesn't have a plugin (since its an abstract class, but even if it wasn't I don't want anyone to actually use this widget). It does however contain properties. And since the designer lists all the properties of all the ancestors of a widget, you can change properties derived from parent widgets event if the parent widget doesn't have a plugin (the classic example being the "objectName" property inherited from QObject).

In any case I did create a plugin for my parent widget (just for the test), and it did have a domXml() retuning a valid XML with the "propertyspecifications" I wanted (not an empty xml). But it seems like the "propertyspecifications" were not inherited by the derived widget. So what you suggested didn't work for me.

[high_flyer]

can you run your code in a debugger, explicitly call domXml(), set a break point and see what string is beying returned?
If the string is not empty, it should be the string you set in the base class, which should hold propertyspecifications in it.
At least then we know if the problem is before calling domXml() or after it.