[Bug 76369] [next] Remove dbus-glib GTypes from public API

[bugzilla-daemon at freedesktop.org]

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

--- Comment #10 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #9)
> So what's the plan to fix this? Turn TpSvc* from GInterface to GDBusSkeleton
> and make them has-a instead of is-a? Or just remove signals from the
> generated interfaces?

My current plan is to fix the low-hanging fruit (high-level API, especially
client-side) first. That's a significant API break already.

Next, I'll probably stop implementing TpSvcDBusProperties (which is a weird
special case) in any of our high-level API, and make the TpSvcInterface code
call into TpDBusPropertiesMixin instead. MC can still override that with its
own TpSvcDBusProperties implementation if it really needs to, but it seems bad
for it to be an API guarantee that TpBaseConnection implements D-Bus Properties
monolithically, rather than letting GDBus do it per-interface. I might
GVariant'ify TpDBusPropertiesMixin at the same time.

Next, I'll go through all our CMs and see how much would break if we got rid of
the signals (by grepping for their names), then implement that by either:

* using a hand-written GDBusInterfaceSkeleton for the few interfaces that are
implemented by our base classes, or

* generating a GDBusInterfaceSkeleton with GDBus' codegen, or

* changing the codegen to not generate the signal names, or

* changing the codegen so the TpSvc* interfaces can either be has-a or is-a,
and changing all our base classes to use them in is-a mode (I suspect it would
be too disruptive to CMs if we change all of them to has-a)

> Related to this, if we want to use gdbus-codegen skeleton in
> TpBaseConnection it means we have to stop implementing TpSvcConnection and
> that's an API break.

Hmm, yes, good point.

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