Request for the 1.0 release
thiago.macieira at trolltech.com
Sun Feb 26 04:18:48 PST 2006
Havoc Pennington wrote:
>On Sun, 2006-02-26 at 02:48 +0100, Thiago Macieira wrote:
>> It works if the bindings play nice with each other. Currently, we
>> don't. We don't register the objects because the tree is dynamic and
>> can change without calling "registerObject".
>I'm not sure I understand all the issues - do you think this is
Maybe. It's not a high priority in my TO-DO list.
>Is the problem you can't reliably tell if another binding registers the
I've got two trees here: the object tree registered with registerObject
and the tree that the registered objects bring with themselves: QObject
objects are organised in a tree themselves, so the user can use
the "ExportChildObjects" flag.
And that tree is out of my control: it can change at any time, so I cannot
register it with the D-Bus library.
A simple solution to this would be to namespace all the objects the
>get_interface() is something you call on the proxy itself, not on the
>signal; so you'd always get whatever interface you created the proxy
>with (the dbus interface name of the remote object). If a remote object
>has two interfaces, with DBusGProxy you have to create two proxies, or I
>think you can just pass in NULL for the interface (which will then omit
>it in the DBusMessage as well).
Ok, I understand. The "destroyed" signal actually means that the (service,
object, interface) tuple is no longer available, instead of the (service,
>DBusGProxy does not map remote signals to regular GObject signals,
>instead there's a special dbus_g_proxy_connect_signal() that you use
>instead of g_signal_connect() for remote signals. To map remote signals
>to regular GObject signals, a new proxy *class* would have to be
>generated for each remote object, while right now the proxy instances
>all have the class DBusGProxy.
I have a similar situation here. I pondered doing that on my way home last
night, but I came to the conclusion that it's more trouble than it's
worth. And, besides, the correct behaviour of a QObject cannot be
reproduced (objectDestroyed signal, deleteLater slot, setParent, setName,
So I'll stay with my current light-weight wrappers (proxies).
Thiago José Macieira - thiago.macieira AT trolltech.com
Trolltech AS - Sandakerveien 116, NO-0402 Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060226/947d126a/attachment.pgp
More information about the dbus