A common roadmap

[John Firebaugh]

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