I was writing some code which prepared a TpAccount and then after that I needed to get the connection out of the account (possibly waiting for notify::connection first) and then prepare that with FEATURE_CONNECTED. This is all pretty annoying. If there was some kind of TP_ACCOUNT_FEATURE_CONNECTION_CONNECTED or similar features on a TpAccount which could prepare the TpConnection in a TpAccount if it was there that would be really useful as I would only have to prepare the TpAccount once and when that returned I'd already have my connection set up as I wanted it! Anyway, what do you think of some TpAccount features like this?
(In reply to comment #0) > If there was some kind of TP_ACCOUNT_FEATURE_CONNECTION_CONNECTED or similar > features on a TpAccount which could prepare the TpConnection in a TpAccount if > it was there that would be really useful as I would only have to prepare the > TpAccount once and when that returned I'd already have my connection set up as > I wanted it! Wow, that's all one sentence! Go me!
Another way to do this, which I think I'd prefer, would be: void tp_account_prepare_connection_async (TpAccount *self, const GQuark *account_features, const GQuark *connection_features, the usual async goo); gboolean tp_account_prepare_connection_finish (TpAccount *self, TpConnection **, GError **); Either way, it's worth documenting very clearly that this isn't, in itself, sufficient to make the account go online: you have to set a requested presence too. (Maybe there should be a version that takes 3 extra arguments representing the RequestedPresence, or a version that copies the AutomaticPresence to the RequestedPresence if it isn't already "something online-looking".) If ChangingPresence goes from true to false with no Connection, any pending tp_account_prepare_connection_async calls should probably also fail, with the ConnectionError as error.
(In reply to comment #2) > Another way to do this, which I think I'd prefer, would be: > > void tp_account_prepare_connection_async (TpAccount *self, > const GQuark *account_features, > const GQuark *connection_features, > the usual async goo); > gboolean tp_account_prepare_connection_finish (TpAccount *self, > TpConnection **, > GError **); > > Either way, it's worth documenting very clearly that this isn't, in itself, > sufficient to make the account go online: you have to set a requested presence > too. (Maybe there should be a version that takes 3 extra arguments representing > the RequestedPresence, or a version that copies the AutomaticPresence to the > RequestedPresence if it isn't already "something online-looking".) This would help in the initial “Okay I have the account now I want the connection” case but it doesn't help you monitor the coming and going of a connection on an existing account. Could we have a TpAccount::connection-prepared signal whose detail is the feature quark you're interested in? :D
I've actually did similar as part of bug #26205: http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/log/?h=contact-list The idea is that I can set desired contact features on the connection, desired connection+contact features on the account and desired account+connection+contact features on the AM, like that a single async method on the AM and *everything* is ready to go.
This part is already merged into master. preparing TP_ACCOUNT_FEATURE_CONNECTION on your TpAccount will ensure that the TpConnection object exposed will always be ready.
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.