Hosts rewrite.

[sirdoombox]

Major Changes

• Complete rewrite of the SukiHost API - Styling remains largely unchanged.
• SukiHost is no more. That single object was quickly turning into a nightmare.
• Add a Hosts property to SukiWindow so people can choose which hosts they do or don't want and implement their own window-level host style controls as needed.
• Tore out and rewrote the toast API as it's own separate entity.
  • Now loosely mirrors the Avalonia.Notification API, for people familiar with that this will be far easier to pick up.
  • Much more MVVM friendly, no more horrible static state and needing to find specific Window instances.
  • Allows a SukiToastHost to be used anywhere or nowhere, you can now have toasts inside a button if you want.
  • Uses a builder pattern for constructing toasts.
    • This is far easier to expand and modify the API without causing massive headaches, no more adding extra arguments and overloads to SukiHost.ShowToast.
  • You can now have any number of ActionButtons within a toast.
  • Much more fine grained control over the behaviour of toasts - Try out the Action Toasts in the demo of this PR.
  • No more async/tasks, not seeing any blocking going on so this is unlikely to need to change.
  • Toast location now works correctly and is set by the host itself. You can change this at runtime, and because you can have multiple toast hosts at once in the window you can have one in each corner and show toasts in all 4 locations at once if you wanted to.
• Tore out and rewrote the dialog API as it's own separate entity
  • API is very similar to the toasts, so it should be fairly self explanatory how to use it.
  • Creating simple confirmation/multi option dialogs is now super easy, it shares the ActionButtons API with toasts.
  • Should be very simple to expand with any number of additional features, things like input fields.
  • Supports passing in a ViewModel and then it just renders that only, so any custom dialog is possible without having to jump through hoops.
  • No more async/tasks in the API, no blocking here either.
  • MessageBox style element has been included as part of this API.
• Fixed the background transparency animation for dialogs.

Outstanding Issues

• Documentation is fairly basic at the moment, I've written the entirety of the page for toasts but wanted to check it was formatted correctly and provided enough detail before I work on the dialogs page.
• I can't seem to figure out how to limit the number of toasts properly. The limit sort of works, but if you spam them quick enough it's possible to exceed the limit.
• Icon appearance isn't great for dialogs, I just slapped it together so it's working, it could probably be positioned a bit more sensibly.
• The PropertyGrid stuff which used SukiHost for displaying it in a dialog is currently not working because there is no longer a static instance, this might not even need to be fixed, you can probably just slap a PropertyGrid inside a dialog yourself.
• This is obviously going to need a fresh pair of eyes and some additional testing to make sure it's solid.

PR Addresses: #266

[kikipoulet]

The action buttons seems to mix between toasts sometimes :

Also, we need a way, a "shortcut", to quickly use toasts and dialogs in the current window without MVVM for guys who just want to quickly display a message in a simple app. Maybe just give this kind of dirty snippet in a method

 var sukiWindow = ((SukiWindow)TopLevel.GetTopLevel(((IClassicDesktopStyleApplicationLifetime)Application.Current.ApplicationLifetime).MainWindow));
        
var currentmanager = ((SukiToastHost) sukiWindow.Hosts.First(h => h is SukiToastHost)).Manager;

I know you won't like it ☠️

Otherwise this is great, especially calling toast like this

This is perfection.

Don't worry about the syling I will correct it at the end.

[sirdoombox]

I don't think there's a huge need to add a hacky workaround to the library, it's very easy to just implement it yourself if you don't want to bother with MVVM. I can add this workaround to the docs for people who want to have a lazy way to do it. Also this is basically how you should do it if you're not doing MVVM anyway.

<SukiWindow.Hosts>
	<SukiToastHost Name="ToastHost"/>
</SukiWindow.Hosts>

public class MainWindow : SukiWindow
{
	public static ISukiToastManager ToastManager = new SukiToastManager();

	public MainWindow()
	{
		ToastHost.Manager = ToastManager;
	}
}

// and then...

MainWindow.ToastManager.CreateToast()
	.Queue();

Button bleed is easily fixed, just an oversight with the pooling and I think I have an idea for how to fix the toast limits too so I'll get that done as well later on today when I get back.

[kikipoulet]

I don't think there's a huge need to add a hacky workaround to the library, it's very easy to just implement it yourself if you don't want to bother with MVVM. I can add this workaround to the docs for people who want to have a lazy way to do it. Also this is basically how you should do it if you're not doing MVVM anyway.

<SukiWindow.Hosts>
	<SukiToastHost Name="ToastHost"/>
</SukiWindow.Hosts>

public class MainWindow : SukiWindow
{
	public static ISukiToastManager ToastManager = new SukiToastManager();

	public MainWindow()
	{
		ToastHost.Manager = ToastManager;
	}
}

// and then...

MainWindow.ToastManager.CreateToast()
	.Queue();

Button bleed is easily fixed, just an oversight with the pooling and I think I have an idea for how to fix the toast limits too so I'll get that done as well later on today when I get back.

I agree, adding that to the doc will be enough 👍

[sirdoombox]

This is mostly complete now I think. I believe that adding new features/styling elements to dialogs and toasts should be much easier now and limit the breaking changes introduced going forward.

You can implement whatever visual changes you need to the SukiToast/SukiDialog and add some extra methods to SukiDialogBuilder/SukiToastBuilder as well as the FluentBuilder for each without having to modify the signature of existing methods forcing devs to make any changes. It also means we won't end up with 300 different overloads in SukiHost which is where I feel that type was heading.

[kikipoulet]

Had to resolve a conflict manually but it seems to be okay

[sirdoombox]

I'm not sure how you merged the PR without actually merging it, should it be closed?