QtDBus bindings: transparent usage
thiago at kde.org
Mon Oct 16 07:13:46 PDT 2006
Sebastian Trüg wrote:
>I have a frontend library that hides DBus (thus, in theory once could
> replace dbus with something else without changing the API). This is no
> problem as long as I am just using clients that call methods. However,
> if I want to export methods I have a little problem becasue these
> methods need to be inserted into an AbstractAdaptor which will not be
> available in the API.
>Is there a clean way to handle this? Maybe using some meta-object magic?
You can easily export slots, signals and properties of any given QObject.
So, I recommend that you use that method of construction: create your own
hierarchy of QObject with the exportable methods.
[Hint: making them Q_SCRIPTABLE and using the ExportScriptableSlots flag
makes it easy to distinguish which slots are meant to be exported.]
Note, however, that there are some limitations on what you can hide from:
the QtDBus demarshaller works in a lazy mode, which means that any
complex that is not integer, double, QString, QByteArray or QStringList
(or a QVariant containing any of those) will not be decoded until much
later. This means it requires some help from the application code itself
to do the decoding -- especially in the case of QVariants.
If you don't need any other type, you should be reasonably safe, though.
(Just don't ever try to access QObject::sender())
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20061016/d41a61a8/attachment.pgp
More information about the dbus