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! 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? Cheers, Albrecht.
pgpwBNFOjPv5O.pgp
Description: PGP signature
_______________________________________________ balsa-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/balsa-list
