Re: [RFC] Progress dialogue options

Jack <[email protected]>
Newsgroups gmane.comp.gnome.apps.balsa
Message-ID <[email protected]>
On 2018.01.01 06:36, Albrecht Dreß wrote:
> Hi all:
> 
> First of all, I wish you all a happy New Year 2018!
And also to you.
> 
> While implementing multi-threaded POP3 message retrieval (related to  
> the recent “Is there a way to fetch mail from only one server”  
> discussion), I ran into a difficulty regarding the display of the  
> progress dialogue.  As to display multiple progress bars  
> simultaneously, I would use the libbalsa_progress_dialog_* functions  
> I introduced for parallel SMTP operations.  These dialogues are  
> automatically destroyed after the last operation has been finished.
> 
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?

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.

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

Might it make sense to duplicate that radio box set for sending as well  
as receiving?
> 
> As to simplify everything, I tend to replace the three options above  
> by a simple check box “Display progress dialog when sending or  
> retrieving messages”.  What do you think – is this reasonable, or  
> would it hamper Balsa's usability?
This would be fine for me (either with one box or separate for sending  
and retrieving.

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

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.

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.

> Thanks in advance for any insight,
Hopefully that doesn't open too large a can of worms.

> Cheers,
> Albrecht.

Jack
_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.