Moveing KDevelop from python

[Bernd Gehrmann]

On Monday 06 May 2002 15:08, you wrote:
> On Monday 06 May 2002 08:29 am, 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
>
> heh, yeah i went that route once too... Qts introspection is good for
> generateing quick and unsuable dcop interfaces (see the KMainWindow dcop
> interface generated by QObject introspection.)   I have found that the best
> way to do dcop is to think out what methods you wish to expose and to write
> them explicitly.  Most people dont realise but it is very hard to deal with
> most advanced Qt types in a portable manner.

So? What are the advanced data types in KMainWindow? int or QCString?

> never heard of it but, we have KScript in kde allready, to simplify this
> process, no need to re-invent over and over again.

Why are you reinventing then? :-) I wonder also what you mean by "KScript". 
If you mean what is in kdelibs/interfaces/kscript, then all the functionality 
that's in  there is provided by Options->Tools in KDevelop for some years 
already.

The scripting part in gideon goes far beyond that. It allows scripts to retain
state. It allows scripts to connect to signals. For example, you can connect
to the projectOpened() signal and execute a function whenever a project
is loaded.

> actually when used properly it is not a problem, and really dosent add any
> real weight to the application.  maby at build time, but you either pay now
> or pay later.

No, you always pay. Wrappers of any kind that are not automatic suffer from 
bit rod over time. See also the java bindings for an excellent example. That's
why I already mentioned this before.

> Then this should be easy to convert to KScript... seeing as KScript
> currently doesnt kill X on exit and the current parts/scripting/* does this
> should be a win win situation.

If my X would be killed, I would try to fix X.

Bernd.