Re: Testing network availability

Hash: SHA1

On 05/27/2017 12:39:17 PM Sat, Albrecht Dreß wrote:
Hi Peter:

Am 27.05.17 16:22 schrieb(en) Peter Bloomfield:
The offending call is in ensure_send_progress_dialog, passing "parent" as the transient parent for the 
send-progress dialog, which is in turn called from lbs_process_queue_real, passing SendQueueInfo::parent. Gdb shows that 
send_info->parent is not balsa_app.main_window, which is supposed to be passed down from send_queued_mail_activated. 
It's also not been NULL, in the cases I've looked at.

Oops--I was looking at the wrong code path: if it's an instant send, not a queue-and-send-queued, the parent 
is the compose window, and it sometimes gets destroyed during the async check for reachability. Adding a 
ref/unref should keep it alive long enough.

Hmmm, I wonder if this would really be the reasonable way...

I think the user expects that the message is either sent or queued /somehow/ whenever [s]he hits the send button.  
Remember that the "real" send process may be delayed for some time, e.g. if a dial-up connection needs to be 
established (maybe ~30 seconds in this case).  Still showing the composer sounds impractical to me.

This means that the composer dialogue should be closed, regardless of the state of the send process.  Which 
in turn implies that the usual state would actually be the destroyed parent!

You're right, of course--not much point in using the async method if the compose window is held open until it 

IMO, there are two proper ways to deal with this situation:
1) always use the main window as parent, when showing the send progress dialogue
2) use that status bar in the main window to show the send progress

However, #2 might conflict with a pop3 download progress...

What do you think?

1) looks good to me. I was actually surprised to see the compose window code using the compose window as 


Version: GnuPG v2


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