Re: [RFC] Progress dialogue options

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 

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)…


Attachment: pgpR2kQTyWQ2W.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]