Account hasn't caught up with the extensible error signalling provided by ConnectionError: ConnectionError: property, s (DBus_Error_Name), read-only If the last connection to this account failed with an error, the D-Bus error name of that error (with the same semantics as the first argument of the Connection.ConnectionError signal). Otherwise, the empty string. | Rationale: the same as ConnectionStatusReason, but extensible like ConnectionError ConnectionErrorDetails: property, a{sv}, read-only If the last connection to this account failed with an error, the details of that error, with the same allowed keys and values as for the second argument of the Connection.ConnectionError signal. Otherwise, the empty dictionary. | Rationale: the same as ConnectionStatusReason, but extensible like ConnectionError
Spec cabal says yes, implementation needed.
Proposed spec patches: http://people.freedesktop.org/~smcv/telepathy-spec-account_errors/spec/org.freedesktop.Telepathy.Account.html#org.freedesktop.Telepathy.Account.ConnectionError
I'm unlikely to have time to work on this soon, so, back to unassigned. It may be easiest to implement this by improving telepathy-glib's error reporting (Bug #23369, which I made some progress on a while ago).
I've done the necessary TpConnection work to enable this, so it's not a blocker any more.
Nobody has implemented this yet, so I did: Bug #28428.
I guess my only question is wouldn't it make sense to have only one D-Bus property? That's conceptually the same thing so what's the point to split it?
Summary of discussion on IRC: ConnectionError is conceptually one property of type '(sa{sv})', but it's easier to work (less deeply nested) with if it's split into separate 's' and 'a{sv}'. They're really also conceptually part of the same meta-property as ConnectionStatus ('u'), ConnectionStatusReason ('u'), and (depending on your point of view) Connection ('o'); splitting them up is consistent with those properties.
Fixed in git, will be considered stable in 0.19.7.
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.