Moveing KDevelop from python

[Richard Dale]

On Monday 06 May 2002 3:34 pm, Simon Hausmann wrote:
> 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.
I would have thought it's easier to use slots/signals to hook up to an 
instance of a QObject that you didn't know about in advance. Have a 
'ScriptingProxy' class with a variety of useful signal arg types to cover 
what is used in the slots in the KDevelop api. And emit signals from the 
scripting proxy to invoke target KDevelop actions. For example, this sort of 
thing:

class ScriptingProxy: public QObject
{
    Q_OBJECT
public:
    ScriptingProxy();
    ~ScriptingProxy();();
    void emitArgs();
    void emitArgs(int);
    void emitArgs(const QString&);
...
signals:
    void signalKDevelop();
    void signalKDevelop(int);
    void signalKDevelop(const QString&);
...
};

void emitArgs() {
	emit signalKDevelop();
}

void emitArgs(int arg) {
	emit signalKDevelop(arg);
}

void emitArgs(QString & arg) {
	emit signalKDevelop(arg);
}

..
// Use QMetaObject::slotNames() on aKDevelopInstance,  to find 
// 'doKDevelopAction(int)'

myScriptingProxy = new ScriptingProxy();
connect( myScriptingProxy, SIGNAL(signalKDevelop(int)), 
             aKDevelopInstance, SLOT(doKDevelopAction(int)) );

myScriptingProxy->emitArgs(anIntegerSentHereViaDCOP);

-- Richard