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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
