Ok, let's start with a bit of history: In late summer 1999, we branched
kdevelop in order to port it to KDE 2. At the KDE Two, Sandy and me began
adding new features to it while the old branch was bugfixed for the 1.0
release. In the following months, not very much happened, with the con-
sequence that last summer we had a HEAD branch that was quite buggy 
(because bugfixes were commited only to the 1.x branch) but had some 
features more (except for the debugger). 

Then came the big cut. The HEAD branch became a vision of an IDE that
would solve all the problems one could imagine (including world hunger
and pollution). Unfortunately, such visions have a big problem: It
needs a lot of time and patience to realize them. In the world of
free software, the situation is even worse: as long as there's a
branch of a program that works (even if it doesn't work very well),
there's little reward in working on a branch that crashes on the
first startup, lacks essential functionality and doesn't look like
it gets completed any time. Sometime in january of this year, it was
very clear that the HEAD was dead, just that everyone was too much
of a coward to openly admit it. 

Since I thought it would be a pity to completely abandon the very nice 
code in HEAD, I decided to bring it into a state that it could compete
with the 1.x branch both in terms of stability and features. Only that
can motivate people to finally bury the old stuff. The only possible
way I saw was to turn the whole code upside down, remove everything
that couldn't be completed in a finite time, remove stuff that was
too ambitious or that I don't understand and replace it with something
that works. And of course, for my own motivation, I added lots of
useful, fancy and neat features :-) I'm fully aware that some people 
will be pissed by me removing their code, and I'm very sorry about that
(and in particular I would really like to see Sandy's work on the
application wizard merged back), but I don't think it was avoidable.

So what do I have now? First, a modular lego-like framework for an IDE
that could be used to build a C++ IDE, a Python IDE, or even a web
development platform (no, I'm not suggesting the latter ;-) In the
second place, a number of 'part's that make use of the framework and
form a complete C++ IDE. That is:

The core application: a kwrite-based editor and a khtml-based
documentation browser. Any number of views per document can be
arranged in a grid of non-overlapping windows (in the tradition
of Emacs and Konqueror). The editor supports incremental search.
Files can be loaded by a KURLCompletion line edit, without popping
up annoying dialogs. To edit header file foo.h, just move the cursor 
over a #include "foo.h" and choose 'Goto include file' from the
context menu. To look at the manpage of printf, move the cursor
over printf and choose 'Goto manpage' from the context menu.

The documentation tree: makes kdoc-generated documentation of
kdelibs and the current project available, also includes the
libc and stl documentation and the KDE2 development book.
The last three can also be accessed by their (concept, function
and file) index. Full text indexing is done through a variant
of khtmlindex from khelpcenter.

The class browser: The class tree can arrange identifiers both
by category (class, variable) and by namespace. The class tool
is still there, and a graphical browser based on the wonderful
graphviz package that can nicely visualize multiple-inheritance
structures.

The project management: is currently based natively on Makefile.am,
that means no additional project file is necessary, no cvs 
conflicts on the project file have to be merged, and so one
(of course, for user-specific customizations, there is still a
xml-based project file). It also supports programs, libraries,
libtool libraries, scripts, data in an arbitrarily nested di-
rectory hierarchy. So except for conditionals in Makefiles,
this should make everyone happy :-)

The application wizard: currently includes variants of 
Kurt Granroth's kapptemplate templates. New templates can
be added by simply adding a short perl script and a
KSimpleConfig configuration file. Of course, this could also
be improved to support additional variables which are pre-
sented in the user interface, etc.

Scripting: For this, a part functions as a proxy to an embedded
python interpreter. It's by far not complete or even useful,
but it's already possible to generate menu items from python...

Anything I forgot? :-) Well, most importantly, most of the
code is modular, extensible, clearly written and maintainable.

Oh, and everybody loves screenshots:

ftp://ftp.kdevelop.org/incoming/gideon1.png
ftp://ftp.kdevelop.org/incoming/gideon2.png
ftp://ftp.kdevelop.org/incoming/gideon3.png
ftp://ftp.kdevelop.org/incoming/gideon4.png
ftp://ftp.kdevelop.org/incoming/gideon5.png

Last not least, the sources :-)

ftp://ftp.kdevelop.org/incoming/gideon.tar.gz

Hope you like it,
Bernd.