Moveing KDevelop from python

[Richard Dale]

On Monday 06 May 2002 1:29 pm, Bernd Gehrmann wrote:
> On Sunday 05 May 2002 16:01, you wrote:
> > Bascily the process of doing this will involve adding dcop interfaces
> > pretty much to every important function of KDevelop.
>
> No, that's not necessary. Take a look at a .moc file generated by Qt 3.0
> and you will notice that everything's in there to dynamically invoke
> methods on an object: method names, argument types, return type and even
> the names of the arguments. You don't need any IDL for advertising dcop
> services, you just have to bridge Qt's introspection API to dcop. Take a
> look at Dox, it supports automation from the command line with about 100
> loc, including the implementation of a messaging protocol. For example, you
> can do things like
>
>   dox -remote MainWindow.fileOpen(man://printf.3)
>
> and similar things on other objects. The per-method overhead of this
> interface is exactly zero.
>
> All you have to do is to write similar code which handles calls coming in
> via dcop. That code would lookup the method name via the object's
> QMetaData object. It then iterates over all QUParameters, checks the
> argument's type, uses the appropriate demarshaller for decoding the
> incoming data and QUType::convertFrom() to set the array of parameters.
I don't think these classes are part of the public Qt api though - they aren't 
listed under 'All Classes' in the reference documentation. Only QMetaObject 
and QMetaProperty. Is it less likely to break in the future if you use 
QMetaObject::slotNames(), and then parse the types of the args in the slot 
names? 

-- Richard