[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Porting to D-Bus
From:       Thiago Macieira <thiago () kde ! org>
Date:       2006-06-13 16:35:28
Message-ID: 200606131835.28737.thiago () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


David Jarvie wrote:
>I've been looking at the Wiki guide to porting to D-Bus, but some things
> aren't clear:

Just FYI, Aaron and I will try to write something better during this week.

>1) With DCOP, you needed an interface header file declaring pure virtual
> methods, plus a normal header file for the DCOPObject class inherited
> from it. For D-Bus, is it still necessary to have the interface header
> file? If so, should its methods still be declared as pure virtual?

No.

In DCOP, you had a .h that was processed into a .kidl, which was in turn 
processed into a skel and a stub. The skel and stub classes derived from 
the original class. In order to use the skel, you'd inherit from it in 
your class. (multiple-inheritance)

In QtDBus, you can have a .h that gets processed into an .xml file, which 
in turn is processed into an adaptor and an interface (analogous to skel 
and stub, respectively). However, neither class will inherit from the 
original .h, nor will the final class, so it's never used anywhere. 
What's more, the way this .h is written resembles a lot the adaptor class 
that is produced, so you can skip a step and write the adaptor yourself. 
(and then process it into XML and generate the interface, if you need)

The final class is not derived from the adaptor: you just instantiate an 
adaptor and that's it. Note, however, that the class that receives the 
calls is the adaptor, so you need to write code there to do something 
about it.

Or, do like the generated code does: call parent() and forward the call.

>2) There is mention of the possible desirability to "export the
> scriptable properties" in the D-Bus registration call. What does this
> mean, and when would it be useful?

It means that you can choose to export everything (all slots, signals and 
properties) or only those that you marked as "scriptable". If you're not 
using an adaptor, you generally don't want to export all the slots that 
your QObject-class has.

>3) I've seen some mention of using XML to define D-Bus interfaces. This
> doesn't seem to be mentioned in the Wiki. Is it relevant just now? Will
> we have to port to XML later when it's implemented?

There's a tool that generates XML from a .h. But it's not necessary to 
work.
-- 
Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
  thiago.macieira (AT) trolltech.com     Trolltech ASA
    GPG: 0x6EF45358                   |  Sandakerveien 116,
    E067 918B B660 DBD1 105C          |  NO-0402
    966C 33F5 F005 6EF4 5358          |  Oslo, Norway

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]