Thiago Macieira schreef op 16-10-2014 09:17:
> 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
It is exactly what I was proposing though. Note that this is *not*
QConfig/QConfigGroup. I do happen to think that being a QObject for a
(central) settings object is a very useful quality. For instance, in
order to signal changes to values.
I know of course that moc was not intended for this. However, you were
asking how such a format could be parsed, and I was pointing out that Qt
has been doing exactly that for ages.
> * there are no extra methods present in the class, which this needs
What do you mean by that?
>
> 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 that you know a lot more that I do about what can and what cannot
be done here... What is blocking doing this _exactly_? Would there be
any feasible workaround for that? Would it be possible to do if you were
required to #include the generated .h file inside the class itself for
instance?
Something like this perhaps?
class AppSettings: public QTypedConfig
{
Q_SETTINGS(AppSettings); // Q_OBJECT, but perhaps with some extra's
#include(appsettings_inc.h) //include generated definitions
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
(...)
}
where the contents of appsettings_inc.h would be generated by the
generator, to yield something like:
//generated for setting property width
int width() const; //Q_PROPERTY READ function
void setWidth(int width); // Q_PROPERTY WRITE function
void widthChanged(int width); // Q_PROPERTY SIGNAL function
void resetWidth(); //revert to set default value; Q_PROPERTY RESET function
I don't think it is stretching what moc is already doing conceptually
all _that_ much. It basically creates properties that are persistent in
some kind of store for configuration, instead of them depending on
variables in the object itself. And again: I'd find this (or similar)
fuctionality also very useful for the Q_PROPERTY MEMBER keyword that we
already have.
André
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
