A final word (was:Re: What's up and what's hot)

[Roland Krause]

Ralf,
thank you _very much_ for your efforts in leading this project, it is
genuinely and honestly appreciated. I know how much time, heart and
soul you are personally investing into KDevelop and at this point I
would like to take the chance and thank you for it. 

Now I would like to address some of the points you bring up. 

--- Ralf Nolden <nolden at kde.org> wrote:
> > When will it have the MDI interface?
> When you guys will agree with me that splitting is a _bad_ idea and
> overcome 
> your predjudices. The way to go for gideon was needed because nothing
> worked 
> on the HEAD in February. 

No no, I was under the impression that the gideon project had already
decided that MDI was a bad UI decision and that it would not go into 
HEAD, no matter what.

> 
> Everyone 
> except Falk was ok with this and as much as I understand that one can
> be 
> pissed off when your work was tagged as depricated, 

Hold on here, Falk's stuff was not depreciated by _all_ people, it was
removed by some, without discussion of the facts. That is no basis for
a collaboration. 

> I think that
> there is a 
> lack of understanding the big picture from you guys. 

I consider myself a "big picture guy" :-), anyway, design decisions are
made early in the development of a program, they can seldomly be
reversed and even if, only with massive effort. Here is where the
problem lies, there are many design decisions that have been made on a
"first come first serve" basis. Examples: 

- plugin architecture, everything is a plugin, is that really 
necessary? While it obviously structures the code nicely, does it  
really make sense that there is almost no core funtionality that  
plugins can rely on? Is it efficient? Are there other possible
solutions? How about documentation of the whole thing, its technology
that is not in widespread use outside of KDE after all. 
- splitter view, enough said in the previous discussions...
- the "splitter" classtree view that is so hard to understand and so 
quirky to handle, can we get rid of that? 
- abstract editor interface, yeah it lets me use NEdit, so what, I can
go to tools and start NEdit on the file, that's all the benefit I can
see from this as of know. Would the time have been better spent on much
necessary improvements of kate? Are we that serious about KDE if we
cant even improve the core texteditor? 
- project management entirely based on automake/autoconf. Who decided
that, what about projects that are not automake based? Not qmake based
either, can I still use HEAD for these, will I be able to in the
future? 
- The whole UI, the dialogs, all that stuff has such a cramped quirky
feel to it, why werent the nice dialogs from 2.0 ported? Why was all
the stuff that worked in 2.0 abandonded, who is going to implement and
port all that?

> You just don't
> see that 
> there is a point in life where you need to do decisions for the good
> of 
> everyone even at the cost of the work of some (and those who did the
> main 
> work agreed with gideon), and everyone understood the meaning of the
> decision 
> back in Feb. except Falk. So I ask you two again to _please_ _please_
> make up 
> your mind and stop acting childish. 

You misunderstand some fundamental differences in developer intentions
and code design as "childish behavior". 

> marketing 

We, that is you, Falk, me, John, HarryF and numerous others have
invested many, many hours to make KDevelop-2 stable. And believe me, in
the beginning it crashed so often that I sometimes thought this is
never going to work. It still crashes, there are still bugs, but it has
matured a lot. That has/had nothing to do with marketing reasons.
There is no room for marketing in free software. Decisions are made by
the users, User become power users, beta testers, bug fixers, then
feature developers and finally core developers. All KDevelop developers
are KDevelop users as well. This is actually a unique situation.

In my professional life, marketing tells me what to implement, that is
often humiliating and frustrating enough, I dont need that anywhere
else. 

> If I may remind you
> of the 
> case of mosfet (I don't do any comparison to you but I just bring up
> a hint 
> where this behavior could lead to) with KDE, 

Well, this could be understand as a threat. I know you a bit from our
IRC conversations and I am convinced you didnt mean it like that.
Nevertheless, I personally am not afraid of the "gods of KDE". I truly
believe that the KDE project is going to be the one and true
"bastillion" against the "evil empire". I like KDE and I promote it in
every day life wherever I can, just as I do with Linux and other free
software projects I like. 

The funny thing really is, the whole affair is remotely comparable to
the "Mosfet" situation with the delicate detail being that you removed
code from the development branch without asking and talking to all the
contributors. So, unless you want to take the "Mosfet" role here, dont
play this game. 


> I bet with you that if we don't agree on a way to go _now_ and that
> should be 
> to work _together_ on gideon, 

Working "_together_ on gideon" has, as of now, not been defined.

> 
> Roland, I've always tried to be understanding for Falk's quarreling
> with 
> gideon because that new version initially dropped the support for
> MDI. 

I dont see any intentions to reintegrate from the current gideon
development, that was never brought up so far. 

> But 
> that was technically because we needed something _working_ to
> interest the 
> developers, which _fullfilled_ its goal; 

Technically, you made the wrong decision. 

MDI was not usable as of February this year, the time when I started to
raise my head here. It became usable through endless bugreports and
fixes, redesign, rewrites. MDI was dismissed by the gideon coders upon
two reasons very early on.

First, usability, i.e. it was deemed to be the wrong UI decision. The
only person that feels strongly about this is Bernd. See the mailing
list discussion as of February...

Second, implementation, i.e. the current MDI code and especially the
document view manager is not very well designed. It interacts with the
calling code (CKDevelop) in far too many ways and does not encapsulate
the editor interface cleanly. This was correctly pointed out by Bernd
also in the above mentioned mailing list thread.

For the record, since then most of the implementation issues have been
addressed, docViewMan is currently undergoing a major rewrite that will
fix these issues where it makes sense. docViewMan will become a kpart
integrating QextMDI and Kate as well as other view related parts. This
work is being done in KDEVELOP_2 because it will lead to an improved,
working version of KDevelop, which has immediate benefits for me. 

Let's talk about integrating _this_ version of the docViewMan and the
corresponding MDI into gideon and we are in business. 


> just you guys are
> disappointed that 
> Bernd didn't take any immediate care of MDI stuff. But MDI is like
> menu 
> orders and dialog layout, a layout question of the application, it's
> a 
> usability part and not the most important part of the application
> that has to 
> be met in the very first implementation. 

You are wrong here. It is the most integral part of a development
environment since it determines how you interact with the program for
about 80% of the time. Wrong design decisions here can hardly be
reversed. The editor abstraction layer of MHK cleary shows that this
decision should have been made earlier. Then his work could have been
integrated with a revised docViewMan and all would be fine... 

> It is up to you two guys to
> say, ok, 
> we will put that into gideon _now_ that this version has matured to a
> state 

gideon hasnt matured to that state, yet. I agree my last version is
from 062201 and much may have happened. I will update today. Last time
I used it, it crashed about every 3 minutes, just like KDevelop-2 used
to do. The proof that pointer are dangerous and UI coding isnt easy. 

> where it is working and where it is our chance to put MDI in as an
> additional 
> component to offer the user a similar way of handling that 2.0 has,
> as a user 
> compatibility component that could even be the default because of
> that. 

A document view manager is an integral part of an application, look at
the kate code to see how it can be done in a clean and nice manner. MDI
will add the additional difficulty of repossesing view widgets, but the
core is clearly the same. 

> It will lead to the point where I will say, this just
> pisses _me_ 
> off. And you don't have to be a rocket scientist to know what happens
> then. 

Ralf, I dont want you to get pissed off, I want the same thing as you
do :-) If you get pissed off, I will take you out for a couple of
"brewskis" in November and drink you under the table... :-) Then we go
and swim through the Bay, that will cool you off.

> 
> Please come back. You don't need to beg for forgiveness, 
> you don't
> have to 
> say, ok, I was wrong, you just need to work on gideon and be a part
> of the 
> team. That's all I demand. Is that too much ?

:-) ROTFL
Roland



=====
--
Roland Krause
In the garage of life there are mechanics and 
there are drivers. Mechanics wanted!

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

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