IDL language

[Thiago Macieira]

Em Segunda-feira 11 Maio 2009, às 15:29:01, Colin Walters escreveu:
> On Fri, May 8, 2009 at 3:23 PM, Thiago Macieira <thiago at kde.org> wrote:
> > Em Sexta-feira 08 Maio 2009, às 17:14:01, David Zeuthen escreveu:
> >>  o  No-one really installs introspection XML anywhere. And if they did,
> >>     it would probably be a dialect anyway.
> >
> > $ ls -1 /usr/share/dbus-1/interfaces | wc -l
> > 17
> > $ ls -1 $KDEDIR/share/dbus-1/interfaces | wc -l
> > 120
> >
> > That doesn't count as "no-one".
>
> Can you describe a bit how KDE works now?  Do authors hand-write the
> introspection XML?  Or is it extracted from the code somehow?

Both cases are valid.

There's a companion tool to qdbusxml2cpp which is called qdbuscpp2xml. It 
parses a C++ header and produces XML. However, that tool is limited to simple 
types. It also can't generate any kind of decoration (besides the built-in 
ones), which means we can't keep non-Qt annotations suitable for other 
bindings.

The CMake scripts that KDE uses have automatic generators for those. Given a 
.h input file, it can produce the .xml which will then be used to create the 
Adaptor (server-side) and the Interface (client-side) classes. The .xml is 
then installed.

So, for simple things, it works:
$ cat test.h
#include <QObject>

class MyClass: public QObject
{
    Q_OBJECT
    Q_CLASSINFO("D-Bus Interface", "com.example.MyInterface")

    Q_PROPERTY(int iProp READ iProp)
    Q_PROPERTY(QString sProp READ sProp WRITE setSProp)
public slots:
    void Method1();
    int Method2(QString);
    QDBusObjectPath Method3(int arg1, int arg2, qlonglong, QByteArray arg4);
    void Method4(SomeComplexType);
signals:
    void Signal1();
};

$ qdbuscpp2xml test.h
<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" 
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
  <interface name="com.example.MyInterface">
    <property name="iProp" type="i" access="read"/>
    <property name="sProp" type="s" access="readwrite"/>
    <signal name="Signal1">
    </signal>
    <method name="Method1">
    </method>
    <method name="Method2">
      <arg type="i" direction="out"/>
      <arg type="s" direction="in"/>
    </method>
    <method name="Method3">
      <arg type="o" direction="out"/>
      <arg name="arg1" type="i" direction="in"/>
      <arg name="arg2" type="i" direction="in"/>
      <arg type="x" direction="in"/>
      <arg name="arg4" type="ay" direction="in"/>
    </method>
  </interface>
</node>

As you can see from the output, the Method4 is missing because the parser 
doesn't know what to do with the "SomeComplexType" type.

If this class were used in an application, at runtime the XML generator code 
can query the SomeComplexType class for its D-Bus type signature. But the tool 
can't do that.

This is caused by our trying to parse C++ code. Since the signatures are 
generated by code, we can't find them out unless we run the code. Compiling to 
IDL wouldn't change anything.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Software
      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: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090511/afc8a812/attachment.pgp