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

List:       kmail-devel
Subject:    Re: Partial merge of kroupware into HEAD
From:       Don Sanders <sanders () kde ! org>
Date:       2002-11-28 14:50:24
[Download RAW message or body]

On Thursday 28 November 2002 23:47, Marc Mutz wrote:
> On Thursday 28 November 2002 10:37, Stephan Kulow wrote:
> > > On Thursday 28 November 2002 08:33, Marc Mutz wrote:
> > > > Thus, we plan to open a new branch port_kroupware_to_kaplan
> > > > (or so) and do the port there using the make_it_cool code, so
> > > > we can keep kroupware_branch for bugfixing and as possible
> > > > end product to be shipped to the BSI in the likely case that
> > > > we don't get kroupware/kaplan stable in time.
> > > >
> > > > In any case, kroupware/kaplan will be what ends up in HEAD.
> >
> > On that topic: So far make_it_cool is pretty uptodate with the
> > changes done in HEAD. I'd like to merge the changes in
> > make_it_cool into HEAD real soon now. I and quite some others use
> > the branch already, so you don't have to fear big instability.
> > And the kaplan change is already done there. If we don't start
> > big changes now we'll never get it.
> >
> > Any arguments against it?
>
> <snip>
>
> There are some changes that I think need more work. Off the top of
> my head, Index should be a class of it's own right, not part of the
> KMFolder hierarchy. Folders would then use the index as a Strategy
> with unindexed folders using a NullIndex object.

If we ever reach the stage where multiple different index 
implementations are required then that might make sense, but I don't 
see any reason for adding that extra complexity before the merge. Or 
perhaps I misunderstand?

> I see kmindexer
> being added. Is that what I describe

Sorry, what did you describe?

> or is it used as a parser that
> builds the index? If the latter, building the index should be done
> through a Builder.

There's always room for improvement. The indexing code is in the early 
stage of development and is disabled in the code by default. It can 
easily be removed if it's not completed by 3.2.

Having said that I really don't see how the Builder pattern is 
relevant here.

> Has the separate readerwin issue been resolved?

I'm very happy with the current solution of KMReaderMainWin being a 
separate class, especially now that Ingo's suggestions have been 
implemented and the code duplication eliminated. I see this solution 
as much preferable to making KMMainWin a generic container class.

> Maybe the people working on make_it_cool can give an overview of
> changes that were done there, so we can start merging the ones that
> are consensus?

You can see a list of user visible changes in kmailNewFeatures in 
kmreaderwin. Also inplace renaming of folders is now supported, and 
ryan breen's system tray notification patch has been applied.

Architecturally KMFolder has been split into KMFolderIndex that 
implements .index file support and a basic KMFolder class that does 
the rest. KMFolderSearch has been added that implements search folder 
support. Zack's imap cleanups that he has already talked about on 
this list have been applied, and also he has made some custom folder 
icon cleanups. KMail has been transformed into a KPart and this 
required KMMainWin being split into KMMainWin and KMMainWidget, and 
some startup code being moved out of main.cpp into kmstartup.cpp.

Also several top wishes are implemented including duplicate removal, 
dynamic filters. The two outstanding major bugs accidental folder 
switching and draft messages being lost have been fixed. Folders are 
periodically saved to prevent information loss on abnormal shutdown, 
the .sorted file has been ported to serial numbers so that it remains 
valid after message deletion, the kmcommands have been modified so 
that all commands only need data in the kernel.

Some icon changes have been made to cr*.png those shouldn't go into 
HEAD, and the about box changes in main.cpp don't have to go in.

If anything is unclear please ask and I'll do my best to clarify 
things, anyway, I'll leave it to Coolo to make the final decision.

Don Sanders / sanders@kde.org
KMail  Adopter / kmail.kde.org
KDE PIM  Co-founder / kdepim.org
KAddressbook  Founder / kaddressbook.org
KDE  Contributor / kde.org

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