View Single Post
epage's Avatar
Posts: 1,684 | Thanked: 1,562 times | Joined on Jun 2008 @ Austin, TX
#2
First you might want to clarify the title of this thread that this is fundamental issues in using Telepathy and not fundamental issues in Telepathy. Making the change would decrease the chance of negative tangentials that would not contribute to helping resolve your problem.

Originally Posted by mr_jrt View Post
Ok, I'm working on my first Maemo5 project (QtCreator/C++) to get a feel for things, and the next stage is to query and preserve the status of all the accounts, disable them, then do stuff, and finally restore them.

Easy-peesy. DBus query to grab the state, DBus calls to disable them all, then DBus calls to restore the saved values.

Thing is, the version of Telepathy in the QtCreator SDK seems quite old, and doesn't have the convenience methods for getting and setting the DBus properties, so you have to use the generic DBus property methods.

My issue is that I've been mostly using Qt up to this point, with just a sprinkling of glib thrown in as required, so I have no idea if I'm missing something fundamental. The blocking calls (tp_cli_dbus_properties_run_get) are deprecated, and the async calls (tp_cli_dbus_properties_call_get) run from the event loop. Thus, the callbacks fire when the reply is received, but I've no idea what the correct way is to determine when this has completed.

It essentially becomes a bit more complicated due to the fact that there are two callbacks involved; the first to identify the accounts, and the second group are set up from that callback for each account to query the property values. I can (IMHO) bodge it by noting the number of accounts returned, and then waiting until I have that many property callbacks fired...but this seems a poor way of doing things, and I'm sure I must be missing something...

...any ideas?
Let's see if I understand the problem. For each account you need to send/receive a message and based on that message you need to send/receive another?

Normally how I handle this is good book keeping. Keep in mind that you should get error replies if one fails so you shouldn't have problems with waiting forever due to a problem (unless there is some weird bug on either side).

The nice thing about the use of callbacks is that even in a buggy condition you can end up having a user cancel the request (assuming this is a GUI app). The other nice aspect is you can fire all of the callbacks in parallel and and process the second ones in parallel and then join them all at the end.

You can use objects dedicated to this to help with the book keeping or you might be able to use QSignalMapper.

I have an example of tracking all of this but it is in Python and uses DBus through GLib rather than Qt but maybe it'd help. Its meant to watch for calls, check if they are incoming but not picked up, so I can refresh voicemail.

Top Level
https://github.com/epage/DialCentral...all_handler.py
Utility Classes
https://github.com/epage/DialCentral...il/tp_utils.py
__________________
770, n810, n900, Ideapad S10-3t
TheOneRing, DialCentral, Gonvert, Quicknote, Multilist, ejpi, nQa, Waters of Shiloah
Programming Blog
 

The Following User Says Thank You to epage For This Useful Post: