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

List:       kmail-devel
Subject:    Re: Last attempt at reconciliation
From:       Carsten Burghardt <cb () magic-shop ! de>
Date:       2002-09-17 20:25:00
[Download RAW message or body]

On Tuesday 17 September 2002 21:35, Zack Rusin wrote:
> 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?

Definitely keep and develop KMime.

> - 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?

The amount of code insterted into kmail could indeed be a problem. The KParts 
can of course be also used within the rest of kde so this should be the way 
to go. But the kroupware is very time critical so it could be a problem to 
switch to a different approach.

> - 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?

Nope.

> 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

-- 
Carsten Burghardt
email: cb@magic-shop.de
WWW: http://www.magic-shop.de
PGP: http://www.magic-shop.de/Carsten_Burghardt.asc

_______________________________________________
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]