hal_initialize() overrides other filter/object/fallback
functions on separate connection
david at fubar.dk
Sun Aug 8 10:35:11 PDT 2004
On Sun, 2004-08-08 at 19:26 +0200, Olivier Andrieu wrote:
> David Zeuthen [Sun, 08 Aug 2004]:
> > > > libhal uses this global filter mechanism to dispatch the signals to
> > > > the registered HAL user functions. Can't libhal (or other libraries
> > > > too) just use dbus_connection_register_object_path() to get called
> > > > at incoming messages for the objects paths it is intersted in?
> > >
> > > Absolutely.
> > >
> > I beg to differ :-). Sometimes you want to listen to all signals
> > regardless of the object path and this is currently only possible
> > with _add_filter() if I'm not mistaken.
> You can register a fallback handler for "/". That should catch signals
> from any object.
OK, thanks, I didn't think of that, my bad. I'll change my code to use
these functions instead of _add_filter(). The documentation for
_add_filter() should state that non D-BUS code shouldn't use it though.
> > p.s. : the doxygen documentation for _register_object_path() is wrong
> Is it because it says '... handles messages sent to exactly the given
> path' ? Well yes, that's a bit inaccurate, it should mention this
> applies to signals sent /from/ the given path also.
Uhm, no, actually not; I misread the documentation for '@param path' and
concluded that it still said it wanted an array of strings. Ugh.
More information about the dbus