A common roadmap

[Victor Röder]

Hi, Roland!

> Ok, now after this nightmare is over and we actually figured out that
> we like each other 

Sorry, I have to untack this roadmap. I know I haven't done only one percent 
of the work you guys did here and I also don't want to butter you up by 
saying nice words :-) but I need to say my opinion to sleep very well to 
night :-).
This roadmap here is not really useful.
WHAT I UNDERSTAND:
KDevelop2 is a great IDE and is more stable and has a more solid base than 
Gideon. Therefore I appreciate that the development of KDevelop2 doesn't stop 
at a moment's notice so that the users gets a useless and unstable version of 
KDevelop3 (aka Gideon).
WHAT I DON'T UNDERSTAND:
Why changing the code base of KDevelop2 to the one of Gideon? So that it 
might become as unstable as Gideon (although GIdeon is more stable than its 
reputation :-)?

What this roadmap wants do is not to make KDevelop2 stable until the version 
2.2 is shipped but to accept a lot of work in addition the make KDevelop2 
"yet another Gideon".

The changes this roadmap want sKDevelop2 to undergo will not increase the 
stability of that program but holds up the next generation of KDevelop.

> What we need to do:
>
> 1 Finish up all KAction work.
Already done in Gideon.

>   Create Toolbars via KAction.
Already done in Gideon.

>   Port gideon's StatusBar.
Already done in Gideon.

>   Create all context menus via KAction.
Already done in Gideon.

> 2 Move docViewManager into it's own directory.
>   Then replace/enhance it with gideons documentManager and viewManager.
Already done in Gideon.

>   Remove all existing docViewMan code.
Already done in Gideon.

> 3 Port gideon's or katex's plugin/part manager.
Already done in Gideon.


> 4 Improve kate part integration.
>   It doesnt actually merge yet, this needs to be done at the same time
>   when we integrate the new viewManager.
Nealry done in Gideon.

> 5 Start porting all gideon parts/plugins. 
Would be unnecessary.

> Let's get this released with KDE-3.1.
Would be no problem.


> We will then need to find something else to fight about, maybe we can
> discuss the merits of "emacs vs. vi" since we all think the same about
> gnome.

It's a lot more than the merits of "emacs vs. vi".


Bye,
	Victor