On Sat, 2015-10-03 at 17:21 -0500, Ben Liblit wrote: > (A good start might be for e_msg_composer_send() > to return the EActivity it creates: this exactly represents the > current send attempt and could be monitored for status changes.)
Hi, you are right, there is no good (and direct) API to achieve what you want right now. There is an indirect API. The EMsgComposer::busy property gives a status whether the composer is doing anything. Looking into the implementation of the busy state change, the code relies on the EActivityBar notifications, which gets to the EActivity. Your "Send & Archive" method might look like this (pseudo-code): static void action_send_and_archive_cb (GtkAction *action, EMsgComposer *composer) { html_editor = e_msg_composer_get_editor (composer); activity_bar = e_html_editor_get_activity_bar (editor); g_signal_connect ( activity_bar, "notify::activity", G_CALLBACK (composer_sent_and_archive_notify_activity_cb), composer); e_msg_composer_send (composer); } Where in the composer_sent_and_archive_notify_activity_cb() you'd get to the activity and you'd disconnect from the "notify::activity" signal. It's still not good, because the e_msg_composer_send() can finish without running any activity, and it can wait for a user confirmation for an unknown time. The only current feasible way seems to me the code duplication, copy the implementation of the e_msg_composer_send() into your plugin (with other necessary parts) and call that, instead of calling e_msg_composer_send(). You cannot invoke EMsgComposer::presend signal before calling e_msg_composer_send() to verify whether the message will be send or not, because, if any signal listener asks users for anything, that could be double asked. I do not think returning an EActivity from e_msg_composer_send() is a good idea. The reason is that it's an API change. The thing is that the returned pointer should be referenced, thus each call would need to unref it. That means adding more responsibilities to the caller and other overheads. What about adding a "postsend" signal? The round trip of signals would be: presend send postsend where the postsend will be called always after the send is complete, successfully or failed. That will also mean an API (ABI) change (the EMsgComposerClass structure will be larger), but it'll not add any additional requirements for the callers. What do you think? Bye, Milan _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers