Task dialogs!

[amwx]

As spec'd out in #94, TaskDialogs are coming soon to FluentAvalonia! There have been some design changes from the original spec, but I think you'll like them - some changes came from the from the proposal in WinUI's repo linked to in the original issue. I've focused on customization with the dialogs to ensure they allow you to easily do what you need them to, without making them a nightmare.

One big change compared to ContentDialogs, is that TaskDialogs can launch in their own modal dialog window. This utilizes CoreWindow, which now has some additional features to properly handle the caption buttons for dialog states (i.e., the min and max/restore buttons are hidden). Unfortunately for Mac/Linux, you'll get the default behavior for dialog windows in Avalonia, which may still show the minimize button. The benefit for this though is you're no longer bound to the app window dimensions.
For platforms that don't support windows, TaskDialog falls back to the ContentDialog behavior and uses the OverlayLayer. I've included the ContentDialog animation and shadows for this scenario too. You can also force this behavior on windowing platforms if you'd like.

Here's what they look like:

Yes, that is a ProgressBar built into the dialog - it supports normal and indeterminate, and can be set to show an error state (turns red) or suspended state (turns yellow).

The footer area has a few visibility options (never, auto, and always). Never is self-explanatory. Always means the footer content shows without the "More Details" button. Auto means the footer area can be expanded open with the "More Details" button. The labels "More Details" and "Less Details" are resources, thus you can easily change them by just overriding that resource

TaskDialog buttons and commands are created by you using abstractions (TaskDialog creates the actual controls), but just about everything is able to be updated while the dialog is showing - thus you can react and dynamically change the content as needed. The only thing you can't do is add or remove buttons/commands after showing. That is not supported and will not be.

It does support a default button (which can either be a button or a command), and the Enter key will respond to that. Escape will also close the dialog. Keyboard navigation within the dialog though is limited to default Tab behavior for now.

Known issues / design decisions:

• I know the icons in the buttons are mis-aligned with the text. There's a couple issues with the symbol font I need to look at (alignment, anti-aliasing) that I think is behind this - just need the time.
• Despite having the icon and description properties (inherited), checkboxes and radiobuttons in the command area ignore these. This was a design decision and will not change at this time.

[robloo]

There's a couple issues with the symbol font I need to look at (alignment, anti-aliasing) that I think is behind this - just need the time.

Hm, let me know if you need me to look at something here. Hopefully it is a problem that can be solved without too much trouble. Its possible to custom position glyphs in FontForge but its always tricky getting the scripts to work. Its also not feasible to do that for each glyphs for maintainability concerns.

That said, the glyphs for standard controls seem to be positioned just fine? That uses the same symbols font for ComboBox, etc as you know.

[robloo]

Just FYI for fluent v2 styles (example ContentDialog) the middle content area is the light color background and then the header and bottom buttons are dark backgrounds. Right now you have the header with the light color background. So while it looks good, and is the way things were done historically, it doesnt quite match Fluent v2.

Awesome control though. Looking really good!

[amwx]

There's a couple issues with the symbol font I need to look at (alignment, anti-aliasing) that I think is behind this - just need the time.

Hm, let me know if you need me to look at something here. Hopefully it is a problem that can be solved without too much trouble. Its possible to custom position glyphs in FontForge but its always tricky getting the scripts to work. Its also not feasible to do that for each glyphs for maintainability concerns.

That said, the glyphs for standard controls seem to be positioned just fine? That uses the same symbols font for ComboBox, etc as you know.

So the alignment issue seems to a combination of things. 1) It does seem like the symbols render unevenly, at least when placed in a Viewbox, either its not centered or the baseline is just naturally high. 2) Segoe UI family has a lower baseline - which makes it seem lower when VerticalAlignment=Center.

In order from LTR:
SymbolIcon,
SymbolIcon,
SymbolIcon,
TextBlock with FluentSystemIcons-Regular
TextBlock with Segoe UI Variable Text

FluentSystemIcons seems to render fine, so I think it might be something with FontForge? Or this is entirely correct, and margins are in order. Elsewhere, I think lack of Viewbox and just being absolutely positioned via margins hides this issue

Aliasing is an issue I've seen though since switching. The three that stand out to me are the Dismiss and ArrowLeft icons are rendering too thick:

and the Navigation icon's middle line is rendering 1px off:

This I haven't had a chance to figure out whether it's FontForge, my rendering, or Skia acting up though. I need to go back and check if I had this issue when using the FluentSystemIcons font.

Just FYI for fluent v2 styles (example ContentDialog) the middle content area is the light color background and then the header and bottom buttons are dark backgrounds. Right now you have the header with the light color background. So while it looks good, and is the way things were done historically, it doesnt quite match Fluent v2.

Awesome control though. Looking really good!

That's a design decision on my part. I originally had it like the ContentDialog, but I didn't like how monochrome the whole thing looked, so I added a lighter color to the header. The buttons are still a darker color though. It It's a lightweight styleable resource, so it can always be overridden. I'm open to other thoughts, but I think it helps lift the dialog up, and helps distinguish that this is an entirely different control from the ContentDialog, not just a light enhancement.

[nlogozzo]

That's a design decision on my part. I originally had it like the ContentDialog, but I didn't like how monochrome the whole thing looked, so I added a lighter color to the header. The buttons are still a darker color though. It It's a lightweight styleable resource, so it can always be overridden. I'm open to other thoughts, but I think it helps lift the dialog up, and helps distinguish that this is an entirely different control from the ContentDialog, not just a light enhancement.

I think the way you have the ContentDialog styles now are perfect

[robloo]

I was having issues with even PathIcon alignment within Viewbox in the past with Avalonia. If you tried using the path from the ComboBox in Avalonia itself would it appear similar? I just want to make sure the issue is only with text.

I also checked the glyph alignment in FluentAvalonia/WinSymbols3 TTF fonts with:
https://fontdrop.info/#/?darkmode=true and
https://torinak.com/font/lsfont.html

But I don't see anything grossly wrong. A few glyphs could be repositioned a pixel or two to better center them. However, I'm not sure how Microsoft does the build and they might have some transforms there. FontForge is also automatically transforming the SVG and I don't think I can configure too much during source import (unless I modified the SVG xml). Afterwards, things can be adjusted though. Here is how it currently works: https://github.com/robloo/SymbolIconManager/blob/ef66959fc07af0101cc3eede34d63408597d3f18/Source/Models/FontBuilder.cs#L160-L180

Concerning the difference in size, I think that is just the size variation chosen for Segoe UI Fluent. The smaller, 14, 16, etc. variants have wider strokes than 20px/24px which is what was used. Of course the sources for these glyphs are not actually the same either so it could be a design decision difference between Windows / Fluent UI System as well.

[amwx]

I was having issues with even PathIcon alignment within Viewbox in the past with Avalonia. If you tried using the path from the ComboBox in Avalonia itself would it appear similar? I just want to make sure the issue is only with text.

I also checked the glyph alignment in FluentAvalonia/WinSymbols3 TTF fonts with: https://fontdrop.info/#/?darkmode=true and https://torinak.com/font/lsfont.html

But I don't see anything grossly wrong. A few glyphs could be repositioned a pixel or two to better center them. However, I'm not sure how Microsoft does the build and they might have some transforms there. FontForge is also automatically transforming the SVG and I don't think I can configure too much during source import (unless I modified the SVG xml). Afterwards, things can be adjusted though. Here is how it currently works: https://github.com/robloo/SymbolIconManager/blob/ef66959fc07af0101cc3eede34d63408597d3f18/Source/Models/FontBuilder.cs#L160-L180

Concerning the difference in size, I think that is just the size variation chosen for Segoe UI Fluent. The smaller, 14, 16, etc. variants have wider strokes than 20px/24px which is what was used. Of course the sources for these glyphs are not actually the same either so it could be a design decision difference between Windows / Fluent UI System as well.

I'm gonna do a deeper look into this later and if I find anything I'll open up an issue on your SymbolIconManager repo and we can continue our discussion there. But I agree there's nothing too out of place anywhere, it just in certain situations

[amwx]

v1.3-beta package will be released shortly after merging. There's a few more bug fixes to do before full v1.3 package, but beta package will now make TabView and TaskDialog available outside of master. More on the v1.3 next week