Application.Controller: Rework composer life-cycle, again

Since plugins especially require the ability to customise a composer
ideally before presenting it, split up composer construction into two
phases: `compose_blah` methods that find a matching composer or
constructa new one, then `present_composer` to present it.
Add `composer_registered` and `composer_deregistered` signals, fired
as appropriate so other code paths (again, plugins in particular) can
hook into composer lifecycles.

Update call sites for new API and to explicitly present new composers.
This commit is contained in:
Michael Gratton 2020-07-03 15:12:27 +10:00 committed by Michael James Gratton
parent f3e6feb887
commit c57ae854bd
3 changed files with 127 additions and 88 deletions

View file

@ -726,8 +726,25 @@ public class Application.Client : Gtk.Application {
}
public async void new_composer(Geary.RFC822.MailboxAddress? to = null) {
yield this.present();
yield this.controller.compose_new_email(to);
MainWindow main = yield this.present();
AccountContext? account = null;
if (main.selected_account == null) {
account = this.controller.get_context_for_account(
main.selected_account.information
);
}
if (account == null) {
account = Geary.Collection.first(
this.controller.get_account_contexts()
);
}
if (account != null) {
Composer.Widget composer = yield this.controller.compose_blank(
account,
to
);
this.controller.present_composer(composer);
}
}
public async void new_composer_mailto(string? mailto) {