[Bug 24061] TpAccount, TpAccountManager: add convenience API similar to libempathy's

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24061





--- Comment #15 from Jonny Lamb <jonny.lamb at collabora.co.uk>  2009-09-25 11:40:59 PST ---
(In reply to comment #14)
> In telepathy-qt4, the core feature is implicit (becomeReady never succeeds
> until FeatureCore is ready, regardless of what features you asked for). I think
> we should probably do the same here, so it's enough to call
> tp_account_prepare_async (., NULL, ., .) to get basic functionality.

Done.

> As with get_current_presence, please explicitly say which presence (this
> appears to be the current presence). I think adding "current" to make the
> distinction between requested and current presence clear is worth the extra
> typing (for how not to do it, see MC 4's Presence and PresenceActual).
> 
> I think it's worth calling accessors/properties whose type is
> TpConnectionPresenceType "foo-presence-type", and reserving "foo-presence" for
> things that (can) get the whole SimplePresence struct. You might disagree,
> though.

Sounds reasonable, done.

> The API for current and requested presence is currently inconsistent: one has a
> single combined method and one has three methods. Please pick one or the other
> (I don't really mind which).

Done.

> > 1881  * tp_account_update_parameters_finish:
> 
> This should be able to output reconnect_required somehow. I don't know how you
> normally do that in GIO.

Yeah, done.

> > 1285    * TpAccount::removed:
> 
> Removal is already represented by invalidating the object with
> TP_DBUS_ERROR_OBJECT_REMOVED, as documented in the TpAccount introduction. Do
> we need a removed signal as well? (telepathy-glib users are basically going to
> have to deal with the idea that objects can be invalidated, regardless - in
> telepathy-qt4 we represent account removal as invalidation with a particular
> error)

I guess not, removed.

> > 1249    * TpAccount::status-changed:
> 
> It might be worth adding a string (currently unused, eventually D-Bus error
> name) and a hash table (currently unused, eventually "details"), to make the C
> API less nasty when we expose ConnectionError(s, a{sv}) on the Account as well
> as the Connection.

Done.


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