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

[David Zeuthen]

On Mon, 2004-08-09 at 20:47 +0200, Kay Sievers wrote:
> > > Wait, I think the fact that signals *from* /foo/bar go to the object at
> > > /foo/bar is completely accidental ;-) Does that even make sense?
> > > 
> > 
> > Not really, because how would you specify what service and interface you
> > want signals from? I suppose that it would be good to state in the docs
> > that dbus_connection_register_object_path() is only to be used for
> > handling methods on the callers own objects. 
> 
> Hmm, I get _all_ signals from the objects I subscribe to. I've added a 
> register_object to the python bindings and get all signals sent from
> /org/freedesktop/Hal/Manager. This works for me:
> 
> dbus.py:class Bus
>   def add_object_match(self, handler_function, path):
>         match_rule = "type='signal',path='%s'" % (path)
>         dbus_bindings.bus_add_match(self._connection, match_rule)
>         self._connection.register_object_path(path, None,handler_function)
> 
> DeviceManager.py:__init__
>         self.bus.add_object_match(self.gdl_changed,
>                                   "/org/freedesktop/Hal/Manager")
> 

Yah, that's the current behaviour. However, I think that the point was
whether it was actually smart to mixup the namespace for objects you
export yourself (which you have exported through register_object_path)
with the signals you're interested in receiving.

Cheers,
David