On Tue, 2010-02-16 at 15:28 +0000, Martin Pitt wrote: > Review: Resubmit > > It uses the _sync calls, but we have a requirement to make all DBus > > operations async in the various indicator code. I'm unclear whether > > up_client_get_can_suspend is sync or async. > > It gets the property synchronously on the first call (i. e. during > initialization of indicator-session, and then just returns the cached > value. I. e. in the "changed" signal handler the property values are > already in the UpClient object's cache and no D-Bus communication > needs to happen at all.
So I went and grabbed the upower code and basically none of this is Async. At all. I'd love to use the libupower library so that we're in a better place with the interface, but man: t...@shi:~/Packaging/upower/upower-0.9.0+git20100216.b9bb78$ rgrep _async * src/up-daemon.c: ret = g_spawn_command_line_async (command, &error); t...@shi:~/Packaging/upower/upower-0.9.0+git20100216.b9bb78$ I'm not sure what to do here. David, do you have opinion? I'd hate to rewrite the PolicyKit code, but we've made it a core architectural point to only use async DBus. I doubt we could patch libupower at this point as it'd be a pretty big patch. -- https://code.launchpad.net/~pitti/indicator-session/libupower-glib/+merge/19392 Your team ayatana-commits is subscribed to branch lp:indicator-session. _______________________________________________ Mailing list: https://launchpad.net/~ayatana-commits Post to : [email protected] Unsubscribe : https://launchpad.net/~ayatana-commits More help : https://help.launchpad.net/ListHelp
