From kmail-devel Tue Sep 17 19:35:45 2002 From: Zack Rusin Date: Tue, 17 Sep 2002 19:35:45 +0000 To: kmail-devel Subject: Re: Last attempt at reconciliation X-MARC-Message: https://marc.info/?l=kmail-devel&m=103229136525650 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=20 have two different branches besides HEAD - make_it_cool and kgroupware.=20 I no longer can keep them in sync simply because make_it_cool and=20 kgroupware took completely different approaches as far as componization =20 of KMail and integration with other parts of kdepim goes. You've all=20 seen the screenshots of both KGroupware (presented by Karl-Heinz) and=20 make_it_cool (presented by Don). Resolving this metter should be one of=20 the basic things on our way to making KMail the _best_ mua out there.=20 That's what it's all about - the damn mail client. Almost all that has=20 been happening lately is purely politics, childish games, accusations=20 and everything that makes this spare-time activity so much less fun=20 (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=20 the branches/problems are that we are facing and maybe everyone could=20 give his/hers opinion on the topic. So, what divides us: =2D we have KMime almost finished. It's a fantastic library maintained by=20 our own Marc Mutz. Don did with Mimelib what he thought would be=20 impossible with it, and was one of the reasons KMime was born. Now Don=20 doesn't want to spend more time integrating KMime since Mimelib=20 fullfills our basic needs and Marc has been insulted as he feels that=20 all his work is going down the drain. I had a conversation with Don=20 about switching to KMime - he has _no_ problem with it, it's just that=20 he works on different things within KMail so can't work on it. The=20 problem that we would face while switching KMime is the lack of=20 substring sharing string class like DwString. Marc maybe we could add=20 one to libkdenetwork and make KMime use it? I volunteer to write one=20 and spend time porting KMime to it. This would solve the only problem=20 Don ever had with switching to KMime and let us do the switch.=20 Comments? =2D we have two approaches to integrate KMail with kdepim packages.=20 kgroupware has one and make_it_cool has one. The big problem I have=20 with the kgroupware approach is that it majorly bloats KMail code,=20 making it even harder to understand - for people who want to help us -=20 and for ourselves. And to be completely honest, even on screenshots it=20 looks not too promising. I find Don's and Daniel's approach with Kaplan=20 _way_ superior. I think Kaplan and KMail as KPart is the way to go. Comments? =2D now people have problems with changes in make_it_cool. I want to know=20 exactly what changes from make_it_cool bother you so much, so in no=20 particular order: o my folder rework, asynchronous access to all folders, common=20 interface, all folder use kmfolderjob, no distinction between local and=20 imap folders. Problems? What? Why? o Don's KMail as KPart, KMMainReadWin addition and zero-copy parsing=20 with mimelib - I already talked about the first, Don cleaned up the=20 second and fixed things which seemed to bother some people when it was=20 in HEAD, has anyone better approaches to the third? I remember that one=20 being a major problem, so let's come up with solution we all can be=20 happy with. o Aaron's work on GUI - IMHO Aaron is by far the biggest usability=20 expert among us, I trust all his judgments. Did anyone have a problem=20 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=20 prefix, putting classes in the KMail namespace and putting files into a=20 more approachable dir structure. Any problems with that? Please, remember to concentrate on the mail client, not self-pride,=20 while commenting. For god sake, let's finally agree on something and=20 resolve all issues people might have. Zack =2D-=20 =46ew women admit their age. Few men act theirs. _______________________________________________ KMail Developers mailing list kmail@mail.kde.org http://mail.kde.org/mailman/listinfo/kmail