Hi Jack: thanks a lot for your feedback! Am 01.01.18 20:30 schrieb(en) Jack:
Minor point (and digression) I seem to repeatedly get confused by the terminology. Under the Balsa menu, there are both Settings and Preferences. Settings has sub menus for Toolbars and Identities, while Preferences immediately brings up the Preferences dialog. Would it simplify or add confusion to move the Preferences to be a third submenu item under Settings?
Good point! It's even more confusing in the German locale, where both menu items are translated identically as “Einstellungen”. I like your ideas of shifting everything below one “Preferences” menu. IMHO, though, it would be better to rename the shifted one to “Common…” (maybe an English native speaker has a better idea?) and make it the first item.
Additional minor point - After making any change on the Preferences dialog, such as to an incoming or outgoing mailbox server, the only button to choose is "Cancel" but this accepts the change that was just made - the actual opportunity to accept or cancel was part of the previous dialog. I haven't tested enough to see when the "OK" button is actually enabled, but I do wonder why I have to hit "Cancel" even though I'm not cancelling anything.
Yes! Very confusing indeed!
However, this behaviour contradicts the /three/ config settings “While retrieving messages”, “Until closed” and “Never”. But the second option doesn't seem to display the dialogue (for me, at least), though. Does anyone use this option, and how is it supposed to work?I have the first checked. I suppose I would ask "until WHAT is closed?" I could imagine it would let you close the progress dialog, essentially forcing it to the third option, but only for for the remainder of that fetch.
I could imagine that the second option keeps the progress dialogue open, even if no POP3 download takes place, until the user /manually/ closes it. But for me, this option doesn't open a dialogue, but prints some information in the status bar.
Might it make sense to duplicate that radio box set for sending as well as receiving?
That would be easy…
This would be fine for me (either with one box or separate for sending and retrieving.
OK, thanks!
However, regarding the retrieval progress dialog - I've been musing over it for a long time. It appears (for a single remote mail server) it shows the progress based on the total (estimated?) volume to be fetched.
It's the total size of all messages which shall be loaded as reported by the remote server.
I'd actually prefer to see it split into two progrss bars -- one based on number of messages, and the other based on either the volume of the current message being fetched or the total volume. For now, I'll let that thought stay as only a fantasy.
Hmmm… The progress dialogue shows both information already – the total (bytes) progress both in the progress bar and in text form, and the message count in text form only (like “Message 3 of 21 (10k of 1M)”). So, a second progress bar would be possible of course, but I wonder if it really adds more information, or just confusion. The progress bar itself is updated when either a message has been received completely, or when the underlying protocol layer has processed a chunk (4k at the moment) of data. IOW, small messages are likely to be read in one or two chunks. Thus, a progress bar based on each message would typically show only two or three states (0% and 100%, or 0/50/100%), which is not very helpful, I guess…
For fetching from multiple servers at once, I'd perhaps like to see a progress bar for each one, disappearing when the fetch is complete for that server. It clearly doesn't matter if you only fetch from one server at a time, but for parallel fetching, I think it would be useful.
This is exactly what I propose. I implemented this for sending (SMTP) a while ago. The progress dialogue contains a separate “section” for each open server connection, with a header, a message line, and the progress bar. When the transaction with a server has been finished, the respective section is faded out and then removed.
Additional wish list item related to fetching: would it be reasonable for Balsa to save the timestamp of the last successful fetch from each remote server? An extra would be to also save the timestamp of the latest attempt, whether successful or not. This/these would have to be easy to display - probably on the fetch dialog where you would select whether to fetch from all, all enabled, just one, or a specified set of servers.
This is also an interesting idea!
Hopefully that doesn't open too large a can of worms.
No, your input is really helpful, as usual! However, please don't expect everything being implemented immediately (I'll start with the progress)… Cheers, Albrecht.
Attachment:
pgpR2kQTyWQ2W.pgp
Description: PGP signature