[Bug 77187] [next] Remove dbus-glib GTypes from public API: properties and handwritten signals

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77187

--- Comment #5 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #4)
>  - "TpBaseConnectionManager:protocols: remove": Hmm, there is a
> _dup_interfaces() and _get_interfaces() and both actually return a new
> GPtrArray... confusing... I don't think we should rename the vfunc to
> dup_interfaces() but at least I would add a _impl suffix, or
> _dup_interfaces_property(), or something else?

I don't think this is critical-path.

TpBaseConnectionManagerGetInterfacesFunc, the implementation of the
TpBaseConnectionManagerClass.get_interfaces vfunc, returns (transfer
container), because in 99% of CMs the interfaces are static strings anyway.

tp_base_connection_manager_get_interfaces() is not API. It is the default
implementation of TpBaseConnectionManagerClass.get_interfaces(). I could rename
it to ..._real_get_interfaces() if you want.

tp_base_connection_manager_dup_interfaces() is not API either. It returns a
deep-copy of the same thing as a GStrv, because that's what we want for the
property.

TpBaseProtocol has the same design.

I'm tempted to make our base classes into GDBusObjectSkeleton subclasses, which
would mean we could replace these functions altogether (the replacement would
be a vfunc returning a GList<GDBusInterfaceSkeleton>), but there are some
logistical problems involving TpDBusPropertiesMixin, so I'd rather do these
lower-hanging fruit first.

(In reply to comment #4)
>  - In the same commit, unrelated, but I spotted /* copy the
> klass->interfaces property for backwards compatibility */ do we still use
> that klass->interfaces? should be remove it? or we don't care?

Yes we should remove it. It's _TP_SEAL'ed, so CMs don't use it anyway.

TpBaseProtocol has the same design.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.