Web lists-archives.com

Re: [gdbus-codegen] handle property set on the service-side

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.


Attachment: signature.asc
Description: This is a digitally signed message part

gtk-devel-list mailing list