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

List:       kmail-devel
Subject:    Re: [PATCH] subscription
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2002-12-19 23:28:36
[Download RAW message or body]

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?

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

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

Regards,
Ingo


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