From kmail-devel  Mon Dec 30 15:23:16 2002
From: Carsten Burghardt <burghardt () kde ! org>
Date: Mon, 30 Dec 2002 15:23:16 +0000
To: kmail-devel
Subject: Re: [PATCH] subscription
X-MARC-Message: https://marc.info/?l=kmail-devel&m=104126186315752

Am Freitag, 20. Dezember 2002 00:28 schrieb Ingo Kl=F6cker:
> On Wednesday 18 December 2002 15:37, Carsten Burghardt wrote:
> > On Wednesday 18 December 2002 00:06, Ingo Kl=F6cker 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 sim=
ply=20
todos that should be resetted (deleted) when you reload the list as you don=
't=20
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=
=20
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