Properties interface additions

[David Zeuthen]

On Thu, 2009-01-29 at 00:15 +0100, Thiago Macieira wrote:
> David Zeuthen wrote:
> >Sounds OK though I'm concerned this will take some time. Does anyone
> >know exactly what bindings, aside from EggDBus, that maps D-Bus
> >properties to native properties/attributes/etc?
> 
> QtDBus maps D-Bus properties to the static QObject properties.
> 
> The Qt Obejct model has two property types: static and dynamic. Static 
> properties are defined in the .h file for the class with the Q_PROPERTY 
> macro, then processed by moc and hardcoded. You can query the QMetaObject 
> for that class what the properties are. The moc program simply creates a 
> function that, given a property ID will call the correct getter or setter 
> function, after casting a QVariant to the appropriate type.
> 
> However, if you were to call setProperty("name", value) where "name" is  
> not a known property, then you are creating a dynamic property. Those are 
> not supported at all by QtDBus.
> 
> The interesting problem is that there is no change notification for static 
> properties, since they are basically moc glue on top of C++ methods. I.e.:
> 
> 	Q_PROPERTY(int value READ value WRITE setValue) // expands to nothing
> 	int value() const;
> 	void setValue(int x);
> 
> And C++ methods can be called directly, bypassing setProperty and, 
> therefore, any trap mechanism we might set.
> 
> On the other hand, dynamic properties must be modified with setProperty 
> and there's an event sent whenever they are changed. But we don' t support 
> them, since they are not known to be valid in every single object of that 
> class and, therefore, cannot be listed in the introspection's XML.
> 
> In other words, QtDBus would always have emits-changed="false" or would 
> have an empty list of property names that supports change notification.

So you are saying this is impossible with current QtDBus, right? Or are
you saying you are unable (because of ABI backcompat issues) to add
support for the PropertyChanged() feature to a new version of QtDBus?

You of course know better than me, but why wouldn't a solution to this
problem simply be that the setter for an emit_changed="true" in the
QObject manually calls a method on the super-class (or a static method
on the connection or other object, dunno if exported objects in QtDBus
have to derived from a well-known class) to emit the PropertiesChanged()
signal? Or, maybe better, require that property setters chain up and you
can emit the PropertiesChanged() signal in the superclass if applicable.

I mean, from a 50,000 ft point of view, the proposed PropertiesChanged()
signal is not really different from other signals; the way it would work
is that you'd just emit a generic signal instead of a hand-rolled one.
So code-wise there wouldn't be any changes for service implementers.

I seem to recall that the way QtDBus works is that you use a code
generation tool to generate skeleton code that the service implementer
can base his class on. Presumably you could generated the suitable code
(or a TODO) for the getters/setters of properties that has
emit_changed="true".

Just out of curiosity, do you cache properties in QtDBus on the client
side? Or do you do a sync D-Bus call on every property get? Either way,
having PropertiesChanged() would easily allow you to implement caching
of properties so it would be a win for QtDBus as well to have this...

     David