Moveing KDevelop from python

[Bernd Gehrmann]

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.

dcopidl is something that be should be buried deep under the face of
the earth :-) It's unnecessary, it causes bloat and additional maintainance
burden.

> The next step would
> be to add a script manager.  The plus side of this would be we dont have to
> mess with embedding python and the mainnance of the python interface. 

There is no python interface. The script in parts/scripting/init.el just uses
pydcop. This is a generic client side implementation of dcop which is
entirely independent of gideon.

Bernd.