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

List:       kmail-devel
Subject:    Re: Last attempt at reconciliation
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2002-09-17 23:52:56
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Go for it.

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

As I already wrote in another message I much prefer the Kaplan approach 
over the KOrganizer-in-KMail 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?

No problems.

> o Don's KMail as KPart,

Very good.

> KMMainReadWin addition

Also very good. We just didn't want to have the half finished version of 
this in KDE 3.1. But for KDE 3.2 this is definitely a great 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.

zero-copy parsing is good. But please let's get rid of mimelib.

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

So far, no problems.

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

Namespacing is good. Getting rid of the KM is also o.k. But I'm not sure 
about the dir structure. How should it look like?

Regards,
Ingo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9h8BYGnR+RTDgudgRAlRoAKDEVqk741l41eg4jK1vV53nq6b6PACfQABy
YU8dV4eWqy8UpabiBOCKa3I=
=Ejdu
-----END PGP SIGNATURE-----

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