Add all AppX assets from Microsoft spec

[mokagio]

Related to pesfPa-1cz-p2#comment-763. Builds on top of #643.

Proposed Changes

Add all icon the assets, whether required or recommended, for the AppX pakcage. See details at https://learn.microsoft.com/en-us/windows/apps/design/style/iconography/app-icon-construction

Assets kindly provided by @matt-west.

Notice I tracked the assets as binaries. However, I wonder whether we should use Git LFS instead.

Granted, the size on disk is negligible, less than 3 MB:

But Git is made for text, not binary. Every edit to one of these files will require the whole binary being tracked in the repo. Over time, the size impact might become noticeable. Besides, it just feels wrong.

Testing Instructions

Download the unsigned AppX from the Buildkite artifacts and install it on Windows. Then... verify there are icons, I guess?

Here are some screenshots from my VM. Unfortunately, the resolution is quite poor. But at least it shows that nothing is missing?

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors? – N.A.

[sejas]

Thanks for creating all the assets!

It feels a bit odd that we track all the sizes of what is essentially the same image, but we exclude four sizes in the .gitignore.

I wonder if, instead of creating those four images dynamically, we could track them in the repository.

I don’t have a strong opinion, though. You have more experience with this process.

[sejas]

Why not call those files directly by their final name, such as Wide310x150Logo.png, instead of WideTile.scale-100.png?
Is it because we need both files? Can we track them in the repository as we do with the rest of sizes?

[mokagio]

Thanks for creating all the assets!

All thanks to @matt-west. I just drag and dropped.

It feels a bit odd that we track all the sizes of what is essentially the same image, but we exclude four sizes in the .gitignore.

I wonder if, instead of creating those four images dynamically, we could track them in the repository.

I don’t have a strong opinion, though. You have more experience with this process.

This is the first time I run into a setup like this, so any input is welcome. (Input is always welcome, actually.)

The reason I decided to provide those assets by copying existing ones rather than simply tracking them in the file system is because their names are not in the standard list from the docs at https://learn.microsoft.com/en-us/windows/apps/design/style/iconography/app-icon-construction . The need to have those assets with those names comes from what is written in the XML manifest template in the library that packages the appx.

Recently, I have been excited about code generation. I might have been victim of the "shiny new toy syndrome".

The fact that it looks odd to you as an observer of the setup, is enough of a signal for me to revert. It was admittedly an inconsistency in the setup, and it doesn't surprise me it stood out to you.

There is one argument in favor of not tracking those assets because they are duplicated binaries that will unnecessarily bloat the repo, but I think it's weak given the little overhead when compared with the other tens of assets.

Besides, if repo size is something we really cared about (I don't think it's a problem at the moment, but correct me if I'm wrong) then we should apply the same dynamic generation strategy to all assets that has the same content but different names. We could even track a single assets, the largest required one, and generate all variants at packaging time. But I don't think that's a need at the moment.

[mokagio]

There is one argument in favor of not tracking those assets because they are duplicated binaries that will unnecessarily bloat the repo, but I think it's weak given the little overhead when compared with the other tens of assets.

Actually @sejas I'd love you hear your thoughts in this regard and with the related idea of using Git LFS.

I wonder whether we should use Git LFS instead.

Granted, the size on disk is negligible, less than 3 MB:

But Git is made for text, not binary. Every edit to one of these files will require the whole binary being tracked in the repo. Over time, the size impact might become noticeable. Besides, it just feels wrong.

This is not a must for me. Just a nitpick. Totally fine to dismiss if we care more about keeping the setup lean (in the same way that it's simpler to track all assets even though some could be derived).

[sejas]

I love code generation too! ❤️ .

Besides, if repo size is something we really cared about (I don't think it's a problem at the moment, but correct me if I'm wrong) then we should apply the same dynamic generation strategy to all assets that has the same content but different names. We could even track a single assets, the largest required one, and generate all variants at packaging time. But I don't think that's a need at the moment.

The size of the repository is not a problem. I believe we can track all the image sizes, even if some are duplicated. We don’t need to use Git LFS for this purpose. I agree that having a single master image tracked and generating the other sizes automatically would be ideal. There is probably a library or tool that can handle this. However, since I don’t expect changing our app icon frequently or anytime soon, I don’t think it’s worth the effort to implement such a mechanism at the moment.