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

List:       kmail-devel
Subject:    Re: Partial merge of kroupware into HEAD
From:       Marc Mutz <mutz () kde ! org>
Date:       2002-11-29 16:36:03
[Download RAW message or body]

On Thursday 28 November 2002 15:50, Don Sanders wrote:
> On Thursday 28 November 2002 23:47, Marc Mutz wrote:
<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?

It's not adding complexity, it's reducing complexity. Complexity of 
KMFolder. When a class does too much, you Extract Class. Should be 
quite easy. We don't need the Index class created by a factory method, 
of course. But Index has no place in KMFolder, IMO.

> > I see kmindexer
> > being added. Is that what I describe
>
> Sorry, what did you describe?

Extracting index handling into KMail::Index.

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

Builder abstract parsing from generating the in-memory representation. 
If KMail::Index is the in-memory (or mmapped) representation, then it 
needs not know how to parse. I guess that's what Sam tries to achieve 
with the indexer.

So the question is: Is indexer part of a builder pattern that combines 
indexer and KMFolder(Index) or is indexer the result of extracting 
index handling from the kmfolder hierarchy?

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

Sounds better than last time around ;-)

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

Danimo told me he's not really happy with it due to accel problems. So 
that's not a part that needs to go to HEAD.

> and
> ryan breen's system tray notification patch has been applied.

That's something that everyone's welcome, I guess.

> Architecturally KMFolder has been split into KMFolderIndex that
> implements .index file support and a basic KMFolder class that does
> the rest.

See above.

> KMFolderSearch has been added that implements search folder
> support.

From how you explained the implementation (list or sernums), I guess 
it's OK.

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

OK.

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

That's what we need to port kroupware to, yes.

> Also several top wishes are implemented including duplicate removal,

OK.

> dynamic filters.

I have minor cosmetic things about that one, but the feature in itself 
is great.

> The two outstanding major bugs accidental folder
> switching and draft messages being lost have been fixed.

Something for 3.1.1?

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

Sounds good.

> Some icon changes have been made to cr*.png those shouldn't go into
> HEAD,

Why were they done then?

Thank you _very_ much for the summary. As you can see, I agree with most 
of them in principle. That doesn't mean that they should go in in one 
go, though.

Marc

-- 
Ich gegen meinen Bruder.
Ich und mein Bruder gegen unseren Cousin.
Ich, mein Bruder und unser Cousin gegen unsere Nachbarn.
Wir alle gegen den Fremden.
                                      -- Beduinen-Sprichwort

[Attachment #3 (application/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]