This means Buddy and its subclasses no longer need to care about
NameOwnerChanged at all.
The old code might not have worked anyway, since it was watching for
NameOwnerChanged on the session bus, but invoking NM methods on the system bus.
This means we don't need to care whether the Sugar shell is actually running -
if it is, we'll get its signals, and if it's not, obviously it can't send us
any signals!
They're not handled in the inherited do_set_property()/do_get_property(), so
won't work as properties, and there seems to be no need for them to be
properties at all.
This fixes the following assertion when importing buddy:
Warning: g_object_class_install_property: assertion `pspec->flags & G_PARAM_WRITABLE' failed
type_register(cls, namespace.get('__gtype_name__'))
It shouldn't have been applied before "services/presence: buddy: add mapping
to/from Telepathy handles" which has not yet been reviewed.
This reverts commit 78356b1956.
Conflicts:
services/presence/presenceservice.py
This causes events in the log to be annotated with the module that emitted the
message.
Before: DEBUG - root: Starting up...
After: DEBUG - s-p-s.server_plugin: Starting up...
I've used a log domain of "sugar.presence..." for the client library and
e.g. "s-p-s.activity" for the service internals.
This owner changes properties periodically so we can test out the PS's handling
of property changes. To execute, run Sugar and then make sure that the D-Bus
address is the one sugar is using (get it from ~/.sugar/default/session.info).
Then run:
build/bin/sugar-presence-service X
where X is a number 1 -> 9 inclusive. It will generate fake buddy info for that
test buddy and then start up a presence service for that buddy, changing a random
property of the buddy every 10 seconds.
