A common roadmap

[Richard Dale]

On Tuesday 02 April 2002 10:45 am, gigafalk at yahoo.com wrote:
> John Firebaugh wrote:
> > On Friday 29 March 2002 7:29, Roland Krause wrote:
> > > --- Matthias Hölzer-Klüpfel <mhk at kde.org> wrote:
> > > > But you will have to pay this with a lot of extra work. I don't think
> > > > that you
> > > > can not use gideon for anything, I rather think it is "almost there".
> > >
> > > No, it is not even 10% of the way. There are a few people here who use
> > > KDevelop on a daily base for payed work. Ask them. Gideon is nothing
> > > more than a proof of concept. Of course that is only my opinion.
> >
> > I have to agree. Although I was encouraged by Matthias's recent work to
> > integrate QextMDI, I was once again disappointed upon trying out gideon.
> > Roland is not exaggerating when he says gideon is not even 10% of the
> > way.
> >
> > Perhaps some of you have read Joel Spolsky's articles about rewriting
> > software. If not, I'd encourage you to do so. In particular, these two:
> >
> > Things you should never do, Part I:
> > http://www.joelonsoftware.com/articles/fog0000000069.html
> >
> > What to do instead:
> > http://www.joelonsoftware.com/articles/fog0000000348.html
> >
> > KDevelop 2.x is useable because it has polish. It has years of work by
> > many many people implementing small but important features that when
> > added together make a product that is comfortable to use. Things like:
> > loading a project when it is imported from an existing directory, menu
> > items to toggle all the views and toolbars, properly working session and
> > project restoration, good looking and complete config dialogs, tons of
> > documentation and help, configurable key bindings, well laid-out menus,
> > working view management, nice icons, a better project import process,
> > tons of usability fixes, etc, etc. It is these small things, this polish,
> > that we throw away by moving to gideon, not to mention hundreds of
> > thousands of user-hours of testing and thousands of bugfixes. These
> > things are not portable. Individually, they may be trivial to implement,
> > but the sheer number of them is overwhelming. Put simply, it will take
> > too long, and throw away too many peoples' hard work, to get gideon to
> > the level that kdevelop 2 is now.
> >
> > My vote is to continue to refactor and clean up current KDEVELOP_2_BRANCH
> > code, always moving toward gideon's modular nature.
> >
> > later,
> > John
>
> The current situation reminds me of a neverending stalemate in a chess
> game. We discussed about the suggestion of porting the Gideon plugins over
> to the stable core of KDevelop2.2 and meanwhile MHK worked and improved the
> Gideon core by adding the QextMDI feature. A pretty nice piece of work (I
> salute MHK) but it again divides both KDevelop parties. Maybe if we don't
> find a solution now a cvs split of the team and of the cvs modules (in
> cvs-module gideon, kdevelop and kdevbase) is better for the whole KDevelop
> project?
I think we seem to have got enough developer energy to work on two IDEs at 
once.. 

Is it ok to add multiple language support to KDevelop 2 now - would anyone 
mind if I ported my Objective-C and Java class parsers to it? I don't think 
it would take long. I can do it as a patch rather than commiting it to the 
cvs, so it can be reviewed.

-- Richard