[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 #16 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #2)
> Properties and signals:
...
> TpAccount:connection-error-details is an a{sv}. TpAccount::status-changed
> contains the same.
> 
> TpBaseCallChannel:contents, TpBaseCallChannel:call-state-reason,
> TpBaseCallChannel:call-state-details, TpBaseCallChannel:call-members,
> TpBaseCallChannel:member-identifiers
> TpBaseCallContent:streams
> TpBaseCallStream:remote-members (but it would be fine with a different GType)
> TpBaseCallStream:remote-member-identifiers (but it would be fine with a
> different GType)
> TpBaseMediaCallContent:remote-media-descriptions,
> TpBaseMediaCallContent:local-media-descriptions,
> TpBaseMediaCallContent:media-description-offer,
> TpBaseMediaCallStream:local-credentials,
> TpBaseMediaCallStream:local-candidates, TpBaseMediaCallStream:stun-servers,
> TpBaseMediaCallStream:relay-info, TpBaseMediaCallStream:endpoints (but it
> would be OK with a different GType)
> TpBasePasswordChannel:sasl-error-details (but it's internal anyway)
> TpBaseConnectionManager:protocols (because it contains their properties)
> TpBaseConnection:requestable-channel-classes
> TpBaseConnection:dbus-status
> TpCallContentMediaDescription:codecs, TpCallContentMediaDescription:ssrcs,
> TpCallContentMediaDescription:header-extensions,
> TpCallContentMediaDescription:feedback-messages
> TpCallStreamEndpoint:remote-credentials,
> TpCallStreamEndpoint:remote-candidates,
> TpCallStreamEndpoint:selected-candidate-pairs,
> TpCallStreamEndpoint:endpoint-state,
> TpCallStreamEndpoint::candidate-selected,
> TpCallStreamEndpoint::candidate-accepted,
> TpCallStreamEndpoint::candidate-rejected

None of those are used in the "big 5" CMs.

> TpBaseMediaCallContent::local-media-description-updated

Rakia and Gabble do use that.

> TpBaseProtocol:immutable-properties

Gabble uses that, and overriding it is documented to be how you extend the
Protocol. I think we should make it into a GVariant.

> TpExportableChannel:channel-properties

Doesn't appear to be used directly by CMs any more - they all rely on
TpBaseChannel for it.

> TpExportableChannel's weird interaction with TpSvcChannel::closed

Realistically, I think we have to keep this, even if it becomes
TpExportableChannel::closed.

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