An Iconic Disaster

[verelpode]

WinUI has delivered innovative and impressive new GUI elements, designs, and techniques, and the WinUI team has implemented many clever improvements. But of course, nobody is capable of 100% pure perfection, so some deficiences must exist in WinUI. So now I'd like to talk about a glaring exception in the impressive track record of WinUI; an area desperately in need of improvement: Icon rendering in WinUI hardly works -- it's a disaster currently.

Icons are a very important topic, considering that most apps uses multiple icons in multiple places in multiple kinds of GUI elements (icons in buttons, toolbars, menus, tabs, standalone, etc). Thus it's really surprising to observe that, currently, icon rendering hardly works in WinUI/UWP unfortunately. Considering the extreme ubiquity of icons in apps, I consider this to be a high priority topic.

Use a PNG image as an icon?

For starters, look at a really simple case where you have an instance of Windows.UI.Xaml.Media.Imaging.BitmapImage that was produced from a PNG, and you want to use this PNG BitmapImage as an icon. This should be super simple, right? But no, unfortunately neither Windows.UI.Xaml.Controls.BitmapIconSource nor Windows.UI.Xaml.Controls.BitmapIcon support the ability to render a specified instance of BitmapImage -- surprising but true.

To use your BitmapImage instance as an icon, you are forced to use Windows.UI.Xaml.Controls.Image to render it because BitmapIconSource cannot. This means that, in combination with the other problems I will describe, Windows.UI.Xaml.Controls.IconSourceElement is a nice idea but so badly broken that it's practically unusable currently.

See also: Proposal: Create IconSource from Bitmap stream #601

Use an SVG image as an icon?

For example, you have an SVG image file that you want to use as an icon in multiple places in your app. You're out of luck because the SVG renderer contains bugs. See the most recent messages in this issue:
SVG Image sources behave unpredictably. #825

The names of BitmapIconSource and BitmapIcon suggest that they will not render SVG images because SVG images are vector not bitmap. I haven't actually tested what happens if you try to set BitmapIconSource.UriSource to the URI of an SVG instead of a bitmap. Unfortunately an IconSource subclass named ImageIconSource does not exist currently.

I am surprised to observe that WinUI does not yet have good support for scalable vector icons, neither colored vector icons (such as SVG) nor monochrome vector icons/symbols (such as paths).

SymbolIconSource and SymbolIcon are often unusable

For example, imagine you want to create a button that looks similar to this:

Thus you write XAML like this:

<Button Margin="20">
	<StackPanel Orientation="Vertical">
		<IconSourceElement Width="64" Height="64" Margin="8">
			<IconSourceElement.IconSource>
				<SymbolIconSource Symbol="Refresh"/>
			</IconSourceElement.IconSource>
		</IconSourceElement>
		<TextBlock Text="Reload Data" FontSize="20" FontWeight="SemiBold"/>
	</StackPanel>
</Button>

But it fails because the above XAML renders as follows:

As you can see, regardless of how large or small you make your IconSourceElement, the symbol still renders at a constant size of 20! Yes, a constant size! I could hardly believe it. Shockingly, SymbolIconSource and SymbolIcon don't scale, and don't provide any way to manually configure the size of the icon, and don't have a FontSize property either. (A FontSize property wouldn't be the right solution but anyway it doesn't exist.)

Following is an awkward inconvenient inefficient workaround that uses a Viewbox element to hack the icon into scaling. An alternative workaround is to view SymbolIconSource as unusable, and stop using it entirely, and instead use a TextBlock element and set its TextBlock.FontSize property.

<Button Margin="20">
	<StackPanel Orientation="Vertical">
		<Viewbox Width="64" Height="64" Margin="8">
			<IconSourceElement>
				<IconSourceElement.IconSource>
					<SymbolIconSource Symbol="Refresh"/>
				</IconSourceElement.IconSource>
			</IconSourceElement>
		</Viewbox>
		<TextBlock Text="Reload Data" FontSize="20" FontWeight="SemiBold"/>
	</StackPanel>
</Button>

How IconSourceElement with SymbolIconSource should behave: The same as BitmapIconSource and Windows.UI.Xaml.Controls.Image -- both of those scale the icon/image whereas SymbolIconSource does not -- a strange inconsistency. The icon should be scaled in the same manner as an Windows.UI.Xaml.Controls.Image element does with its default setting of Stretch="Uniform", or the same as a Windows.UI.Xaml.Shapes.Path element with Stretch set to Uniform.

FontIconSource and FontIcon are also broken

FontIconSource and FontIcon are slightly less broken than SymbolIconSource because they have a FontSize property. Actually a FontSize property is a bad solution but at least there exists some way of changing the icon size, and a bad way of changing the icon size is better (less bad) than the nothing that SymbolIconSource provides.

The idea of applying a FontSize to an icon is strange and doesn't make sense. What makes sense is applying a Width and Height to an icon or image or path, not a FontSize. A FontSize property is applicable to text but an icon is not text, rather an icon is akin to an image or path.

Instead of trying to apply font size to an icon, SymbolIconSource and FontIconSource should scale the icon in the same manner as BitmapIconSource does.

SymbolIconSource handles white space better than FontIconSource. For example, have a look at how this SymbolIconSource snippet renders:

<Border Padding="0" HorizontalAlignment="Left" VerticalAlignment="Top" BorderBrush="CadetBlue" BorderThickness="2">
	<IconSourceElement Margin="0">
		<IconSourceElement.IconSource>
			<SymbolIconSource Symbol="Refresh"/>
		</IconSourceElement.IconSource>
	</IconSourceElement>
</Border>

The above rendering makes sense. The Border encloses the icon without padding. Now compare it with the failure of FontIconSource and FontIcon:

<Border Padding="0" HorizontalAlignment="Left" VerticalAlignment="Top" BorderBrush="CadetBlue" BorderThickness="2">
	<IconSourceElement Margin="0">
		<IconSourceElement.IconSource>
			<FontIconSource Glyph="↻" FontFamily="Global User Interface" />
		</IconSourceElement.IconSource>
	</IconSourceElement>
</Border>

As you can see above, FontIconSource and FontIcon render with padding/whitespace around the icon. In practice, this makes it difficult to use the icon in a button because the spacing/layout looks strange because of the uncontrollable extra space introduced by FontIconSource. The amount of white space on the left, top, right, and bottom sides varies depending on the font -- the white space comes from the font.

If you have several IconSourceElement instances, such as 10 different buttons (in a row) with icons, and some of those IconSourceElement instances use SymbolIconSource and some use FontIconSource and some use PathIconSource, then the 10 buttons look strange and inconsistent with each other because some have extra whitespace/padding (those that use FontIconSource) while the others don't.

FontIconSource and FontIcon are not any better than using a TextBlock element. They render the same as TextBlock. This rendering behavior makes no sense because they are supposed to render as icons not text.

If you use TextBlock instead of FontIcon, you might try to use the OpticalMarginAlignment property to eliminate the problematic whitespace/padding, but it doesn't work, as you can see following. The first image (left) is with OpticalMarginAlignment="None" and the second image (right) is with OpticalMarginAlignment="TrimSideBearings". As you can see, TrimSideBearings didn't trim anything at all, rather it moved the space on the left side to the right side (the total width remains unchanged), and it didn't trim the top and bottom sides, and no other trimming option exists in OpticalMarginAlignment.

<StackPanel Orientation="Horizontal">
	<Border Margin="5" Padding="0" HorizontalAlignment="Left" VerticalAlignment="Top" BorderBrush="CadetBlue" BorderThickness="2">
		<TextBlock Text="⎈" FontFamily="Global User Interface" FontSize="100" OpticalMarginAlignment="None" Margin="0" Padding="0"/>
	</Border>
	<Border Margin="5" Padding="0" HorizontalAlignment="Left" VerticalAlignment="Top" BorderBrush="CadetBlue" BorderThickness="2">
		<TextBlock Text="⎈" FontFamily="Global User Interface" FontSize="100" OpticalMarginAlignment="TrimSideBearings" Margin="0" Padding="0"/>
	</Border>
</StackPanel>

In WPF, one way of rendering a glyph/character as an icon (without whitespace/padding) is to do this:

1. Use either System.Windows.Media.FormattedText.BuildGeometry or System.Windows.Media.GlyphRun.BuildGeometry to convert the glyph/character to a Geometry instance.
2. Create an instance of System.Windows.Shapes.Path and set the Path.Data property to the Geometry returned by BuildGeometry.
3. Set the Path.Stretch property to Uniform.

Sadly, this technique cannot be used in WinUI because an equivalent of FormattedText.BuildGeometry does not exist in WinUI (or not that I'm aware of).

PathIconSource and PathIcon are unusable

For example, you have an instance of Windows.UI.Xaml.Media.PathGeometry that you want to use as a monochrome vector icon in multiple buttons, pages, or places in your app. This should be super simple, right? Just use Windows.UI.Xaml.Controls.PathIconSource or Windows.UI.Xaml.Controls.PathIcon and give it whatever PathGeometry instance you want? But no, unfortunately this fails to render. Surprising but true.

Following you can see the success of Windows.UI.Xaml.Shapes.Path versus the failure of Windows.UI.Xaml.Controls.PathIconSource (or PathIcon), when rendering the same PathGeometry (a house symbol). The first image (left) is the Path element -- it works. The second image (right) is PathIconSource -- a failed (truncated) rendering of an icon.

<StackPanel Orientation="Horizontal">
	<Border Margin="5" Padding="0" HorizontalAlignment="Left" VerticalAlignment="Top" BorderBrush="CadetBlue" BorderThickness="2">
		<Path Width="90" Height="90" Stretch="Uniform" Fill="Black">
			<Path.Data>
				M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
			</Path.Data>
		</Path>
	</Border>

	<Border Margin="5" Padding="0" HorizontalAlignment="Left" VerticalAlignment="Top" BorderBrush="CadetBlue" BorderThickness="2">
		<IconSourceElement Width="90" Height="90">
			<IconSourceElement.IconSource>
				<PathIconSource>
					<PathIconSource.Data>
						M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
					</PathIconSource.Data>
				</PathIconSource>
			</IconSourceElement.IconSource>
		</IconSourceElement>
	</Border>
</StackPanel>

The Path element succeeds because I set its Stretch property to Uniform, but this solution does not work for PathIconSource nor PathIcon -- they have no Stretch property. Thus PathIconSource and PathIcon are unusable and you're forced to use the Path element instead, which means that IconSourceElement is a nice idea but so badly broken that it's practically unusable currently.

The fact that PathIconSource and PathIcon don't scale the icon is especially strange when you consider that BitmapIconSource does scale the icon.

A second reason why PathIconSource and PathIcon are broken is that if you try to use the same icon in multiple buttons, pages, or places in your app, it fails (throws an exception). Unfortunately the Path element also suffers from the same failure, but it only fails in WinUI, not in WPF. In WPF, you can "freeze" a Geometry instance and then use it in an unlimited number of places in your app. For more info, see this issue:
PathIconSource claims to support sharing but throws exception (AKA shared Geometry issue) #827

If your PathGeometry instance represents a stroked figure instead of a filled figure, such as a "+" symbol consisting of a horizontal stroked lines over a vertical stroked line, then PathIconSource does not support your PathGeometry. See issue:
PathIcon/PathIconSource should allow stroke to be set as well as fill #1279

Library of icons in app (re ResourceDictionary)

Edited:
I remembered another important part of this issue. When using PathIconSource, obviously every app needs to store a collection of all the icons that the app uses (icons as paths/geometries in the case of PathIconSource). This should be super simple to do because WinUI already supports the excellent ResourceDictionary feature. Therefore, our problem is simply solved by storing the app's icons in a "MyResourceDictionary.xaml" file, right? But no, unfortunately this only works in WPF, whereas it is still broken in WinUI, even after the number of years that have elapsed since the release of UWP/WinUI.

In WPF, you can easily store a collection of icons in your app like this:

<ResourceDictionary xmlns="..." xmlns:x="...">

	<PathGeometry x:Key="HouseSymbol">
		M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
	</PathGeometry>

	<PathGeometry x:Key="RefreshSymbol">
		...
	</PathGeometry>

	<PathGeometry x:Key="SettingsSymbol">
		...
	</PathGeometry>

</ResourceDictionary>

Actually, to be precise, in WPF, it's recommended to optimize the above by simply replacing PathGeometry with the optimized read-only equivalent of PathGeometry that is named StreamGeometry. Easily done:

<StreamGeometry x:Key="HouseSymbol">
	M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
</StreamGeometry>

So that works great in WPF, but StreamGeometry is unsupported in WinUI. As for the other class, PathGeometry, it does exist in WinUI but it still produces a compile-time error message when you try to use it (PathGeometry) in a ResourceDictionary XAML file:

Error XLS0503
A value of type 'String' cannot be added to a collection or dictionary of type 'PathFigureCollection'.

This bug could be easily fixed AFAIK, because most of the necessary work is already done, therefore I find it surprising that this bug still hasn't been prioritized after this number of years. I thought it was standard recommended practice to increase the priority of a bugfix when the bug is easy to fix.

AFAIK the PathGeometry bug is easy to fix because the WinUI XAML compiler already compiles the following successfully, therefore most of the work is already done for PathGeometry.

<ResourceDictionary xmlns="..." xmlns:x="...">

	<Path x:Key="HousePathElement">
		<Path.Data>
			M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
		</Path.Data>
	</Path>

</ResourceDictionary>

Although Path in ResourceDictionary compiles successfully, you should use PathGeometry not Path. Path is derived from Windows.UI.Xaml.FrameworkElement and Windows.UI.Xaml.UIElement, and each FrameworkElement instance is permitted to have only one parent FrameworkElement instance, and this won't change. Thus you cannot (and should not) try to share the same Path instance among multiple different buttons in your app where the same icon needs to be used in multiple places.

Unlike the Path element, PathGeometry and/or StreamGeometry are suitable for being shared/used in multiple places, but as I mentioned in issue #827, it only works in WPF. Currently WinUI malfunctions (throws an exception) when you try to share/use the same PathGeometry or PathIconSource instance in multiple places, even despite the fact that the documentation says that sharing is supported:

"PathIconSource is similar to PathIcon. However, because it is not a FrameworkElement, it can be shared."

Notice how the documentation says "because it is not a FrameworkElement". This is the same reason why the ResourceDictionary should contain PathGeometry not Path. Path derives from FrameworkElement whereas PathGeometry does not.

The conclusion is that WPF (but not yet WinUI) supports the storage of the app's icons in a "MyResourceDictionary.xaml" file. This is very strange when you consider the fact that the only thing stopping WinUI from supporting it is a small easily-fixed bug in the XAML compiler. (Or maybe the bugfix is more difficult to implement than it appears, because maybe some reason exists that I don't know about, but anyway, this bug needs to be fixed.)

Apps definitely need this ability to store their own icons/symbols, instead of being limited to predefined icons from Microsoft. SymbolIconSource is an excellent feature (thanks!) but obviously it's unreasonable to limit apps to using only the predefined icons/symbols in the Windows.UI.Xaml.Controls.Symbol enumeration.

Classes were not updated for IconSource

When the IconSourceElement and IconSource classes was created in WinUI in order to replace the defective IconElement subclasses, unfortunately various other classes were not updated accordingly. They should have been updated at the same time as when IconSource was released. For example, in order to update MenuFlyoutItem, this needed to be done:

1. Create a property in MenuFlyoutItem named IconSource of type IconSource.
2. Mark the old property MenuFlyoutItem.Icon as obsolete by applying System.ObsoleteAttribute. (This old property uses Windows.UI.Xaml.Controls.IconElement.)

public class MenuFlyoutItem : ...
{
	public Windows.UI.Xaml.Controls.IconSource IconSource { get; set; }

	[System.ObsoleteAttribute("Use IconSource property instead of Icon property.")]
	public Windows.UI.Xaml.Controls.IconElement Icon { get; set; }
}

The following have not yet been updated:

• Windows.UI.Xaml.Controls.AppBarButton.Icon
• Windows.UI.Xaml.Controls.AppBarToggleButton.Icon
• Windows.UI.Xaml.Controls.MenuFlyoutItem.Icon
• Windows.UI.Xaml.Controls.MenuFlyoutSubItem.Icon
• Windows.UI.Xaml.Controls.NavigationViewItem.Icon
• Windows.UI.Xaml.Controls.Primitives.NavigationViewItemPresenter.Icon
• Windows.UI.Xaml.Controls.SettingsFlyout.IconSource (uses ImageSource not IconSource)

Already up-to-date:

• Windows.UI.Xaml.Controls.SwipeItem.IconSource
• Windows.UI.Xaml.Input.XamlUICommand.IconSource

Although the subclasses of IconSource currently render in a broken manner, this will be fixed and IconSource is still a good idea, thus the various other classes need to be updated to support IconSource instead of the old IconElement subclasses.

Conclusion: They're all broken!

Windows.UI.Xaml.Controls.IconSourceElement is a nice idea and its concept makes good sense, but unfortunately all subclasses of IconSource are currently broken:

• BitmapIconSource
• SymbolIconSource
• FontIconSource
• PathIconSource

Fixing this iconic disaster should be a high priority because icons are very common in apps. Despite the fact that nearly all apps use icons, icon rendering hardly works in WinUI!

[adrientetar]

A FontSize property is applicable to text but an icon is not text

In this case it is, that's why it's called FontIcon.

[verelpode]

In this case it is, that's why it's called FontIcon.

It's called FontIcon not TextIcon therefore it shouldn't behave like text, but currently it does behave like text and this text-like behavior causes failures. We could interpret (or re-interpret) it as being named "FontIcon/FontIconSource" because the icon comes from a glyph in a font, and don't interpret the name "FontIcon" as meaning that it should behave like text. Thus it shouldn't have a property that controls the size of the text, but it does. It's meant to (or needs to) behave as an icon not text.

In order to control the icon size, wouldn't you prefer to set the Width and Height properties of IconSourceElement or an ancestor element of your choice, rather than trying to control the icon size via FontIcon/FontIconSource.FontSize?

Before you answer, keep in mind that the concept of IconSourceElement is better than its predecessors BitmapIcon, SymbolIcon, FontIcon, PathIcon. The issue is that BitmapIcon etc are fundamentally defective designs because, for example, if you write some XAML for a ControlTemplate, UserControl, or Page etc and your XAML displays an icon by using BitmapIcon, then the icon is locked to being a bitmap -- that's a problem. The icon cannot be later changed to a path-based or font-based icon because your XAML uses BitmapIcon and BitmapIcon only supports bitmap icons.

This problem cannot be solved by simply editing the XAML to change BitmapIcon to PathIcon whenever you want to switch from a bitmap to a path -- this doesn't work because the person who writes the XAML of a ControlTemplate is often a different person than the various people who use it. The solution is to use IconSourceElement instead of BitmapIcon etc, and then the ControlTemplate works for everyone regardless of what kind of icon they want/need to use, and the ControlTemplate XAML doesn't require modification whenever someone simply needs to display a different kind of icon.

Thus IconSourceElement is an excellent concept, but in practice it only succeeds if IconSourceElement.IconSource can be set to any subclass of IconSource (any kind of icon) without breaking the size of the rendered icon. This means that each subclass of IconSource needs to behave consistently in regards to icon size, but currently they behave wildly differently than each other.

Currently, when you use IconSourceElement in the XAML of your ControlTemplate or Page or wherever, you can easily configure your IconSourceElement instance in a way that makes it render perfectly when IconSourceElement.IconSource is set to BitmapIconSource, but then your IconSourceElement instance breaks (renders incorrectly) as soon as IconSourceElement.IconSource is set to FontIconSource, SymbolIconSource, or PathIconSource. This causes IconSourceElement to be practically unusable, or at least it defeats the purpose of IconSourceElement.

In order to make IconSourceElement.IconSource interchangeable with any subclass of IconSource (any kind of icon), each subclass of IconSource needs to render the icon consistently with the same size as BitmapIconSource and Controls.Image do, meaning all subclasses of IconSource need to scale the icon to fit the available space. IconSourceElement breaks when different different subclasses of IconSource use completely different ways of controlling icon size such as FontIconSource.FontSize.

Thus the existence of FontIconSource.FontSize represents a design defect and it should be removed. However, if people still desire the option to use FontIconSource.FontSize, then instead of removing this property entirely, it could be made optional, meaning it could operate like this:

• When FontIconSource.FontSize is set to System.Double.NaN or defaults to NaN (similar to how the default value of FrameworkElement.Width is NaN), then it would render like BitmapIconSource, Controls.BitmapIcon, and Controls.Image already do: Scale the icon. This also makes the Width/Height/MinWidth/MaxHeight properties usable/settable in either IconSourceElement or an ancestor element of your choice.
• When FontIconSource.FontSize is not NaN, then it would operate the same as it does today: The FontSize property controls the size of the icon instead of the normal behavior of scaling the icon. This mode might be useful in some circumstances, but the disadvantage of this mode is that it breaks the interchangeability of IconSourceElement.IconSource.

[verelpode]

An analogy with the Image Control

Windows.UI.Xaml.Controls.Image defines these Source and Stretch properties:

public class Image : ...
{
	public Windows.UI.Xaml.Media.ImageSource Source { get; set; }
	public Windows.UI.Xaml.Media.Stretch Stretch { get; set; }
	...
}

The current design of the Image Control works well. Now imagine what would happen if you remove the Stretch property from Image and instead place it in ImageSource.

public class Image
{
	public Windows.UI.Xaml.Media.ImageSource Source { get; set; }
	...
}

public class ImageSource
{
	public Windows.UI.Xaml.Media.Stretch Stretch { get; set; }
	...
}

That would be madness, but let's imagine making it even worse by adding settable sizing properties to ImageSource akin to the Width/Height properties that Image contains/inherits from FrameworkElement:

public class FrameworkElement
{
	public double Width { get; set; }
	public double Height { get; set; }
	...
}

public class Image : FrameworkElement
{
	public Windows.UI.Xaml.Media.ImageSource Source { get; set; }
	...
}

public class ImageSource
{
	public Windows.UI.Xaml.Media.Stretch Stretch { get; set; }
	public double Width { get; set; }
	public double Height { get; set; }
	...
}

That would really be madness -- it'd cause chaos! I believe I don't need to explain why this would cause chaos, because everyone already understands and agrees that the Stretch, Width, Height properties need to be located in Image not in ImageSource. That's obvious.

However, despite the fact that everyone knows that placing Stretch, Width, Height in ImageSource would be madness, the current version of WinUI does engage in this madness anyway, but only in the case of IconSource not ImageSource.

I'm not saying that IconSource.Stretch exists (it doesn't exist), rather I mean that in principle IconSource subclasses behave with the same kind of madness as if IconSource.Stretch did exist:

• BitmapIconSource renders like Windows.UI.Xaml.Media.Stretch.Uniform.
• PathIconSource renders like Windows.UI.Xaml.Media.Stretch.None.
• SymbolIconSource renders like Windows.UI.Xaml.Media.Stretch.None plus a constant size of 20.
• FontIconSource renders like Windows.UI.Xaml.Media.Stretch.None plus a size determined by FontIconSource.FontSize. This FontSize property is the same madness as if ImageSource.Width/Height would exist instead of (or in addition to) Image.Width/Height.

In principle, the current behavior of IconSource subclasses is the same madness and chaos as if the Image.Stretch property would be moved to ImageSource.Stretch. Also in principle, FontIconSource.FontSize is the same chaos as if settable ImageSource.Width/Height properties would exist.

The WinUI team has repeatedly delivered impressive stuff, except for the dysfunctional icon rendering. No big deal; just fix it and become even greater! 😄

[kikisaints]

@jevansaks - is this a proposal? It feels more like a discussion that should lead to one or more proposals.

@verelpode you make some really good points - to summarize and ensure I understand what you're saying, it's that:

• IconSource's API structure/behavior is inconsistent with that of similar components, like Image and ImageSource
• Subclassing IconSource to Bitmap/Symbol/Font/PathIconSource all result in different sizing behavior that isn't consistent and renders IconSource rather unusable because of this
• If IconSource's sizing behavior operated in a similar way to how Image and ImageSource work, it would mean that FontIconSource is practically obsolete, because the need to size the icon would be mostly handled by the system or through height/width properties instead of a "FontSize" property.

Is the above summary correct?

[verelpode]

Hi @kikisaints, thanks for the quick reply.

IconSource's API structure/behavior is inconsistent with that of similar components, like Image and ImageSource.

Correct.

Subclassing IconSource to Bitmap/Symbol/Font/PathIconSource all result in different sizing behavior that isn't consistent and renders IconSource rather unusable because of this.

Correct.

If IconSource's sizing behavior operated in a similar way to how Image and ImageSource work, it would mean that FontIconSource is practically obsolete, because the need to size the icon would be mostly handled by the system or through height/width properties instead of a "FontSize" property.

There's a typo in that point. The typo can be correct as follows:

"If IconSource's sizing behavior operated in a similar way to how Image and ImageSource work, it would mean that FontIconSource the property FontIconSource.FontSize is practically obsolete, because ...."

The FontIconSource class is a good idea; don't throw it in the garbage bin; just fix its problems and it will become great. The two problems with FontIconSource are:

1. The sizing behavior / "FontSize" property as mentioned above.
2. The glyph needs to be rendered without the whitespace/padding that currently surrounds the glyph. In other words, the whitespace/padding behavior of FontIconSource needs to be made consistent with SymbolIconSource. (To implement this fix, note that in WPF, BuildGeometry is one way of eliminating the whitespace/padding.)

I also suggest that the following points are important for inclusion in a summary:

• A common requirement is to share or use the same icon in multiple different places in the app, but this fails (throws an exception) despite the documentation saying that PathIconSource supports sharing.
• The WinUI XAML compiler fails to compile PathGeometry in ResourceDictionary XAML files. See details in my next message.

The first or second version of something is hardly ever great, but who cares? What I love about software development is that we can produce a third or fourth version that is great, and erase the mistakes of the first and second versions. The concept of IconSourceElement is solid and if a new version is released, then WinUI's support for icons can definitely become great. Success is not far away! 😄

[verelpode]

Library of icons in app (re ResourceDictionary)

I remembered another important part of this issue. When using PathIconSource, obviously every app needs to store a collection of all the icons that the app uses (icons as paths/geometries in the case of PathIconSource). This should be super simple to do because WinUI already supports the excellent ResourceDictionary feature. Therefore, our problem is simply solved by storing the app's icons in a "MyResourceDictionary.xaml" file, right? But no, unfortunately this only works in WPF, whereas it is still broken in WinUI, even after the number of years that have elapsed since the release of UWP/WinUI.

In WPF, you can easily store a collection of icons in your app like this:

<ResourceDictionary xmlns="..." xmlns:x="...">

	<PathGeometry x:Key="HouseSymbol">
		M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
	</PathGeometry>

	<PathGeometry x:Key="RefreshSymbol">
		...
	</PathGeometry>

	<PathGeometry x:Key="SettingsSymbol">
		...
	</PathGeometry>

</ResourceDictionary>

Actually, to be precise, in WPF, it's recommended to optimize the above by simply replacing PathGeometry with the optimized read-only equivalent of PathGeometry that is named StreamGeometry. Easily done:

<StreamGeometry x:Key="HouseSymbol">
	M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
</StreamGeometry>

So that works great in WPF, but StreamGeometry is unsupported in WinUI. As for the other class, PathGeometry, it does exist in WinUI but it still produces a compile-time error message when you try to use it (PathGeometry) in a ResourceDictionary XAML file:

Error XLS0503
A value of type 'String' cannot be added to a collection or dictionary of type 'PathFigureCollection'.

This bug could be easily fixed AFAIK, because most of the necessary work is already done, therefore I find it surprising that this bug still hasn't been prioritized after this number of years. I thought it was standard recommended practice to increase the priority of a bugfix when the bug is easy to fix.

AFAIK the PathGeometry bug is easy to fix because the WinUI XAML compiler already compiles the following successfully, therefore most of the work is already done for PathGeometry.

<ResourceDictionary xmlns="..." xmlns:x="...">

	<Path x:Key="HousePathElement">
		<Path.Data>
			M81.799,0 L163.599,75.636001 146.368,75.636001 146.368,136.341 17.229999,136.341 17.229999,75.636001 0,75.636001 23.987998,53.455336 23.987998,16.938999 53.620998,16.938999 53.620998,26.054981 z
		</Path.Data>
	</Path>

</ResourceDictionary>

Although Path in ResourceDictionary compiles successfully, you should use PathGeometry not Path. Path is derived from Windows.UI.Xaml.FrameworkElement and Windows.UI.Xaml.UIElement, and each FrameworkElement instance is permitted to have only one parent FrameworkElement instance, and this won't change. Thus you cannot (and should not) try to share the same Path instance among multiple different buttons in your app where the same icon needs to be used in multiple places.

Unlike the Path element, PathGeometry and/or StreamGeometry are suitable for being shared/used in multiple places, but as I mentioned in issue #827, it only works in WPF. Currently WinUI malfunctions (throws an exception) when you try to share/use the same PathGeometry or PathIconSource instance in multiple places, even despite the fact that the documentation says that sharing is supported:

"PathIconSource is similar to PathIcon. However, because it is not a FrameworkElement, it can be shared."

Notice how the documentation says "because it is not a FrameworkElement". This is the same reason why the ResourceDictionary should contain PathGeometry not Path. Path derives from FrameworkElement whereas PathGeometry does not.

The conclusion is that WPF (but not yet WinUI) supports the storage of the app's icons in a "MyResourceDictionary.xaml" file. This is very strange when you consider the fact that the only thing stopping WinUI from supporting it is a small easily-fixed bug in the XAML compiler. (Or maybe the bugfix is more difficult to implement than it appears, because maybe some reason exists that I don't know about, but anyway, this bug needs to be fixed.)

Apps definitely need this ability to store their own icons/symbols, instead of being limited to predefined icons from Microsoft. SymbolIconSource is an excellent feature (thanks!) but obviously it's unreasonable to limit apps to using only the predefined icons/symbols in the Windows.UI.Xaml.Controls.Symbol enumeration.

Note my message here is a different issue than #827 because #827 describes the sharing failure whereas the main point of my message here is the failure of the XAML Compiler to compile PathGeometry in ResourceDictionary.

[verelpode]

Classes were not updated for IconSource

When the IconSourceElement and IconSource classes was created in WinUI in order to replace the defective IconElement subclasses, unfortunately various other classes were not updated accordingly. They should have been updated at the same time as when IconSource was released. For example, in order to update MenuFlyoutItem, this needed to be done:

1. Create a property in MenuFlyoutItem named IconSource of type IconSource.
2. Mark the old property MenuFlyoutItem.Icon as obsolete by applying System.ObsoleteAttribute. (This old property uses Windows.UI.Xaml.Controls.IconElement.)

public class MenuFlyoutItem : ...
{
	public Windows.UI.Xaml.Controls.IconSource IconSource { get; set; }

	[System.ObsoleteAttribute("Use IconSource property instead of Icon property.")]
	public Windows.UI.Xaml.Controls.IconElement Icon { get; set; }
}

The following have not yet been updated:

• Windows.UI.Xaml.Controls.AppBarButton.Icon
• Windows.UI.Xaml.Controls.AppBarToggleButton.Icon
• Windows.UI.Xaml.Controls.MenuFlyoutItem.Icon
• Windows.UI.Xaml.Controls.MenuFlyoutSubItem.Icon
• Windows.UI.Xaml.Controls.NavigationViewItem.Icon
• Windows.UI.Xaml.Controls.Primitives.NavigationViewItemPresenter.Icon
• Windows.UI.Xaml.Controls.SettingsFlyout.IconSource (uses ImageSource not IconSource)

Already up-to-date:

• Windows.UI.Xaml.Controls.SwipeItem.IconSource
• Windows.UI.Xaml.Input.XamlUICommand.IconSource

[verelpode]

Icons in "Visual Assets" in manifest

On the topic of icons, unfortunately I also had a disappointing experience when configuring the icons in the "Visual Assets" tab in the "Package.appxmanifest" of a WinUI UWP app in Visual Studio 2019.

Lack of knowledge of runtime image scaling

The current design of "Visual Assets" represents a surprising lack of knowledge of the commonly-known fact that at runtime an image can be quickly and easily rendered at a smaller or larger size -- scaled to fit any rectangle. This rendering-with-scaling is quick regardless of whether the app is running in a smartphone or desktop computer. When the image is rendered at exactly 50% or 25% size, the scaling is even faster and delivers excellent image quality. Here is a screenshot of the current GUI for "Large Tile":

As you can see above, it recommends that the app developer provide 3 sizes of the same image, plus 2 optional sizes (up to 5 sizes of the same image). Thus it represents lack of knowledge of the fact that only one image file is required for "Large Tile" because the image can be scaled at runtime.

As I mentioned, the quality and speed is especially good when the rendered size is 50% or 25% of original. As you can see in the screenshot above, the 3 recommended sizes are 1240, 620, and 310 and those are multiples of 310. 50% of 1240 is 620, and 25% of 1240 is 310. Thus if only one image is provided, and if that one image is 1240x1240 px, then the 620 and 310 versions can be rendered at runtime with excellent image quality and speed, even better than if they weren't multiples. The current GUI for configuring "Large Tile" (with 5 sizes of the same image) is nonsense.

"Scaling Mode" option makes no sense

This lack of knowledge of image scaling is further evident in the "Scaling Mode" option that provides 2 choices named:

• "Bicubic (Sharper Edges)"
• "Nearest Neighbor (Smoother Edges)"

Both of those descriptions are wrong. For "Nearest Neighbor", it says "Smoother Edges", but Adobe Photoshop says the opposite: "Nearest Neighbor (preserve hard edges)". Visual Studio says the opposite of both Photoshop and Wikipedia. Wikipedia says "Nearest-neighbor ... introduce jaggedness in previously smooth images."

Not only are the descriptions wrong, but Visual Studio's "Scaling Mode" option shouldn't exist at all, because "Nearest Neighbor" never produces a better result than bicubic scaling (for the purpose of Visual Studio). Furthermore, the scaling should be performed at runtime, not in Visual Studio, meaning only one image file should be provided for "Large Tile". Thus the "Scaling Mode" option should be removed from "Visual Assets".

Word wrapping is broken

Another problem is word wrapping. In the section titled "Display Settings", you can enter a name in the textbox "Short name" and you can tick "Show name", but when the tile is displayed in the Start menu, the name fails to wrap onto 2 lines, despite the fact that other Microsoft products somehow do achieve 2 lines. For example, MS Blend displays as:

In your own app, if you set "Display Settings" to "Blend for Visual Studio 2019", then it appears with only one line, truncated:

Nonsense file names

For "Small Tile", the default file name is "SmallTile.png" and that makes sense. Likewise for "Large Tile", the default file name is "LargeTile.png" and again that makes sense. Now what do you think the file name is for "Medium Tile"? A sensible guess would be "MediumTile.png", but no, the name is "Square150x150Logo.png", even when the PNG file is not 150x150 pixels. That's nonsense.

The problem repeats itself for "App Icon". What do you think the file name is for "App Icon"? A sensible guess would be "AppIcon.png", but no, the name is "Square44x44Logo.png", even when the PNG file is not 44x44 pixels. Likewise for "Wide Tile", you'd expect "WideTile.png", but no, the name is "Assets\Wide310x150Logo.png". The file name says "Logo" instead of "Tile", and it says 310x150 even when the PNG file is not 310x150 pixels.

A file named "Wide310x150Logo.scale-200.png" is not 310x150 pixels. It's actually 620 x 300 pixels. The file name includes the text "scale-200" but that's ridiculous, as I explained previously in regards to runtime image scaling and 50% and 25%.

When you click any asset within the "Large Tile" section, such as when you click 620x620 px, a window appears and describes the asset incorrectly. It says the wrong name and wrong size. Instead of saying "Large Tile 620x620", it says "Square 310x310 logo". It says: "This asset is used for the Square 310x310 logo field and is shown in the following location(s)." The underlying XML schema says "Square310x310Logo" but unfortunately that design is nonsense.

Requirement for "Wide Tile" is nonsense

Here is a screenshot of the nonsensical message that appears when you try to delete "Wide Tile":

Reasons why that message is nonsense:

• The words "Square 310x310 logo" are nonsense -- it actually means "Large Tile".
• The logic of the requirement is reversed. Logically speaking, if the Medium and Large Tiles are supplied, then they can also be used to render the Wide Tile by default, by rendering the icon in the center of the Wide Tile. If you have a medium icon, you can use it to render a wide tile, but the message says the opposite: It says if you have an icon, then you must provide another icon. It's nonsense.
• (I do realize that some apps will want or need to supply a Wide Tile image, but it shouldn't be mandatory, and it shouldn't have 5 size of the same image.)

In the "Wide Tile" section, 3 assets are recommended, but nothing should be recommended by default in Wide Tile, and nothing in Wide Tile should be mandatory (regardless of whether "Square 310x310" is supplied). "Wide Tile" can be supported but it's hardly a good recommendation. Except for games, none of the Microsoft apps use the "Wide Tile" visual asset. The Microsoft Weather app does not use it either. Weather supports wide tiles via live tile, NOT via a Visual Asset.

"Medium Tile" is mandatory for no reason

I fully supplied the "App Icon" section of "Visual Assets", and then I tried to delete the unnecessary images in the "Medium Tile" section, and then it displayed the following nonsensical error message:

That error message is nonsense because:

1. The words "Square 150x150 logo" are incomprehensible and need to be replaced with a choice of words that people can actually understand, meaning it needs to say "Medium Tile" instead of "Square 150x150 logo". I have a double degree from a respected university but the words "Square 150x150 logo" are still mumbo-jumbo that I could not understand and were forced to decipher.
2. The error message does not state any reason for making "Medium Tile" mandatory, because no reason exists, but if something will be made mandatory, then it's necessary to have at least one reason for making it mandatory. In this case, the number of reasons is zero, thus it shouldn't be mandatory.
3. The idea of making "Medium Tile" contain a duplicate of the image in "App Icon" makes no sense. There is no need for "Visual Assets" to produce so many duplicates of the same image.

Here is a sensible design: If "Medium Tile" is supplied, then use it. If it's unsupplied, then use the image(s) in "App Icon" to render the "Medium Tile" at runtime, as the default behavior. Visual Studio's default behavior of duplicating the same image in "Medium Tile" and "App Icon" makes no sense. You click the "Generate" button and suddenly you have many unnecessary duplicates of the same image!

Other problems in "Visual Assets"

• The "Visual Assets" GUI fails to provide any way to delete an unwanted asset or scale. You can delete an entire group but not an individual scale.
• When you click the 1240 x 1240 large tile, it displays the image in a window but the window has no scrollbars and the window is so large that the "Close" button is offscreen, despite the fact that my computer has a relatively large monitor attached.
• Too many assets are recommended yet unnecessary and serve no purpose.
• By default, the "Asset Generator" auto-generates images for "App Icon" and tiles, but it strangely also generates an image for the splashscreen, despite the fact that it makes no sense to display an icon as a splashscreen.
• "Apply recommended padding" would be more useful if it allowed the app developer to choose an amount of padding, instead of using the "recommended" amount that doesn't work well for all icons/tiles.
• When you click "Large Tile" on the lefthand side, you expect it to show the settings for "Large Tile", but it also shows some settings that affect "Medium Tile" and "Wide Tile" (the settings in the "Display Settings" section).