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

List:       kmail-devel
Subject:    Re: [PATCH] subscription
From:       Carsten Burghardt <burghardt () kde ! org>
Date:       2002-12-30 15:23:16
[Download RAW message or body]

Am Freitag, 20. Dezember 2002 00:28 schrieb Ingo Klöcker:
> On Wednesday 18 December 2002 15:37, Carsten Burghardt wrote:
> > On Wednesday 18 December 2002 00:06, Ingo Klöcker wrote:
> > > 2nd problem:
> > > Check the checkbox of a folder. Then click reload folder list. The
> > > checkbox of this folder (probably of all folders but I only saw one
> > > folder because of the 1st problem) is unchecked although the folder
> > > is still in the list of subscribed folders. If I check the checkbox
> > > again the folder is added again to the list of subscribed folders.
> > > It now appears twice in the list.
> >
> > The reload-button now clears all lists and therefore fixes this.
>
> Does this mean that all subscribed folders will get unsubscribed when
> one pushes the Reload button?

No, as changes only take affect when you press Ok. So the listitems are simply 
todos that should be resetted (deleted) when you reload the list as you don't 
know what changed.

> > > 3rd problem (most likely related to your patch):
> > > KMail HEAD doesn't work at all very good with the above server.
> > > Somehow it seems to add a whole lot of cancel folders under each
> > > normal folder. This doesn't happen with KMail 3_1.
> >
> > Cancel folders? What's that? It works without a problem here.
>
> For every folder (e.g. kde.kde-kmail) there was a cancel subfolder (e.g.
> kde.kde-kmail/cancel). But this is probably related to the other
> problems with this particular server. OTOH the cancel folders don't
> appear with KDE 3.1.

I can't reproduce this here.

> > OK, the only real problem is described by yourself here:
> > > OTOH, using this server with KMail 3_1 is also very annoying. After
> > > setting up the server you have to wait 15-30 minutes (this is from
> > > the university where I have a really fast connection) until KMail
> > > has created the 1000+ dummy (empty) index files and serial number
> > > files for all folders on the server. IMO creating any folder
> > > related files (index files, serial number files, etc.) should be
> > > delayed until the user actually clicks on a folder. If feasible not
> > > even the directory structure should be build locally until needed.
> > > This would not only speed up the first connection but also the
> > > startup of KMail since instead of 1000+ serial number files much
> > > less serial number files would have to be read.
> >
> > I agree but I'm pretty sure that this is not so easy to implement.
> > You need to delay a big part of the folder-creation until it's
> > selected. Therefore you need to create a special class otherwise
> > you'll end with tons of "if imap" parts in mbox.
>
> It would probably already help if the index file and the serial number
> file of an IMAP folder wasn't created before the folder is actually
> selected. It doesn't make much sense to create them before the folder
> is selected because the contents of the folder isn't read before it's
> selected.
>
> I didn't have a look at the corresponding code, so I don't know how
> difficult that would be.

Should be possible but will be tricky. I'm currently not so concerned about 
speed-optimizations but I'll keep that in mind.


Carsten

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