| Summary: | TpConnectionManager API is avoidably cumbersome | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Will Thompson <will> |
| Component: | tp-glib | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | mardy |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
I think this issue should be solved with an API similar to the _call_when_ready() of TpChannel and TpConnection (as a plus, a weak object parameter would be great). Having something like tp_list_connection_manager_and_introspect_them() could be good too, but mission-control wouldn't use that in any case (because it is only interested in managers which have some defined accounts). BTW, the current implementation has a bug: if the .manager file is missing, the "got-info" signal will never be emitted. Let's use this bug for the long-term improvement of the API / deprecation of got-info (a concept of "ready" like mardy suggests, probably) and #18207 for short-term fixes to deficiencies in the got-info API. Fixed in 0.7.26 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
There are two main use cases Daf and I can think of for TpConnectionManager: * Listing all protocols supported by all CMs (the single CM case is similar); you would want to do this in Empathy's account dialog, for instance. * Calling RequestConnection and connecting to NewConnections; the AccountManager would want to do this. Currently, the second case is easy (you create a TpCM, connect to the NewConnections DBus signal, call the method, and ignore the got-info GLib signals that will be emitted at various hard-to-predict times), but the first is hard (even if #18207 is fixed): - call tp_list_connection_managers - when the callback fires, for each CM, connect to got-info - when got-info fires: > if it's FILE, we're done for this CM. > if it's NONE: * call tp_cm_activate; the object is useless to us without the protocol info * when got-info fires again for this CM: # if it's LIVE, we're done for this CM # if it's NONE, this CM is a writeoff. - when we've finished or written off all CMs: actually do what we hoped to do. Contrast: - call tp_list_connection_manager_and_introspect_them - when the callback fires, we're ready to go. In fact the got-info signal is not very useful at all. The only case when we might want such a signal is: * haze grew a new protocol, and either restarted or emitted a magic new signal to say so * we're still showing the Accounts dialog * we want to update it on the fly.