An Iconic Disaster #1494
Comments
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 Before you answer, keep in mind that the concept of This problem cannot be solved by simply editing the XAML to change Thus Currently, when you use In order to make Thus the existence of
|
An analogy with the Image Control
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 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 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 However, despite the fact that everyone knows that placing I'm not saying that
In principle, the current behavior of The WinUI team has repeatedly delivered impressive stuff, except for the dysfunctional icon rendering. No big deal; just fix it and become even greater! 😄 |
|
@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:
Is the above summary correct? |
|
Hi @kikisaints, thanks for the quick reply.
Correct.
Correct.
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 The
I also suggest that the following points are important for inclusion in a summary:
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 |
Library of icons in app (re ResourceDictionary)I remembered another important part of this issue. When using 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 <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 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 <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 Unlike the
Notice how the documentation says "because it is not a FrameworkElement". This is the same reason why the 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. 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 |
Classes were not updated for IconSourceWhen the
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:
Already up-to-date:
|
msft-github-bot
added
the
needs-triage
Icons in "Visual Assets" in manifestOn 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 scalingThe 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 senseThis lack of knowledge of image scaling is further evident in the "Scaling Mode" option that provides 2 choices named:
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 brokenAnother 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 namesFor "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 nonsenseHere is a screenshot of the nonsensical message that appears when you try to delete "Wide Tile":
Reasons why that message is nonsense:
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 reasonI 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:
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"
|
|
On a few occasions in the past, I produced amateurish work, but I'm proud to say that I revisited my work and transformed it from amateurish to professional, and the customers loved receiving the improvements. Everyone produces amateurish work sometimes. The current version of "Visual Assets" is one of these examples of things that need to be transformed from amateurish to professional. Here is a screenshot of the files that Visual Studio 2019 produces when you auto-generate every image in "Visual Assets". A fair and accurate description of this behavior is: Amateurish. The file list is not long because it's advanced and powerful. In reality, the list is long because it's amateurish work and falls far below the usual high standards of UWP. Many things in UWP are advanced and powerful and wonderful, but "Visual Assets" is not yet one of them.
Microsoft has experienced some difficulties in convincing app developers to develop for Windows Phone instead of (or in addition to) Android and Apple iOS. One factor to keep in mind is the effect of first impressions. First impressions count. When an app developer used other products in the past, and one day uses Visual Studio for the first time, what will his/her first impression be? The first impression when seeing "Visual Assets" is that Microsoft seems amateurish, and then the app developer begins to wonder: "If Microsoft couldn't even manage to do the app icon/tile, then what's the rest of UWP like? Is the whole thing amateurish?" In reality, UWP is really great stuff -- UWP is advanced and professional -- but app developers can be misled by the bad first impression of "Visual Assets". What happens next? App developers swallow the amateurish "Visual Assets" and then start writing an app and they try to create some icons inside of their app, and then they discover that WinUI's icon rendering is badly broken, hardly works, and the first impressions deteriorate even further. This is a sad result because in reality many things in WinUI and UWP are wonderful, but the first impressions (icons) can mislead developers into thinking that UWP is low quality. |
|
I struggled with that form too. I was trying to figure out the unplated/plated/light mode/dark mode rules and this form was no help. It is a very unintuitive “tool”. |
|
@moshegutman -- Oh yes, "unplated" is another problem; thanks for reminding me. I can explain "unplated". Surprisingly, the newly-invented term/jargon "unplated icon" means "a normal icon" in the normal sense of the word "icon". This raises the question: If "unplated icon" just simply means a normal icon, then why not speak normally and just simply say "icon" instead of confusing everyone by inventing a new term that means the same as the preexisting word "icon"? I can think of two possible answers to this perplexing question. I'm pretty sure that the answer is one of these:
In the case of the "unplated" jargon, I think the answer is probably number 1, an honest mistake. In various other cases in life, the answer is number 2. |
|
Yeah, I think it goes back to the windows phone days where the tile background in the start menu is the “plate” that the icon is on. But either way, through Visual Studio it isn’t possible to make all the variations of icons needed for a proper app. |
|
I suspect that the Visual Assets recommendations will be changing with WinUI 3.0 - because of the new icon styles used by Windows 10 X |
|
Here are a few more things that are unfortunately bungled in "Visual Assets".
More is bungled. The following screenshot shows the default setting of "Tile background" -- "transparent". When "Tile background" is "transparent", the tile background is opaque! Yes, in this case, "Visual Assets" uses the word "transparent" to mean "opaque". How can you configure it to be truly transparent? You cannot. It's always opaque. I have no complaint about it being always opaque, but if it's always opaque, then it shouldn't say transparent. "Visual Assets" uses the word "transparent" to mean "non-transparent default tile background color".
@mdtauk wrote:
I haven't looked at 10X, but do you mean the "Windows Light Theme"? If yes, then this is already in Visual Studio 2019 -- see the icons called "Light Unplated Target" in the "App Icon" section of "Visual Assets". In the "Asset Generator" section, the option "Apply color conversion for Windows Light Theme" seems to be badly broken, or at least it didn't work with the icons I tested it with. I didn't have time to perform a comprehensive test with many icons, but I did test the main feature that should work: I tested with an icon that has a light gray border meaning it is intended for use on a dark background. This means that for the "Windows Light Theme", the light version of the icon needs the light gray border to be changed to a dark gray border, but "Apply color conversion for Windows Light Theme" completely failed to do this. It did make a modification to the icon, but it was a weird pixelated modification that didn't appear to be even remotely successful. Not often, but occasionally Microsoft does attempt impossibly difficult tasks -- tasks that are far too difficult to achieve, even for a company as large as Microsoft. My impression of "Apply color conversion for Windows Light Theme" is that it seems to be one of these few cases where Microsoft attempts an impossibly difficult task. Therefore I think that Microsoft shouldn't attempt to repair this option, rather Microsoft should remove it entirely, because Microsoft does not possess sufficient resources to achieve impossibly difficult tasks. Alternatively, if it won't be removed, then give it a completely different name such that it will no longer be an impossibly difficult task. I gave this issue the title "An Iconic Disaster" because the current situation for icons really is an iconic disaster. The icon support is terrible currently. But overall UWP and WinUI are excellent. Keep up the good work! 😄 |
|
Unfortunately I still haven't finished the substantial work of documenting the list of defects in "Visual Assets"
"Tile background" behaves incorrectly in the "App Icon" section:
You can see in the above screenshot that the first row is labelled "Scaled Assets" but the other 3 rows are missing their labels -- that's a strange inconsistency. The last 2 rows are the so-called "unplated icons" meaning actually "normal icons" that don't have a plate/tile. Confusingly, Visual Assets uses multiple different words for the same things, thus plate = tile, and unplated = non-tile. As you can see above, the non-tile icons (the last 2 rows) are incorrectly rendered with the blue tile background. Obviously that's a mistake because non-tile icons shouldn't be rendered as tiles, thus the color specified in the "Tile background" textbox shouldn't be rendered under the non-tile ("unplated") icons, but it is. If you click on any of the unplated icons, it displays a window like the following, and you can see it says the icon is used in Windows Explorer etc, but NOT used as a tile. The "Tile background" color is incorrectly rendered in the preview despite the fact that it isn't a tile.
A few other defects are also visible in the above window, such as the wrong name ("Square 44x44 Logo"), and also the fact that it doesn't say "unplated" in this window despite the fact that I clicked on an icon that did say "unplated". To summarize, the defects in the "App Icon" section include these:
Icons and tiles for an app should be a simple issue. It shouldn't require a PhD to understand it. It shouldn't require hours of deciphering. It shouldn't require the following ridiculous translation table.
I'd like to hilite an excellent piece of advice that @codendone mentioned in another issue. Although the other issue was unrelated to icons, this advice is also applicable to icons and many other topics in general. He wrote:
That's an important principle. The current version of "Visual Assets" runs very contrary to this important principle. I don't say that "Visual Assets" should be reduced to only one single PNG file, but it shouldn't be 55 PNG files. Let's not jump to either extreme. Currently it generates/uses up to 55 PNG files -- that's ridiculous. A reasonably balanced solution is needed and 55 images is far away from being reasonably balanced between simplicity and full functionality. The full functionality can be retained with a much simpler design of "Visual Assets". |
|
I've saved the best for last. Here is the number 1 most absurd thing about the current version of "Visual Assets". When you use "Asset Generator" with its "Recommended Scales" setting, and you want to use the full tile area thus you untick "Apply recommended padding" (or tick it if you want), and you give it a source tile image of a reasonable size such as 300x300 or whatever, then as I said it generates many unnecessary smaller duplicates of the same image for no reason, but that's not all it does. Here comes the number 1 most absurd thing: In the "Large Tile" section, it takes the 300 x 300 source image file and scales it UPWARDS to produce a big blurry 1240 x 1240 PNG file that consumes roughly 1 megabyte on average!! That upwards scaling to 1240 x 1240 is so absurd that if Mac users knew about this, they'd burst out laughing. Scaling it downwards is bad enough, but scaling it upwards is just... so... ridiculous. It's not any exaggeration whatsoever to describe it as absurd. Mac fanatics will say it's hilarious. It's even worse than I said because the 1240 x 1240 PNG file isn't the only one. It's one of multiple upscaled image files. It also scales up the 300x300 source image to produce PNG files of sizes 310x310, 310x150, 620x620, 620x300, 600x600, and 1240x600. It's still even worse than I said. The default setting also includes scaling up the 300x300 image to produce a 2480 x 1200 splashscreen that also consumes roughly 1 megabyte on average. And a 1240 x 600 splashscreen. Wait, there's one more: It also scales upwards to a 620 x 300 splashscreen. I do realize that the "Scale 400" image files are supposed to correspond with the setting in Start menu / Settings / Display / "Scale and layout", but this reasoning is completely illogical. It makes no sense whatsoever. 400% doesn't even exist in the ComboBox in "Scale and layout", and even if 400% did exist there, it would still be completely illogical to pre-generate upscaled PNG files. The behavior of "Visual Assets" is just beyond belief. It's very unusual for Microsoft to publish something of very low quality, but this time it happened unfortunately. "Visual Assets" is extraordinarily low quality software. |
|
Instead of fixing all the resolution problems in @verelpode 's posts on visual assets directly, you could just obviate them by making a large simplification.
|
|
@charlesroddie -- I believe you've described an excellent solution that fits the needs: A modern design with a good balance between power and simplicity. Surely nobody will be able to think of a better plan than what you said. For comparison purposes, Android supports SVG icons, although the SVG must be converted first (AFAIK). Android has a GUI-based tool that converts the source SVG file to Android's own vector format called VectorDrawable. I think the following items belong in the list of top 10 reasons why Android won the battle between Android versus WinRT/UWP:
This is a good opportunity for Microsoft to change some things in order to attract more developers to UWP. |
|
@verelpode I think it would be more productive to not write these things in a "rant" kind of manner. But I fully agree with the IconSource and Path issues you pointed out, and also the flaws of the assets area. I ran into many of these problems myself. But you miss some things about assets:
I'd recommend you to create three separate, real proposals, one for the IconSourceElement issues, one for Path issues and one for assets area (that one is not really WinUI related, still it should appear here to create awareness). And I think you should try to just write down things neutrally, without making it a rant. Let's just say that there is still some room for improvement in these areas :) |
|
16x16 icons are far from obsolete. Small icons are required for list views like in Windows Explorer detail or list modes. They are used for status icons and titlebar icons, favicons, etc. They have a valid use case and a good app considers all the use cases and adapts their UI accordingly. You can certainly scale a bigger icon into a title bar, but then you are breaking the UX by wasting space in a Window Frame rather than giving that space to the Content. This could be summed up as adaptable vs scaling UIs. Adaptable makes sure the icon works best for the placement, position, readability, etc. that is needed for it's use case. Scaling ensures its readable across different DPIs and form factors. |
|
Any x*x icons are obsolete since Windows Vista which introduced good support for dpi. Since scaling in windows can be anything, you would need to support every possible integer x of you do it that way. @verelpode is being constructive with detailed analysis. If you want images to vary by size and be sharp then two or three svgs should be used for the same icon. |
Although I view 16x16 as obsolete, and although I view @lukasf's varying line thicknesses as overkill, nevertheless I would be willing to support a modified version of @charlesroddie's suggestion that supports those abilities, as follows. A single icon would consist of a list of images. Each image in the list can be either SVG or PNG. Thus a single icon consists of zero or more SVG images and zero or more PNG images. The size of each PNG in the source image list should be determined by the app developer's own preferences (not by Visual Studio). For example, an app developer would be able to configure a single icon to consist of these 4 source images:
I believe @lukasf, @mdtauk, and @dragonwolf83 should be happy now because the suggested plan includes support for what they want. Visual Studio shouldn't stop you from supplying a non-standard size. For example, if you want to display wide 48x32 icons inside your app, then Visual Studio shouldn't stop you from supplying a 48x32 PNG image. The sizes of the supplied source images should be your own choice. When an icon is rendered at runtime, obviously it should inspect the list of images in the icon, and select whichever one is the best/closest match for the destination rectangle and resolution.
Good point. I had already thought about multiple PNG images in the same icon, but I didn't realize that multiple SVG images in the same icon could be used to support varying line thicknesses, font sizes, borders. Note this idea of multiple SVG images only succeeds if each SVG image can be marked with a width and height, but SVG already supports this, IIRC. Even if I've remembered incorrectly and SVG doesn't support storage of a width and height, it would be trivially easy to separately store a width and height with each SVG image in the icon. So the point is, yes, a single icon can consist of a list of images, and each image should be either SVG or PNG.
When scaling an image at runtime, some software still uses a very old and obsolete scaling algorithm that delivers poor image quality: The "Nearest Neighbor" algorithm. The use of this obsolete algorithm is a defect in those pieces of software. Those defective programs should be corrected to use the bicubic image scaling algorithm, which delivers much better image quality. Decades ago, CPU's had insufficient power to quickly perform bicubic at runtime, and GPU's didn't even exist, therefore the fast-but-bad "Nearest Neighbor" algorithm was the only choice at runtime, and bicubic could only be performed prior to runtime in separate program such as Photoshop. Nowadays every computer has a GPU, and every tablet and smartphone has integrated GPU-like abilities, thus bicubic should be performed at runtime. Furthermore, in order to further enhance speed, bicubic scaling can be performed once and then cached and reused (not repeated every time an icon is rendered), as I mentioned in a previous message re the implementation of the Windows "Start" menu. Thus software that still uses "Nearest Neighbor" is incorrectly written and needs to be fixed to use bicubic. |
|
"Nearest Neighbor" is a good option if dealing with pixel art and defined scaling ratios. I think it could be useful to sum up what your request is, as opposed to a long and detailed explanation of what is broken. Based on looking through the posts, I think you have a number of asks that are all related in some ways.
|
Yes, you're right, but why should I work for a wealthy corporation (such as Microsoft) for free? It would be wildly unreasonable to expect me to work as if I'm a Microsoft employee, in return for $0 of salary for my hard work. To be ethical and fair, software engineers need to be paid a reasonable salary in return for their long hours of hard work. Ethical and legal working conditions. Also, I'm not a pseudo-religious open source fanatic who works two jobs simultaneously; a so-called "day job" plus a so-called "night job". An unpaid "night job" that is quasi-illegal in regards to max allowed/legal working hours per week. Open source isn't bad, but open source fanaticism is very bad -- it causes much harm to society and to companies as well. Thus you and @lukasf are correct in saying that properly-written proposals would be better, but I am not going to do that work because it would make me feel as if I'm being unethically exploited/abused. |
|
I believe that it would have been less work to write 2 or 3 compact, focused proposals for the improvements that would be most valueable for you, compared to the very lengthy and overly detailed write down of everything that is wrong. It's up to you to decide how much time you spend here. Microsoft won't pay you for creating issues here, obviously. Remember that creating an issue is usually only a tiny fraction of work, compared to the work required to actually resolve one of these issues. |
|
Since it seems like @verelpode won't write a proposal, I would like to step in and do this since it would be hard for the WinUI team and the community to come up with feasible solutions solely from this discussion. However I am not quite familiar with all the obstacles that are combined with using custom icons in UWP and WinUI, thus I will base it on the list @mdtauk kindly created in this issue There seem to be two large areas where there should be improvement: Using icons in app
App/tile icon
Are there any points missing @mdtauk , @charlesroddie, @verelpode , @lukasf, @moshegutman, @dragonwolf83 ? @verelpode Mind expanding on the open source "fanaticism" ? 😅 |
Impossible. If someone doesn't understand the problems, then he/she cannot write proposals to solve those problems. NOW, today, we've eventually reached a stage where it's possible to write proposals. Previously it wasn't possible to write proposals because there was little or no understanding of what was wrong. How could I be expected to write a proposal when I didn't understand what was wrong and hadn't discussed the problems with anybody? Even if I thought I knew the problems, my understanding could be proven inaccurate after discussing it with people, thus it was necessary to have discussion first. Thus the first stage is to determine what is wrong and discuss it, and the second stage is to use this knowledge of what is wrong, in order to write a proposal.
I've already done more than a generous amount of work for free in this and other issues. If I do more work for free, then I'll receive valid criticism from my colleagues and from customers/clients, for failing to prioritize the tasks necessary for our business and for our customers. We've already solved our icon problems by NOT using any of WinUI's icon stuff. A client could legitimately criticize my task prioritization by saying to me: "Why on earth are you spending so much time on icons when scalable and bitmap icons already work wonderfully in the app, whereas we urgently need the other issue XYZ fixed ASAP please?"
If you mean the proposal is a small part of the work, then my experience has been the opposite. It takes me a month or two to write a solid proposal, and then when the proposal is finished, I can hammer out the source code within 1 week, and then fix any bugs in the following week. |
WinUI is not open source therefore open source fanaticism cannot occur in WinUI. This could potentially change when WinUI becomes open source with the release of WinUI 3 sometime this year, if the WinUI team is not careful to prevent the problem, but I believe the WinUI team will monitor and prevent the problem. Some open source programmers are fanatical and sacrifice their own lives and work hundreds of hours for free instead of negotiating a reasonable normal employment arrangement with fair and ethical remuneration. Their bizarre fanatical behavior is inexplicable and harmful to themselves and to Microsoft and to the software industry in general. But no, I don't think it happens in WinUI.
Perhaps your form of a proposal is much less work than my form of a proposal. I have to maintain a reasonable limit on the amount of work I do for free for any wealthy corporations, and I have to ensure that our customers/clients don't suffer as a result of me spending excessive time writing messages or proposals in GitHub. |
|
@verelpode A WinUI 3.0 proposal would be a short list of wants, reasons why they are being asked for, and possibly some kind of visual mock up if that is relevant. The time you spent "ranting" about the problems with how icons are treated in the framework, could have gone into a more approachable ask. Of course there are Proposals, Bug Reports, Discussions, and other types of conversation on here. There are requests buried within the criticisms. And if you would like action to be taken on those wants, then wrapping them in a vitriolic negative tone, will make it easier to ignore them. And there are valid issues there, that should be reconsidered with WinUI 3.0's release, and Windows 10 X's new Shell |
I think you've misinterpreted the title of this issue. The title "An Iconic Disaster" is a play on words; a light joke. The light-hearted nature of this title becomes clear when reading the first sentence of this issue, where I gave a large compliment to the WinUI team: "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." I have no vitriolic feelings in regards to icons in WinUI. I think the vitriol is the product of what you imagine my feelings are. If you heard me speaking verbally instead of in writing, you wouldn't have viewed it as vitriolic. This is a common problem when reading and writing -- it's easy for people to make the mistake of reading something and interpreting it as having a different tone/emotion than the writer had, because the verbal tone of voice is absent from writing. Does the WinUI team consist of adults or teenagers? It consists of mature adults. Therefore these mature adults can take the good with the bad. I gave the WinUI team a big compliment, therefore if they accept the compliment then it's fair to also accept the criticism alongside the compliment. If they were immature, then they would only be able to handle positive news, but they're not immature. I respect the WinUI team by giving them both compliments and criticism because I view them as mature adults who can handle it. In contrast, you appear to be showing disrespect for the WinUI team because you're treating them as if they're immature teenagers who lack the mental maturity necessary to take the good with the bad. How you treat the WinUI team is your own choice, but if you ask me, my recommendation would be that you start showing them some respect by treating them as mature adults instead of teenagers. So-called "polite" wording is sometimes highly disrespectful to people.
Apparently your proposal method is different than mine, and neither method is better, rather both methods have pro's and con's. You say "a short list of wants" and that is clearly a method that has advantages but it also has disadvantages. You can use the proposal method that you feel works better for you, and I can use the proposal method that I feel works better for me.
Impossible. If someone doesn't understand the problems, then he/she cannot write proposals to solve those problems. NOW, today, we've eventually reached a stage where it's possible to write proposals. Previously it wasn't possible to write proposals because there was little or no understanding of what was wrong. How could I be expected to write a proposal when I didn't understand what was wrong and hadn't discussed the problems with anybody? Even if I thought I knew the problems, my understanding could be proven inaccurate after discussing it with people, thus it was necessary to have discussion first. Thus the first stage is to determine what is wrong and discuss it, and the second stage is to use this knowledge of what is wrong, in order to write a proposal.
You speak as if your preferred communication method is proven successful when in reality the opposite has already occurred. WinRT was released 8 years ago (2012). If your method is a successful method, then all the problems in UWP, WinRT, WinUI would have already been communicated easily and successfully YEARS AGO. You're trying really hard to convince me to switch to a failed method; a communications method that has been unsuccessful for the last 8 years. Why do you care so much about which method I use? Is it because you're trying to convince yourself by convincing me first? This happens commonly. People commonly try to suppress their own self-doubt by trying very hard to convince other people to do the same unsuccessful thing. Thus people convince themselves by trying to convince other people. The end result is that a whole group of people start repeating the same mistakes as each other, because a few self-doubting people try very hard to convince the other people to repeat the same mistake in order to erase their own self-doubt. It's one of the most common problems in society. |
|
Realized my comment on TabView relates to this discussion as well. |
|
I definitely feel like it'd be useful to split this into multiple scoped issues. There's a lot of great problems pointed out here, but I feel like this is hard to act on as an all-up sink. I just realized that I can't style an Icon/IconSource, when I get the |
|
@verelpode: Just by chance I discovered that a negative margin enables scaling to some extend. See you're code snippet below with this "hack"... |
|
I noticed that when I'm binding to a I'm using version The ViewModel: The View: I tried removing the negative margin, but to no effect. When I set the property
I don't know if I'm at the right place here. |
|
🦙 @brechtb86 probably best as a new issue, especially as it related to WinUI 3, I moved it over for you here: #4074 |
|
🦙 Linking to an older Stack Overflow thread about this same type of issue for reference: https://stackoverflow.com/questions/50458126/how-to-set-appbarbutton-icon-using-svg-file-resource-in-uwp-c |
|
More than 3 years later this is still the status quo? |
Actually, that's a negative. MDL2 and Fluent Font are called font icons and they are literally that: .ttf fonts |
|
I just started with WinUI3 recently and I can't believe it isn't easy to load an SVG image anywhere you can load a PNG. I can do it in WinForms with DevExpress controls, for example. These elements need to scale nicely depending on DPI, why is there little-to-no support for SVGs in things like NavigationViewItems after all this time? |
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.BitmapImagethat was produced from a PNG, and you want to use this PNGBitmapImageas an icon. This should be super simple, right? But no, unfortunately neitherWindows.UI.Xaml.Controls.BitmapIconSourcenorWindows.UI.Xaml.Controls.BitmapIconsupport the ability to render a specified instance ofBitmapImage-- surprising but true.To use your
BitmapImageinstance as an icon, you are forced to useWindows.UI.Xaml.Controls.Imageto render it becauseBitmapIconSourcecannot. This means that, in combination with the other problems I will describe,Windows.UI.Xaml.Controls.IconSourceElementis 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
BitmapIconSourceandBitmapIconsuggest 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 setBitmapIconSource.UriSourceto the URI of an SVG instead of a bitmap. Unfortunately anIconSourcesubclass namedImageIconSourcedoes 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:
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,SymbolIconSourceandSymbolIcondon't scale, and don't provide any way to manually configure the size of the icon, and don't have aFontSizeproperty either. (AFontSizeproperty wouldn't be the right solution but anyway it doesn't exist.)Following is an awkward inconvenient inefficient workaround that uses a
Viewboxelement to hack the icon into scaling. An alternative workaround is to viewSymbolIconSourceas unusable, and stop using it entirely, and instead use aTextBlockelement and set itsTextBlock.FontSizeproperty.How
IconSourceElementwithSymbolIconSourceshould behave: The same asBitmapIconSourceandWindows.UI.Xaml.Controls.Image-- both of those scale the icon/image whereasSymbolIconSourcedoes not -- a strange inconsistency. The icon should be scaled in the same manner as anWindows.UI.Xaml.Controls.Imageelement does with its default setting ofStretch="Uniform", or the same as aWindows.UI.Xaml.Shapes.Pathelement withStretchset toUniform.FontIconSource and FontIcon are also broken
FontIconSourceandFontIconare slightly less broken thanSymbolIconSourcebecause they have aFontSizeproperty. Actually aFontSizeproperty 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 thatSymbolIconSourceprovides.The idea of applying a
FontSizeto 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,
SymbolIconSourceandFontIconSourceshould scale the icon in the same manner asBitmapIconSourcedoes.SymbolIconSourcehandles white space better thanFontIconSource. For example, have a look at how thisSymbolIconSourcesnippet renders:The above rendering makes sense. The
Borderencloses the icon without padding. Now compare it with the failure ofFontIconSourceandFontIcon:As you can see above,
FontIconSourceandFontIconrender 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 byFontIconSource. 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
IconSourceElementinstances, such as 10 different buttons (in a row) with icons, and some of thoseIconSourceElementinstances useSymbolIconSourceand some useFontIconSourceand some usePathIconSource, then the 10 buttons look strange and inconsistent with each other because some have extra whitespace/padding (those that useFontIconSource) while the others don't.FontIconSourceandFontIconare not any better than using aTextBlockelement. They render the same asTextBlock. This rendering behavior makes no sense because they are supposed to render as icons not text.If you use
TextBlockinstead ofFontIcon, you might try to use theOpticalMarginAlignmentproperty to eliminate the problematic whitespace/padding, but it doesn't work, as you can see following. The first image (left) is withOpticalMarginAlignment="None"and the second image (right) is withOpticalMarginAlignment="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 inOpticalMarginAlignment.In WPF, one way of rendering a glyph/character as an icon (without whitespace/padding) is to do this:
System.Windows.Media.FormattedText.BuildGeometryorSystem.Windows.Media.GlyphRun.BuildGeometryto convert the glyph/character to aGeometryinstance.System.Windows.Shapes.Pathand set thePath.Dataproperty to theGeometryreturned byBuildGeometry.Path.Stretchproperty toUniform.Sadly, this technique cannot be used in WinUI because an equivalent of
FormattedText.BuildGeometrydoes 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.PathGeometrythat 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 useWindows.UI.Xaml.Controls.PathIconSourceorWindows.UI.Xaml.Controls.PathIconand give it whateverPathGeometryinstance you want? But no, unfortunately this fails to render. Surprising but true.Following you can see the success of
Windows.UI.Xaml.Shapes.Pathversus the failure ofWindows.UI.Xaml.Controls.PathIconSource(orPathIcon), when rendering the samePathGeometry(a house symbol). The first image (left) is thePathelement -- it works. The second image (right) isPathIconSource-- a failed (truncated) rendering of an icon.The
Pathelement succeeds because I set itsStretchproperty toUniform, but this solution does not work forPathIconSourcenorPathIcon-- they have noStretchproperty. ThusPathIconSourceandPathIconare unusable and you're forced to use thePathelement instead, which means thatIconSourceElementis a nice idea but so badly broken that it's practically unusable currently.The fact that
PathIconSourceandPathIcondon't scale the icon is especially strange when you consider thatBitmapIconSourcedoes scale the icon.A second reason why
PathIconSourceandPathIconare 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 thePathelement also suffers from the same failure, but it only fails in WinUI, not in WPF. In WPF, you can "freeze" aGeometryinstance 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
PathGeometryinstance represents a stroked figure instead of a filled figure, such as a "+" symbol consisting of a horizontal stroked lines over a vertical stroked line, thenPathIconSourcedoes not support yourPathGeometry. 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 ofPathIconSource). This should be super simple to do because WinUI already supports the excellentResourceDictionaryfeature. 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:
Actually, to be precise, in WPF, it's recommended to optimize the above by simply replacing
PathGeometrywith the optimized read-only equivalent ofPathGeometrythat is namedStreamGeometry. Easily done:So that works great in WPF, but
StreamGeometryis 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: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
PathGeometrybug is easy to fix because the WinUI XAML compiler already compiles the following successfully, therefore most of the work is already done forPathGeometry.Although
PathinResourceDictionarycompiles successfully, you should usePathGeometrynotPath.Pathis derived fromWindows.UI.Xaml.FrameworkElementandWindows.UI.Xaml.UIElement, and eachFrameworkElementinstance is permitted to have only one parentFrameworkElementinstance, and this won't change. Thus you cannot (and should not) try to share the samePathinstance among multiple different buttons in your app where the same icon needs to be used in multiple places.Unlike the
Pathelement,PathGeometryand/orStreamGeometryare 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 samePathGeometryorPathIconSourceinstance in multiple places, even despite the fact that the documentation says that sharing is supported:Notice how the documentation says "because it is not a FrameworkElement". This is the same reason why the
ResourceDictionaryshould containPathGeometrynotPath.Pathderives fromFrameworkElementwhereasPathGeometrydoes 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.
SymbolIconSourceis an excellent feature (thanks!) but obviously it's unreasonable to limit apps to using only the predefined icons/symbols in theWindows.UI.Xaml.Controls.Symbolenumeration.Classes were not updated for IconSource
When the
IconSourceElementandIconSourceclasses was created in WinUI in order to replace the defectiveIconElementsubclasses, unfortunately various other classes were not updated accordingly. They should have been updated at the same time as whenIconSourcewas released. For example, in order to updateMenuFlyoutItem, this needed to be done:MenuFlyoutItemnamedIconSourceof typeIconSource.MenuFlyoutItem.Iconas obsolete by applyingSystem.ObsoleteAttribute. (This old property usesWindows.UI.Xaml.Controls.IconElement.)The following have not yet been updated:
Windows.UI.Xaml.Controls.AppBarButton.IconWindows.UI.Xaml.Controls.AppBarToggleButton.IconWindows.UI.Xaml.Controls.MenuFlyoutItem.IconWindows.UI.Xaml.Controls.MenuFlyoutSubItem.IconWindows.UI.Xaml.Controls.NavigationViewItem.IconWindows.UI.Xaml.Controls.Primitives.NavigationViewItemPresenter.IconWindows.UI.Xaml.Controls.SettingsFlyout.IconSource(usesImageSourcenotIconSource)Already up-to-date:
Windows.UI.Xaml.Controls.SwipeItem.IconSourceWindows.UI.Xaml.Input.XamlUICommand.IconSourceAlthough the subclasses of
IconSourcecurrently render in a broken manner, this will be fixed andIconSourceis still a good idea, thus the various other classes need to be updated to supportIconSourceinstead of the oldIconElementsubclasses.Conclusion: They're all broken!
Windows.UI.Xaml.Controls.IconSourceElementis a nice idea and its concept makes good sense, but unfortunately all subclasses ofIconSourceare currently broken:BitmapIconSourceSymbolIconSourceFontIconSourcePathIconSourceFixing 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!
The text was updated successfully, but these errors were encountered: