[Development] QConfig update.
thiago.macieira at intel.com
Thu Oct 16 09:17:04 CEST 2014
On Thursday 16 October 2014 08:51:52 André Somers wrote:
> Exactly the same way moc already parses header files now? My idea was to
> explore if it were possible to build on what moc already can do. You
> might have noticed that this idea looks exactly like how you create
> Q_PROPERTY declarations. I think they should basically _be_ Q_PROPERTY
> declarations, though the options would be extended with keywords such as
> SETTING and DEFAULT.
That's abusing moc for something it wasn't intended. Moc creates a meta object
information for an existing object. That implies:
* the class is a QObject, which this needs not be
* there are no extra methods present in the class, which this needs
We need a code generator that generates a header and possibly a .cpp that can
be #included for use elsewhere, like uic. That's not moc.
The syntax you proposed does not accomplish that:
class AppSettings: public QTypedConfig
Q_SETTINGS(); // Q_OBJECT, but perhaps with some extra's like the
ability to include generated function declarations for getters and setters
Q_SETTING(int width SETTING "dialog/window-width" DEFAULT 800);
//use generated getter, setter and notify
Q_SETTING(MyCustomType myValue READ myValue WRITE setMyValue NOTIFY
myValueChanged); //use custom getter and setter
AppSettings(QObject* parent = 0);
MyCustomType myValue() const;
void setMyValue(const MyCustomType& value);
Q_SIGNAL void myValueChanged(const MyCustomValue& value);
Given this header, there's no way the preprocessor can turn the Q_SETTING
macro into a useful declaration. So you can be absolutely sure that the above
will not be the way to write the setting declarations. The schema will not be
a C++ source or header file.
Given the above statement, we have two choices:
1) invent our new schema format
2) adopt a format based on something we can read with QtCore
Option 2 implies either XML or JSON.
> Note that I would really like it if it were possible at all to not only
> generate .cpp, but also generate a bit of .h that gets included into the
> class declaration in some way, so that there would be real functions to
> call for all settings. That's what I really miss with the Q_PROPERTY
> using the MEMBER keyword.
Just as I said.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development