[Bug 30422] Provide GVariant-based access to all a{sv} things

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Apr 23 14:21:19 CEST 2012


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

--- Comment #27 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-04-23 05:21:19 PDT ---
(In reply to comment #26)
> _vardict is wrong name here since it's not a dictionary.

Yes, it should be _variant I think. I've been using _vardict for things that
return a %G_VARIANT_TYPE_VARDICT (i.e. a{sv}) because they're so common, they
deserve an extra hint.

> I'm pretty sure you can do almost the same as _tp_asv_to_vardict()
> but with TP_STRUCT_TYPE_REQUESTABLE_CHANNEL_CLASS as GType for the value.

Yes, do that inline. (_tp_asv_to_vardict() is only worthwhile because a{sv} is
so common.)

> > Should it return an array of TpChannelClass having accessors to get the fixed
> > and allowed props?
> 
> I don't think we want to add higher level API to expose classes, we already
> have the _supports_ methods. Also TpChannelClass is very bad name because
> that's the GObjectClass for TpChannel already.

I agree with Xavier.

If we make TpCapabilities iterable at all, my inclination would be to make
iterating it return a list of single-channel-class TpCapabilities objects so
you can still call supports_X on them (like the way iterating a Python str
returns single-character strs).

If you understand the Telepathy D-Bus API well enough to care about fixed and
allowed properties, then you understand it well enough to know about property
names, IMO. (Where "you" might mean "your application" sometimes.)

I'm curious: what else does Empathy do with TpCapabilities, and can we put it
in tp-glib?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.



More information about the telepathy-bugs mailing list