Create AlertDialog

[danirabbit]

A new AlertDialog based on PortalDialog to replace MessageDialog since it's Gtk.Dialog based on Gtk.Dialog is deprecated.

Todo:

• button box isn't always valigned to the end. Bug in ToolBox?
• Handle no secondary icon
• Improve documentation
• Mark MessageDialog deprecated
• Wrap buttons if the text is long

Things to figure out:

• Do we require an icon to construct? Adw and GTK don't. Alerts on Android and iOS don't either
• Adw and GTK both have an async API https://valadoc.org/gtk4/Gtk.AlertDialog.choose.html and https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/method.AlertDialog.choose.html
• Adw.AlertDialog uses a string ID which is good for making code more maintainable and on our side it makes it easer t use GLibAction for things like action enabled, but in places where we want to use alerts (like portals) an int response is required (and Gtk uses int still). Which use case do we optimize for?
• Gtk automatically creates a "Close" button if no buttons are added. Probably a good feature
• Adw.AlertDialog allows removing buttons. Is that good/necessary? Examples?
• Should button labels be settable?
• Should button styles be settable?
• Property and function names
• Padding for content area. Should we pack everything into a scrolled by default?
• Do we want to keep the error output area/details view feature? Is this an anti-pattern? Should it just be a separate widget with no collapsing like Widgets: Add TerminalView #867?
• Should alert dialogs make noise? Play a sound for Granite.MessageDialog #471

[bugaevc]

I have experience implementing another dialog API at $dayjob, also modeled after modern GTK & libadwaita dialogs.

All of GTK's recent dialogs have an async API, as opposed to signal-based response.connect + present. See Gtk.FileDialog for example.

In practice, if you want to obtain a response, you await (yield) the call that shows the dialog. For a message dialog, I'd expect this to return the chosen response either as a string or an int. If you don't want a response and just want to let the user know about something, you do dialog.choose.begin ().

Triggering the cancellable passed to the async call causes the GTK dialogs to pop down and throw Gtk.DialogError.CANCELLED. However: note that the implicit GLib.Task Vala creates when you write an async method has the check_cancellable flags set (which is the default... unfortunately). The effect of this is that the async method will be seen as throwing GLib.IOError.CANCELLED if the cancellable has been triggered, even if the implementation did react differently, such as in this case by throwing a different error, Gtk.DialogError.CANCELLED. I don't immediately know of a way to work around this, except writing the function in C.

[danirabbit]

@bugaevc yeah I agree an async API would be good. I've already seen some issues with GTK4 porting that would've been easier to solve with an async API for messagedialog so I'm totally onboard with that. I also wouldn't mind getting rid of the response signal altogether. I think Adw still has it? But I'm not strongly attached to it