QtDBus bindings: transparent usage

[Thiago Macieira]

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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20061016/d41a61a8/attachment.pgp