Re: [Evolution-hackers] EMsgComposer API support for "Send and Archive"

[Milan Crha <mcrha redhat com>]

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