Moveing KDevelop from python

[ian reinhart geiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.  It is best to make sure all 
types are cleaned up and as simple as possible.  The other problem is Qt 
properties are an all or nothing deal, once you start to "filter" them it 
gets messier than just doing it the right way the first time.

> 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
never heard of it but, we have KScript in kde allready, to simplify this 
process, no need to re-invent over and over again.  I wrote KScript with 
kdevelp in mind.

> 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.
Yes, see above why this is a bad idea.  It gets even worse when you have 
container classes or wish to provide frontends to complex functions that 
provide feedback.

>
> 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.
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.

>
> > 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.
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 you would like to talk about this on IRC let me know and I can fill you in 
with how this works.  Currently the scripting_part provides the same concept 
s the scriptmanager that would be needed for KScript.

Cheers
- -ian reinhart geiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE81oBWPy62TRm8dvgRAkG6AKCloUqI4UA9Ck0DRypyktNIBP7akgCdFpr7
0XQ5RrKeXVEbocJ+NqhAbgs=
=R+DN
-----END PGP SIGNATURE-----