If this is all that stands in the way, I wouldn't object to the addition of a tp_dbus_properties_mixin_set(), defined in terms of "does the same thing as the D-Bus method or raises the same error".

(In reply to comment #1)
> If this is all that stands in the way, I wouldn't object to the addition of a
> tp_dbus_properties_mixin_set(), defined in terms of "does the same thing as the
> D-Bus method or raises the same error".

I'll retract my neck slightly: that may not be *all* that stands in the way. It's just the thing that I hit that made me give up.

(I wouldn't be hugely opposed to that function either, but I am having a think about how to avoid it, just in case.)

tp_dbus_properties_mixin_set has been implemented. I wonder whether anything else prevents this change?

(In reply to comment #3)
> tp_dbus_properties_mixin_set has been implemented. I wonder whether anything
> else prevents this change?

If I remember correctly, the answer is that McdDBusProp allows read-only properties to have a setter, and be set via mcd_dbusprop_set_property(), in order to implement an equivalent of GObject's READWRITE|CONSTRUCT_ONLY properties.

We could add tp_dbus_properties_mixin_set_during_construct() but I really don't want to put that on the critical path for Telepathy1.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-mission-control/issues/34.