Moveing KDevelop from python

Simon Hausmann hausmann at kde.org
Mon May 6 16:35:05 UTC 2002


On Mon, May 06, 2002 at 03:22:50PM +0100, Richard Dale wrote:
> 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? 

Although not publically documented they are guaranteed to work
across the 3.x series as any change on them would break binary
compatibility (all the moc generated code uses that API) . It's
probably just that it's not a very Qtesque API (it's tricky to use),
hence the omission from the API docu.


Simon




More information about the KDevelop-devel mailing list