[Development] QConfig update.

[Thiago Macieira]

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

public:
     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