A common roadmap

F@lk Brettschneider gigafalk at yahoo.com
Tue Apr 2 11:47:03 UTC 2002


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?

Ciao
F at lk

P.S.: Actually, the April joke I read on www.kdevelop.org isn't very funny...



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com





More information about the KDevelop-devel mailing list