KDevelop team interview

[Bernd Gehrmann]

On Wednesday 15 May 2002 10:04, you wrote:
> > I think Gideon has a very well designed and matured
> > structure. And that's from
> > the beginning :-). It's written like an IDE (or an
> > application in general)
> > has to be written.
> >
> > What's missing are 15-20 developers ;-)...
> >
> > If you want a more technical answer just say "Yup" :-)
>
> Yup!
>
> What makes Gideon so promising ? If Gideon is so different/new, how can it
> be possible that its kpart might be reusable in standard kdevelop ?

Perhaps it can be that this claim is just a cheap marketing gag? ;-)

Gideon's structure is really very different from KDevelop. It is designed for
extensibility to the core, i.e. almost all core functionality is provided by
plugins, and consequently plugins can use the same interfaces to other
components as any core component. That's why the interaction between
components must follow a very different model than in a monolithic 
application. To give you two examples:

What happens if you right-click on a tree view in KDevelop? The tree view
will insert some items into the context menu. If the user chooses one of
them, the tree view invokes the corresponding function in the correct 
component. In other words, KDevelop uses a push model. A tree view 
must know *each* component that is responsible for context menu items.
It is clear that such a model does not allow for plugins to extend the context
menu. In contrast, Gideon follows a pull model. When the user opens the
context menu, the tree view shouts "Listen everybody! The user has clicked
on a file". All plugins offering file-related functionality listen to such a 
message and insert their items into the context menu. You see that the tree 
view in which the context menu has been opened doesn't have to know 
*anything* about other plugins.

This difference in design is not only important for extensibility, it also 
has a big practical advantage. Experience with developing KDevelop shows that
the bottleneck for the communication between different subsystems of the IDE
lies in one class. Every time you change even a small thing, you have to 
recompile all files that include the header file that defines this class. In 
the times of KDevelop 1.0betaX, this frequently led to compilations of half an
hour, which was totally frustrating. In Gideon, mere changes of some 
implementation *never* require the compilation of files outside of the 
affected plugin. You only have big recompiles when an interface changes, and 
that is relatively rare.

Another example are the language specific features. In KDevelop, whenever the
IDE thinks that the language parser should be invoked, it calls the 
appropriate function. In Gideon, this is impossible, because the language 
support part of the used language decides itself when it starts to parse. And 
in fact, this is done in different ways for different languages: C++ is only 
parsed when a file is saved, as the parser is relatively slow (with increasing
processor speed, this may change sometime). PHP has a realtime parser, i.e.
is updates each time the user modifies a file. Docbook has a 
"delayed-realtime" parser, i.e. it starts to parse when the editor is idle 
for a second or so.

Bernd.