[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 23:18:54
[Download RAW message or body]

On Tuesday 17 September 2002 19:52, Ingo Klöcker wrote:
> > - 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.

By the way, Karl-Heinz and co. just refactored almost everything from 
KMail core to KMGroupware. Great work guys. What is the deadline for 
the Kroupware KMail?


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

Great. My main concern was that someone will object to merging 
make_it_cool into HEAD once the feature freeze is over.

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

Yes, I personally don't like mimelib and see completely no reason to 
stick with it and hundreds to switch.

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

To be honest, I'm not sure. Personally I thought about 
- ui/ - for all ui files,
- widgets/ - for all widgets,
- core/ - for all non-gui related classes,
- main/ or app/ - for main and kpart stuff
Daniel?

Zack

-- 
Failure is not an option. (It comes bundled with Windows.)

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