Qt-DBUS (was: KDE4's IPC)

[Kevin Krammer]

On Sunday 25 December 2005 13:49, Thiago Macieira wrote:

> Our options are:
>
> 1) write the interface inheriting from QObject
> Pros:
> - easier to write (mostly done already)
> - can be parsed from moc
> Cons:
> - cannot be fully inline, due to _EXPORT restrictions (that is, it has to
> belong to at least one library). In fact, I doubt the .h file containing
> the QObject-derived definition can be installed at all.
> - the object implementing this interface can only have one interface
> - it has to derive from this interface and none other (cannot do your
> FooApplication above)
> - the skeleton class won't inherit the interface definition, it'll
> reimplement it!
>
> 2) write the interface without inheriting from QObject
> To do this, we'd have to throw away the current bindings and start from
> the scratch, since the base object won't be a QObject anymore and cannot
> benefit from the Qt Meta Object system.
>
> Unless you want us to start over, the FooApplication above will have to be
> modified so that, instead of inheriting KIMIface itself, it'll have an
> object that does.

The bindings could just use a basic interface to relay method calls to and one 
implementation of said interface could be a QObject adapter that maps to slot 
calls like the bindings currently do.

This way you can utilize QObject if you like but are still free to implement 
non-QObject service objects.

Additionally the QObject adapter could allow to have fine grained access 
restrictions on available slots, etc

Cheers,
Kevin

-- 
Kevin Krammer <kevin.krammer at gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtforum.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051227/ed4f84d6/attachment.sig>