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

[Milan Crha <mcrha redhat com>]

On Mon, 2015-10-05 at 20:10 -0500, Ben Liblit wrote:
> Is there any possible race condition under which the activity might
> complete/cancel and go away before I have an opportunity to grab it
> like this?  Or is there a race condition under which some *other*
> activity might be set as the activity bar's current activity before I
> can grab this one?

        Hi,
I'm not aware of any such race condition off head. As the composer and
the related parts are widgets, they operate these changes in the main
(UI) thread, which gives a thread safety.

> I like this!  Unless you think there's a race lurking in my code to
> fetch the current EActivity, this seems to give me everything I need
> with *no* API changes at all.

I also think it is fine, and the direct get of the activity as you
outlined above is even nicer than checking with notification signal on
the activity bar.

> I don't quite understand your "double asked" concern.

I thought of not copying the e_msg_composer_send() yourself, but just
emitting the "presend" signal to check whether the message will be send
or not. Forget it, maintaining the copy of that function is not a good
option, it's just an option :)

> I agree that we should not ask existing callers to g_object_unref() a
> return value that they previously did not expect to see at all.  If
> we believe that ignoring this return value will be the common case,
> is it reasonable to return the EActivity *without* increasing its
> reference count accordingly?

Yes, I'm just used to thread safety issues with references, though it
doesn't apply here (see above the note about the main (UI) thread).

> That would work for me provided we have some strong guarantee that no
> other send can appear in the middle, as in:

The send within one composer cannot interleave, because the composer
disables most of the UI while processing the send.

The solution with added signal is the clean way of achieving what you
want. All the above is doable, but a little hacky. If you are fine with
the current way, then even better, otherwise I can add the signal and
you can use it conditionally (using g_signal_lookup()), or create your
plugin only for 3.20+.
        Bye,
        Milan