QtDBus bindings: transparent usage

[Sebastian Trüg]

On Monday 16 October 2006 16:13, Thiago Macieira wrote:
> 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.

But I need to know the methods of that object at compile-time, right?

> [Hint: making them Q_SCRIPTABLE and using the ExportScriptableSlots flag
> makes it easy to distinguish which slots are meant to be exported.]

How do I use that? Just like so:
Q_SCRIPTABLE QString whatever();

> 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())

that is no problem. I am sticking to simple types anyway.

Cheers,
Sebastian