KDevelop editor interfaces - ups

[Bernd Gehrmann]

On Thu, 3 May 2001, Roland Krause wrote:

> 
> --- Bernd Gehrmann <bernd at physik.hu-berlin.de> wrote:
> > > That actually applies just as well to the "splitter mode" currently
> > > available in HEAD. The practicality of this "MDI" mode decreases w/
> > the
> > > number of files you have opened at the same time. 
> > 
> > No, you can have 300 files open without that affecting the
> > user interface.
> 
> We are probably speaking of different things here. Let me clarify,  if
> you try to open many files, say 30 to deescalate numbers a bit,
> "splitter mode" becomes just a little bit less useless, than "tiled
> childframe mode". Nevertheless, it's practicality decreases with the
> number of simultaneously viewed files. This is not true for "childframe
> mode" where you can prioritize views. 

No, the splitter mode becomes never useless, regardless of the
number of files you have open. In an IDE, you typically have a 
high number of files open for any nontrivial project. On the other hand,
you do not want to edit or view many files at once. In other words,
these two numbers are on two different scales. The 'Tile' feature ignores
this usage pattern. And of course, it's not a mode, it's an action.
That means, as soon as you enlarge a window, it is likely to conceal
the most important information of the window below, namely its file
name.

> Bernd, I respect your integrity and your opinions. Nevertheless, you
> have no right to comment on my opinions or contributions to this
> mailing lists as "crap".

The statement "It's all there, tested and functional" _is_ crap.
I have already made an extensive list of its shortcomings, and
I haven't even mentioned the most frightening one: since KDevelop
0.3, I have not seen a buggier version than the current 1_4
branch. As soon as you play around a bit with the windows, it's
likely to crash. If it doesn't crash while using, it is likely
to die at shutdown with a couple of double QObject deletions.
And this is not something I am making up or that depends on my
system. Several people have experienced it, so don't pretend that 
you don't know this or you haven't known it when you made that
statement.

You know, I am working on KDevelop now for two years, and I'm
also working on several other projects with different sizes
in tao, fortran, python and perl. In this time I have learned
a lot about software development, and the most important thing
I've learned is that writing a large and complex program is 
very different from writing a small comprehensible program or
a small perl hack. With 50k lines (estimated) KDevelop is
one the bigger open source programs, and it is one without
formal testing and regression suites. That makes debugging
very difficult. If there is a problem in one area of the appli-
cation, it will not necessarily show up there, but in a
different, unrelated area. If memory is corrupted, a crash
may happen at a random time later. If you're trying to find a
a bug related to a double object deletion, it is not helpful if
the debugging message related to your bug is buried in a heap
of other messages from elsewhere. This was one of the most
annoying problems with the old branch. The 1.0 beta phase
was a nightmare.

One approach to solve the problem is to decouple different
areas of an application whereever possible and modularize 
it. In this way, you can - for debugging purposes - startup
only a part of the whole application and isolate problems.
For example, the scripting support in the HEAD is currently
crap. This doesn't matter: you can simply delete its .desktop
file from the installation directory, and it won't get loaded.

However, modularization is not a silver bullet. When modules
interact much with other modules, it is often not worth the
effort to write a test program that isolates them from each
other and allows to run them separately. Other parts may not
be initially separated because of pragmatical reasons (i.e.
it was more straightforward not to do it). One such area is the 
window management and the editor interface in the new and in 
the old HEAD branch (although for a short period of time, there
was something like a view handler component in the old HEAD).

In the old HEAD branch, it was also one of the main headaches.
Over several months, it simply did not work, and noone was
willing to fix its problems. That's why I tried to take a
step back, bring kdevelop into a usable state and _then_
add all the bells, whistles and gong. It was not an easy
decision, but I think now more than ever that it was the
right decision, and others agree. In contrast to the myths
some people like to spread, I did not remove stuff just for
fun or out of spite. In the process of reconstructing the whole
thing, I left out many things that I initially liked very much,
including the dock widgets. The first priority was to get kdevelop
stable.

And it was a success. The HEAD branch has still its rough
edges, it has some things missing and it has some minor
bugs. But overall, it is a quite robust platform for 
further development. The only way to continue attracting
developers is to make it _more_ stable and _more_ complete.
Going back to a state in which it has non-reproducible
crashs would be a big mistake. Replacing stuff that works
with stuff that does not work would be wrong. I think that
some people here completely miss that. Adding large sub-
systems as mandatory components of kdevelop that are supposed 
to work 'some time in the distant future' do not help the
project as a whole. What kdevelop needs is code that does
a reasonable subset of the 'ideal' well, and is still fle-
xible enough for adding more features and more configurability
in the future.

Bernd.


-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«