DBus-using Library Design
As a rule of thumb, when writing a library which uses DBus please always make asynchronous DBus method calls. You never know when someone will write a system using your library which, via a series of plugins, ends up calling itself. A single main loop and blocking DBus calls are not a great combination, and leads to lots of frustration.
Yes, libnotify, I'm looking at you.
NP: Out of Season, Beth Gibbons
Posted by davidz at Mon Feb 18 18:43:39 2008:
Uh. I'd rather we'd have some decent D-Bus bindings for GObject instead of everyone and their mother wrapping their D-Bus service in some kind of API they happen to like (and that mostly everyone else dislikes).
Seriously, we need way better D-Bus bindings for GObject.
Posted by Daniel Stone at Mon Feb 18 23:22:14 2008:
Seriously, we need way better D-Bus bindings for GObject.
a) Who's Beth Gibbobs?
b) Surely this only screws you up further by assuming you're using a D-Bus-aware mainloop. What if you're using libnotify from an application which doesn't make D-Bus calls in its mainloop, because it doesn't use them?
Posted by Ross at Tue Feb 19 08:28:15 2008:
b) Surely this only screws you up further by assuming you're using a D-Bus-aware mainloop. What if you're using libnotify from an application which doesn't make D-Bus calls in its mainloop, because it doesn't use them?
(a) Doh. Fixed
(b) libnotify makes its own connection to the bus and then makes blocking calls, so you can use it in applications which don't use dbus or glib. The flip side is that breaks applications which do use dbus and glib a lot. :/
Luckily I was only using the basic interface, so I replaced it with dbus_g_proxy_begin_call.
(b) libnotify makes its own connection to the bus and then makes blocking calls, so you can use it in applications which don't use dbus or glib. The flip side is that breaks applications which do use dbus and glib a lot. :/
Luckily I was only using the basic interface, so I replaced it with dbus_g_proxy_begin_call.
