ANNOUNCE: New KDevelop Design

[Bernd Gehrmann]

>Why do we need an IDE for all programming languages? There are already
>nice IDE's for Java (netbeans,freebuilder,codeguide) and say Python (IDLE).
>And if you want to code for KDE 99% of the users will take C++, or? 

Because they don't know Python :-)

Restructuring KDevelop is not (or not only) a question of
support of different languages. It's also a question of maintainability.
Currently much functionality is concentrated in the class CKDevelop
which doesn't necessarily belong there. For example, it "knows" too
much about all the widgets in the main window. The right way to go(tm)
is too make all the components as independent from CKDevelop as possible.
That's what I am currently working on. After that is done, someone who
e. g. wants to implement coloring of error messages can make changes
in the corresponding class, without even caring about the existence
of CKDevelop.

More changes of this kind will happen. The project management is of
course one area. This is the big reason why making branches is a bad
idea: it will not be possible to merge anything after a short time if
several people are working on the same things at the same time. You know
that it has already become a pain to merge things from the 1.0 branch
to HEAD two days (!) after the porting began.

Support for multiple languages/toolkits: It all depends on what one
expects from that. You can do whatever you want, but KDevelop will
certainly not become a viable platform for developing gtk applications.
A well done dialog editor needs native widgets. Using gtk widgets in
a Qt application is not possible. You would have to bring both event 
loops (and possibly MICO's) together. Oh, it is possible (see Matthias'
slides about KIMP) but complicated. But that's uninteresting because
noone will be using it. Glade is in excellent dialog editor (far
superior to any Qt dialog editor, if you ask me). 

Support of multiple languages would become possible in a natural
way if CProject and the class parser are turned into abstract classes
with the `real' classes for languages inheriting it. I don't even
think that this would be tremendously difficult. Again, think about
the drawback: You don't want to write a class parser in C++ when
you can have all the wanted information available in 10 lines of
Python code (yep). In Java, you have the introspection API. How do 
you make use of it in a C++ program?

CORBA: OpenParts is dead. The "master" has spoken, and I expect
the funeral on the next weekend :-) KOM is still living, and it's
the preferred method for scripting. This is only marginally important
for KDevelop (i.e., it doesn't affect the core, but can be implemented
as an additional feature). So if someone wants to do this, IMHO it
would be appropriate to make it optional (by a configure switch).
The reason is that KOM introduces incredible bloat. Compile times
are exploding and would make it impossible at least for me to do
anything productive. Compile and link times are already now too
high for my taste. The interface between KDevelop and the dialog
editor has a design bug: the slightest change in some header file
causes the complete dialog editor to be recompiled. Ugly. It 
would be nice to have the dialog editor as plugin which is loaded
at runtime.

Bernd.