On March 6, 2002 01:35 pm, Roland Krause wrote:
> >    4. release policy after KDevelop-2.1 (F@lk Brettschneider)
>
> I was going to hold back on this until we have a release since we
> should focus now on fixing bugs.
>
> Anyway, here are my personal plans for KDevelop KDEVELOP_2_BRANCH after
> the release of KDE-3.
>
> KDEVELOP_2_BRANCH is about 90% converted to use KAction and KStdAction,
> thus making it compliant with other KDE-3 parts. The menu is completely
> based on KActions. I am working on the toolbars which is mostly editing
> the kdevelopui.rc file and I have decided to discard the current
> statusbar code and replace it with gideon's statusbar.
>
> KDEVELOP_2_BRANCH is also theoretically ready to use gideon plugins. As
> a first candidate for a backport of a gideon plugin I looked at the
> gideon tools, since that is real easy to implement and doesnt really
> use any internal datastructure.
>
> Therefore I have made a little development outline for myself:
>
> 1 Finish up all KAction work.
> 2 Move docViewManager into it's own directory.
>   Then replace/enhance it with Kate documentManager and viewManager.
> 3 Use gideon statusbar, throw out current code.
> 4 Port gideon's or katex's plugin/part manager.
> 5 Create directories for gideon plugins in cvs and port one or two
>   gideon parts/plugins. I've thought of the project manager and the
>   build system, since they both really suck in KDevelop-2.
> 6 Improve kate part integration.
> 7 There was something here that I cant remember...
>
> So far this is just what I am going to do for myself, I know, a few
> people here are going to stay on the KDEVELOP_2_BRANCH also. For all of
> us that would like to have a stable and working KDevelop and at the
> same time do not want to loose work they invested in gideon I want to
> propose the following.
>
> Lets take a close look at all gideon parts and plugins and sort them in
> one of three categories as follows:
>
> "core parts"
> These are parts that KDevelop will not work without. They are mandatory
> and they are loaded immediately after the program is started and are
> guaranteed to be there. I.e. other parts/plugins can rely on these
> parts being there. E.g. the "kate editor part" is a "core part" so is
> the "KHTML part". All developers are in charge and maintain core parts.
> The APIs of core parts are well documented.
>
> "supported parts"
> These are parts that can be configured to load, they can be unloaded
> while the program is running and they can be exchanged for
> alternatives. No other plugins/parts should depend on them. E.g. the
> "API doc part" could be a supported part. One or more developers are
> repsonsible for maintenance of a "supported part". API's of "supported
> parts" are documented.
>
> "usupported parts"
> These are all parts for which we have source code and that wont fall
> into the other categories. Also "beta" plugins/parts can go in here.
>
> Then lets take a close look at existing KDevelop funtionality, much of
> which has been continuously improved with literally hundreds of patches
> over the last year and lets take things one by one and integrate with
> each other.
>
> Roland
I agree with that.
Something that I think will be usefull is to build gideon parts as a 
standalone project. I'm looking to add this, along with my palm dev support.
Mathieu
-- 
Graduate students and most professors are no smarter than undergrads.
They're just older.


_______________________________________________
Kdevelop-devel mailing list
Kdevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel