ANNOUNCE: New KDevelop Design

[Catalin Climov]

----- Original Message -----
From: Ralf Nolden <Ralf.Nolden at post.rwth-aachen.de>
To: <kdevelop at barney.cs.uni-potsdam.de>
Sent: Thursday, September 30, 1999 2:12 PM
Subject: Re: ANNOUNCE: New KDevelop Design


> 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.
ACK.
> b) he is not dead or unavailable, just busy working on the new
> plugin-structure/modularization.
well, ...
> c) he has received Mr. Climov's mail about the "New design"
and never answered :-)
> 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.
That's why we want to branch (fro a period of time).
>
> 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.
I know the sources quite well (I've been studying them for the last two
months :-)). And I don't think that the additions are easy to made, and I
don't think it has an API in the true sense. And I will give an example.
Let's suppose you will make a "KDevelop developer how-to". It's easy to
imagine how it will sound like: "To implement Java support, hack a little
CKAppWizard, add your project type(s) to the tree-view of the wizard, add
your new pages (or hack the existing ones, putting everything that varies
under some nice switch-case structures :-)). Then take care to
disable/remove the pages you don't need each time the user chooses your kind
of project, but don't forget to re-enable them in case that user changes his
mind and chooses another type of project. And don't desperate: the fun just
follows! So, if your project needs a (less or more) different set of
settings you have more alternatives:
1. Inherit you project class from CProject (a perfect name for a perfect job
:-). What does that "C" stands for: "C"lass or "C" language? How should I
call my Java project: JProject or CJProject, in order to be consistent ?).
Now implement all you need for a Java project, and don't forget to grep all
the sources for "CProject", study them a little and decide where should you
insert switch-case to choose between CProject and CJProject :-). It's easy,
isn't it (after all you're a hacker, since you want to mess with Kdevelop)?
2. Decide which settings are not needed for Java and reuse them in order to
store Java related settings. But be carefull to insert switch-case wherever
needed.
3. Add new member variables for each new setting, ignoring the other ones
you don't need. This way you will avoid clashing, and it doesn't really
matter if the size of CProject will grow each time a new language is added!
" (end of how-to)
Or it (how-to) might sound like: "Create your own Java project wizard,
inheriting the KDevProjectFactory (abstract class), and don't forget to
register it to KProjectFactoryManager (using an API call like:
KProjectFactoryManager::registerProjectFactory(new JavaProjectFactory());).
You may start your implemetation from the default implemetation provided
with KDevelop SDK. Implement you own KDevJavaProject inheriting either from
KDevProject (abstract) class, or from KDevCppProject (if it is more
appropriate). Make sure that KDevProjectFactory returns a KDevJavaProject.
There is no need to change any of the KDevelop core code."

Don't get me wrong, I don't mean that the actual KDevelop is bad coded, it
is just not very well structured. And that's where we want to help.
>
> -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)
I saw the plugin support and it is not what I was expecting. IMHO, what you
call "plugin support" is just an "official" way to add more hacks to
KDevelop. I was thinking that almost everything in KDevelop (views,
projects, wizards, etc) should be implemented as a plugin/module, except for
a small part which will be the core. And this cannot be done without a
complete redesign, from ground-up.
>
>
>
> > 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.
Well my team has nothing to do with the company I'm working for in romania.
Like most of you, I have a full time job (at that company in romania), and I
work for KDevelop in my free time. No one wants to take KDevelop away from
you and make it a propritary tool.
This time I will not consider your behaviour as being egoistic, but rather I
will think of it as a way to defend your work from a "firm located in
romania (that) is trying to take KDevelop out of the hands of the
core-developers".
First time we thought that we should use "closed doors" development, and
only after we finish make our work public. Then we reconsidered, and decided
that helping KDevelop is far better. So we tried to contact you (first
Sandy, and then the list), tried to be open (the fact that I will try to
reply every mail on this subject is a proof of that), and now what we got ?
I door closed right in our nose. And that's what you call "Open Development"
?
I will try to be patient and not to flame anyone, but with these reactions
from you, I think we will reconsider our plans...
>
> 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.
:-). No,no,no. Again, we just want to brach for a short period of time,
until KDev 1.0 is released, and you solve all the bugs. Then we will come
with (good) docmentation on what we have done, and try to merge the
branches. In order to make things easier, we will synchronize all our work
with your lates sources on a daily bases.
>
> 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.
Are your flames on today :-) ? Calm down.
>
>
> 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.
Your wrong. If WE don't cooperate, we will just start it from the very
beginning. We don't want to "steal" from you :-). We respect you and your
work too much (that's true).
>
> 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

I hope I didn't offend you too much with my answer, and I hope you will
reconsider your oppinions and decide who is more important: the user or the
core developer :-) ?

Regards,
XXL.

BTW: don't bother to reply to this mail, if you don't turn off your flames
:-). I don't want to change my (very good) oppinions about KDev developers.