Re: IMAP-problems

[Darko Obradovic <dobradovic gmx de>]

On Sun, 20 Apr 2003 19:57:18 -0400
Peter Bloomfield <PeterBloomfield@bellsouth.net> wrote:

> On 04/18/2003, Darko Obradovic wrote:
> [ snip ]
> > You're right on all aspects. One problem less with the patched version
> > now. :)
> 
> One down, n to go!

Not sure if I should really continue. :)
Still not usable the way I'd like it. Apart from the bug reports I made, which question the whole architecture balsa is using for the special folders in last consequence IMHO, there are two more things:

directly related to that is the fact that I can't open more than 5 folders in a session, as Balsa opens a new connection to the server for each one, and the server restricts an IP to 5 simultaneous connections. I read through the libmutt-docs a little, and they say they try to prevent multiple connections as good as possible, but for IMAP, balsa isn't using libmutt, did I get that right?
One reason might be that a folder marked as "Outbox" for example, will be transferred into a new single IMAP-mailbox by balsa. this triggers quite some confuison and is what I mentioned up there.

The other minor thing is that the IMAP-tree is always folded when starting balsa. this is quite annoying when it's my only folder at all, and even if it contains subfolders I have to unfold as well by hand. An option "open on launch" would be cool for an IMAP-folder. I looked through the file creating the folder-pane on the left, and it's full of GTK-TREE-VIEWs, but I couldn't find out what causes local folders to be expanded and IMAP-folders to remain folded.

> I don't recall any IMAP-related RFC that suggests how a MUA should 
> present an IMAP folder tree.
> 
> I can see that if you specify a prefix, you might want the tree to be 
> based on the folder path names *after* the prefix. If the prefix is 
> "INBOX.", the trimmed path name for any child wouldn't begin "INBOX.", 
> so it wouldn't be natural to place it below INBOX. However, Iirc Balsa 
> uses the full path name, so the children are recognized as children of 
> INBOX and located accordingly.
> 
> It could probably be set up the other way. If INBOX were forced into 
> the list *after* finding the children, they would be attached directly 
> to the root of the tree, and INBOX would later be added, also directly 
> to the root--which sounds like what Sylpheed does.

Actually, I'm pretty happy with the tree after having changed that bool-value.
Any plans to include this in some way into the new version? Options are the most flexible of course, but sane defaults have their advantages as well. ;)

I'm really sorry I can only bug you with problems and not come up with any solutions or patches, but this C-stuff is looking extremely unfriendly to someone used to Java...

bye

Darko