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 KP=
arts=20
can of course be also used within the rest of kde so this should be the w=
ay=20
to go. But the kroupware is very time critical so it could be a problem t=
o=20
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

--=20
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