On Tue, 2018-02-06 at 13:35 +0000, Simon McVittie wrote:
On Mon, 05 Feb 2018 at 15:22:00 +0100, Gabriel LUCAS wrote:I think I might have reached some limitation with this method while trying to handle a property set from the service side. The generated code provides a vtable for the interface with the property_get and property_set handlers set. When a property set is received, the GObject property is automatically changed without having to be handled by the developer. My opinion is that the service should be able to refuse a property set in some cases.One option is to set properties via method calls: this makes it easier to document which errors they can raise, makes it possible to have several properties change atomically as a batch, and makes it (I suspect) more likely that all D-Bus clients will be able to make those changes asynchronously and cope with failure (or cope with the property being set to a differing value, e.g. undergoing some sort of normalization).For example, a property GNSSEnabled can be set true to activate the GNSS output only if the modem is powered on. Then, I'll need to return an error and prevent the property set if the modem is off.For example, you could have a read-only GNSSEnabled property paired with an EnableGNSS() method; or maybe a read-only GNSSEnabled property paired with an EnableFeatures() method that takes an array of strings or integers representing features as its argument. The underlying GDBusInterfaceVTable makes it possible to handle setting properties asynchronously (and the documentation doesn't explicitly say so, but this is also failable) but I don't think gdbus-codegen currently has a way to generate code that makes use of that feature.
Indeed, afaik you have to forego gdbus-codegen entirely and manually write your vtables in order to do failable property setters. A common cause for this is the need to do a polkit check before allowing a property to be set. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part