[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Last attempt at reconciliation
From:       Zack Rusin <zack () kde ! org>
Date:       2002-09-17 19:35:45
[Download RAW message or body]

On Tuesday 17 September 2002 14:51, Carsten Burghardt wrote:
> On Tuesday 17 September 2002 14:34, Don Sanders wrote:
> > I have been thinking some more about my position.
> >
> > I would like to present Michael the following final offer at a
> > compromise:
> >
> > I be allowed to fork KMail and begin work on KMail2 a mail client
> > largely based on KMail but with the intention of making radical
> > fundamental changes to the core architecture as I describe in
> > my "Stuff I'm working on" mail.
> >
> > Would that be acceptable?
>
> I don't think that this would be wise. It should be possible to agree
> on the points that differ in the branches and to concentrate the
> developer-power to one product.

Yes. Guys let's discuss the future of KMail once and for all. We now 
have two different branches besides HEAD - make_it_cool and kgroupware. 
I no longer can keep them in sync simply because make_it_cool and 
kgroupware took completely different approaches as far as componization  
of KMail and integration with other parts of kdepim goes. You've all 
seen the screenshots of both KGroupware (presented by Karl-Heinz) and 
make_it_cool (presented by Don). Resolving this metter should be one of 
the basic things on our way to making KMail the _best_ mua out there. 
That's what it's all about - the damn mail client. Almost all that has 
been happening lately is purely politics, childish games, accusations 
and everything that makes this spare-time activity so much less fun 
(and I assume almost all of us work on KMail in their spare time).
Please, oh please let's agree on a couple of things. I'll present what 
the branches/problems are that we are facing and maybe everyone could 
give his/hers opinion on the topic. So, what divides us:

- we have KMime almost finished. It's a fantastic library maintained by 
our own Marc Mutz. Don did with Mimelib what he thought would be 
impossible with it, and was one of the reasons KMime was born. Now Don 
doesn't want to spend more time integrating KMime since Mimelib 
fullfills our basic needs and Marc has been insulted as he feels that 
all his work is going down the drain. I had a conversation with Don 
about switching to KMime - he has _no_ problem with it, it's just that 
he works on different things within KMail so can't work on it. The 
problem that we would face while switching KMime is the lack of 
substring sharing string class like DwString. Marc maybe we could add 
one to libkdenetwork and make KMime use it? I volunteer to write one 
and spend time porting KMime to it. This would solve the only problem 
Don ever had with switching to KMime and let us do the switch. 
Comments?

- we have two approaches to integrate KMail with kdepim packages. 
kgroupware has one and make_it_cool has one. The big problem I have 
with the kgroupware approach is that it majorly bloats KMail code, 
making it even harder to understand - for people who want to help us - 
and for ourselves. And to be completely honest, even on screenshots it 
looks not too promising. I find Don's and Daniel's approach with Kaplan 
_way_ superior. I think Kaplan and KMail as KPart is the way to go.
Comments?

- now people have problems with changes in make_it_cool. I want to know 
exactly what changes from make_it_cool bother you so much, so in no 
particular order:
o my folder rework, asynchronous access to all folders, common 
interface, all folder use kmfolderjob, no distinction between local and 
imap folders. Problems? What? Why?
o Don's KMail as KPart, KMMainReadWin addition and zero-copy parsing 
with mimelib - I already talked about the first, Don cleaned up the 
second and fixed things which seemed to bother some people when it was 
in HEAD, has anyone better approaches to the third? I remember that one 
being a major problem, so let's come up with solution we all can be 
happy with.
o Aaron's work on GUI - IMHO Aaron is by far the biggest usability 
expert among us, I trust all his judgments. Did anyone have a problem 
with him having a free hand in making needed GUI changes?
o Daniel wants to refactor a lot of stuff - getting rid of the KM 
prefix, putting classes in the KMail namespace and putting files into a 
more approachable dir structure. Any problems with that?

Please, remember to concentrate on the mail client, not self-pride, 
while commenting. For god sake, let's finally agree on something and 
resolve all issues people might have.


Zack

-- 
Few women admit their age. Few men act theirs.

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]