ANNOUNCE: New KDevelop Design

[Ralf Nolden]

Hi again,

I'm back !!!!

;-) 

Now, to this subject I will give my 2 cents as a KDevelop
core-developer:

a) Sandy is a man.
b) he is not dead or unavailable, just busy working on the new
plugin-structure/modularization.
c) he has received Mr. Climov's mail about the "New design"
d) we have talked about it
e) we are not yet finished to find an agreement because of the simple
reason that we don't know where this thing comes from
f) I just answered Sandy to reply on the mailinglist to clear out some
things
g) I wanted to answer yesterday already, but had no time ;-(
h) here comes my statement :

A)
As far as the questions of Mr. Climov go regarding a "New design" for
KDevelop, we have the following situation:

The KDevelop Team as a team of independent individuals, but organized in
the development of the KDevelop IDE, started and still runs the KDevelop
IDE project. This will not change and the project will continue. 

If developers that use KDevelop take the codebase and change it to adapt
new things like the debugger, this is fine with each core-developer,
including myself. Making the patches available is nice and serves
everyone, but it is not part of the official development state which is
found by consent of the core-developers in regular intervals where we
meet and discuss directions. The stability of the IDE requires this and
prevents code-changes that could be hard to reverse in the future.

The current state of the development is that we're fixing the 1.0
version, so that it is almost bug-free considering the desired state.
Therefore not many features are added officially, because we want a
rock-stable 1.0.  In parallel, we're porting to KDE 2 and have to take
the pace for the changes in the KDELIbs API to offer developers the 1.0
in a KDE 2 version for their development. In this, we're making good
progress.

New features get implemented now as well. We're testing the MDI
interface, the dockwidget interface and so on, but have to take care of
the 1.0 and HEAD branch to keep them in sync. Also Sandy promised to fix
a bug in the project management of HEAD and will have finished the new
plugin API for KDevelop plug-ins by this weekend.

KOM/OP architecture functionality will also be added, but is delayed for
some weeks until HEAD kdelibs have a code-freeze and the status of the
CORBA architecture is cleared, this will add IDL support to KDevelop and
a new Appwizard that will also generate KOffice and KOM/OP frame apps.
The current HEAD version works, including the browser and the
mini-template, the normal and qt template are not yet ported.

Now to the points Mr. Climov mentioned:
> 
> Considering the following facts:
> a. Actual KDevelop has poor modularization; it lacks in (true)
> multi-language and plugin support.
-KDevelop is definitely one of the KDE applications that have the best
API interface, completely modularized and separated into classes. Even
in such a complex codebase, the class hierarchy makes additions easy. 

-Furthermore, KDevelop's internationalization is one of the best
regarding the huge mass of documentation to be translated. There are
some dialogs that will be redesigned anyway, therefore we delayed
implementing geometry management for those that will be changed; the new
ones will have full geometry management support (if that is what is
meant by lack of multi-language support)

-The plugin support will be available this weekend (see above)



> b. The original team is working a lot on improving and bug solving on the
> actual design/implementation. I doubt that they will have time for a
> re-design soon (that would mean that for a long period of time KDevelop will
> mark no visible progress).
- I doubt that there is really a need of redesign. The codebase that is
there is actually the best one could wish to have for a functional IDE.

- we will have time. The last three month have been bug-fixing and a
waiting for KDE 1.1.2 with which KDevelop should have been brought out.
We canceled this plan shortly before the release, so we have more time
for bug-fixing and don't set ourselves under pressure.

- we already have visible progress regarding the porting to KDE 2. I
changed the templates to the new autoconf, just the code needs adaption,
and the documentation browser works again except for a bug when
displaying KDevelop's own documentation.


> c. Such a great tool as KDevelop is MUST have better design and
> modularization.
> We don't want (just) another IDE, we just want to improve KDevelop. We want
> to (re)use the code that was already written. 

To my mind this statement suggests, that your firm located in romania is
trying to take KDevelop out of the hands of the core-developers. If you
were a "normal" developer that would come to us and say: "hey, I can
program and I want to help improve things" like Jonas did, we have a new
core-developer and that's ok. In this case, I think I am right that I
suspect some really black clouds coming. 
The GPL allows code-reuse, so noone and nothing can prevent your
corporation to take the KDevelop code and change it like Corel changed
KDE code for their distribution. And this is what it's going to be like:
we can't work like Mr. Climov suggested. This will split up the codebase
and end up in a fight whose final is better and offers the best
features.

To me, this seems like that we core-developers are dammed by Mr. Climov
to fix bugs and maintain the show, including answering questions of
newbies and taking care of the lists, while they take their time and
build a second version which will be theirs, just like it happened with
KDEStudio.

About KDEStudio, I'm not as pissed off as about this, because if you
look at the code, you see some similarities and it is clear that this is
another IDE but based on our effort. We on the other hand will surely
make use of this or that idea of KDEStudio as we're already testing the
dockwidget. So for the user there will be choice in one or the other
variant of the same code-base. But this attempt is just rediculous as
Mr. Climov asks KDevelop users and developers for their wishes and
plans. Asking me for my wishes is rediculous as I'm going to implement
these plans and additions with the other developers, anything else I
would consider to steal ideas and make a new project even stealing the
name.


And about the manageability of
> a branch and re-merge, it's just a matter of how much we want to do this (in
> fact a matter of interests). And I think that our (common) interests are to
> create the best IDE. In the worst case, we will have two IDE's instead of
> one, at the end :-).
I think this request already led to the worst case- you're offering this
as a thread : if we don't cooperate, you will go on with our codebase
anyway and start you own development. I don't doubt your facilities as a
developer nor the integrity of your corporation, but a thread like this
is unacceptable to me.

I will continue my work on THIS project, on OUR KDevelop.  I want more
developers to work IN our TEAM, not outside with our code on their
project. This is again a waste of resources and will split up users
again as well as developers.


I hope Mr. Climov has good reasons for threatening the core-team and
would be more clear in his way to explain his point of view and what
plan he exactly means. I would like to have developers help, but not in
an extra-team; on the other hand I can understand that he wants to have
his corporation work alone on a project without us. But if that is the
case, I please you to start from scratch by your own. Any other option
is not fair against our team.

Just my two cents.
I hope I didn't offend anyone too much more than necessary and
recommended in this case, as well as I hope that I gave some light from
the official side towards the users of the original KDevelop.


Bye,

Ralf