hal_initialize() overrides other filter/object/fallback functions on separate connection

[David Zeuthen]

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.

Thanks,
David
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal