hal_initialize() overrides other filter/object/fallback
functions on separate connection
David Zeuthen
david at fubar.dk
Mon Aug 9 12:01:34 PDT 2004
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
More information about the dbus
mailing list