feat: windows app icon

[Klemen2]

Closes: #3648
Implement #3596 for windows

Windows app resources will only be build with --release flag, otherwise it will be embedded (no app icon (thumbnail) or metadata when installed)

This pr also reduces the binary size since including icon is now deduplicated.

Added functions: default_icon, icon_from_memory, icon_from_path

Tested only on windows 11

[photino]

Why didn't previous versions support Windows app icons?

[Klemen2]

windows is windows and always needs something special, aka building a resource file with a specific program

[Klemen2]

In the docs somewhere there should be a notice that windows is very bad at updating app icons of installed apps, so if you bundle the app, install it, change the icon and bundle again and reinstall - it will look buggy with old icon in some places and new one on other, with the only fix being restarting the pc or at least restarting the explorer didn't seem to fix it on my machine

[pythoneer]

Anything left i can help with to bring this over the finish line? 0.7 is is nearing its release and i would love to not use a workaround for my current releases with 0.6 to have app icons.

[Klemen2]

Anything left i can help with to bring this over the finish line? 0.7 is is nearing its release and i would love to not use a workaround for my current releases with 0.6 to have app icons.

There are a few changes that needs to be done.

• 1. testing bundling apps for windows on mac/linux
• 2. It should probably not fail to build for windows if you do not have the tooling, it should only fail for bundling and release builds this requires changing how default icon is handled on windows (embedded with include_bytes instead of loaded from_resource) and if that's the case notify the user that there will be no icon for the app
• 3. Make it work with workspaces, since currently it doesn't compile unless you cd to the app crate itself (e.g will not work with 👩‍🏫 Add support for default-members #4811) - there should probably be a test for this so you see that it fails
• 4. I noticed that the logs "Compiling Windows resource file with ..." gets outputted twice, it should just be once
• 5. default icon handling for other platforms (related to 2. but ideally it would get it from the app itself and fallback to include_bytes for non release/bundle) -- not required for this PR, but would be nice for consistency
• 6. caching the windows resource file so it only compiles when the associated files changes -- not required for this PR

I think this is everything unless @jkelleyrtp has anything to add, feel free to work on this

[Klemen2]

microsoft has since added windows-resource to crates, but before they release anything it will be another half a year or more or it may not even be related to the resource compiler based on their sense of naming things

[Klemen2]

I think that this is pretty much finished now. From the comment above 1. is probably out of scope but should work if you have the tools setup correctly,
4. is not a big issue and I don't really know why is happening
6. would be nice to have, but not really important

[pythoneer]

I think the work here is relevant #4958 idk.

[pythoneer]

This PR #5072 worked on the same code location and created a conflict.

[jkelleyrtp]

Sorry this has sat so long. I'm just not a fan of the winres approach.

Deno built a crate called sui which can embed resources into binaries after they've been built.

https://littledivy.com/sui.html
https://github.com/denoland/sui

It specifically handles embedding icons into PE (windows exe files).

I would prefer we use sui to embed the icon for windows instead of the build.rs / winres system.

Alternatively, we could perform the compilation of the icon in the CLI and then pass it in as a linker arg.

https://claude.ai/share/b0f8e502-2932-4734-b4b0-da1241a262c1

I just don't want icon configuration to be done from within the build.rs. The dioxus.toml should be the source of truth for these configuration options and dx should perform the linker flag modifications if needed.

// ❌
println!("cargo:rustc-env=DIOXUS_APP_ICON=./assets/default_icon.png")

I might also just be misunderstanding the PR. It seems that the inlined winres system has code for printing link statements and reading the cargo_manifest_dir, which I don't think is applicable here

https://github.com/klemen2/dioxus/blob/2322b03a74b1b13e53327d803cd20ea0255b3091/packages/cli/src/build/winres.rs#L782-L786

[Klemen2]

winres was already doing compilation of the icon in the cli and was not using any cargo / build script since the first working version of this PR - basically what cloud suggested, the original was based on the tauri winres but this version is without embed_resource since it prints to the console, the tooling finder is from the script that zed is using winresource, I removed a bunch of irrelevant comments and unused stuff and also changed the structure a little

I haven't tested the gnu toolkit or on other platforms, only mscv on windows only

println!("cargo:rustc-env=DIOXUS_APP_ICON=./assets/default_icon.png") was done so that #3596 could be closed - now it's only implemented for windows, there is probably a better way of doing that on other platforms instead of embedding the icon in the exe but sui could be used for quick implementation, but I would need to look into it how and where it can be implemented

[pythoneer]

relevant PR #5328

[pythoneer]

I think #5412 and #5328 caused conflicts again. Not sure how this affects this PR :(

[jkelleyrtp]

Would love to merge this. What's the current state?

After digging into windows bundling recently, I have several thoughts:

• dx bundle shells out to wix / nsi which have options to include icons. For many users this could just be enough? You don't get icons during dev, but you do in bundle, which is really what matters.
• There is a crate called sui which lets you inject icons and files into binaries after they've been built (https://github.com/denoland/sui). This might be pretty simple.
• We can just add the icon via the linker - ie dx runs cargo rustc -- -C link-arg=app.res automatically. I think that's what's happening in this PR?

It seems that on many platforms we need some sort of pre-processing step for icon generation (android as well, and mac/ios). This adds extra overhead in dev (slower dev-server starts until we properly parallelize things), which is why we've deferred it to bundle.

I'm happy to add this step in dev too if folks think it's important.

[Klemen2]

As far as I know, wix / nsi settings only add icon to the installer, not the actual app.
the pr is basically doing cargo rustc -- -C link-arg=app.res where res needs to be compiled with rc.exe (or equivalent) because windows is special.

I don't think that dev builds necessarily need an icon, so atm you just get a warning if it can't be compiled.

I think that I only need to update a couple of things which I can probably do this weekend.

[Klemen2]

I'd say this is ready, unless you want any changes in the windows scope.

[jkelleyrtp]

Thanks so much!

[adamgreg]

The addition of ApplicationConfig::name in this PR is very interesting! It looks like it's not really used yet, but is it intended as a way to override the application name in bundles, so it doesn't have to be a PascalCase version of the crate name? That would be really useful for my app.

Is anyone working on that? I couldn't find an open PR. I'd be willing to give it a try myself if that would be welcome.

[Klemen2]

right now it's only used for the windows product name (app -> right click -> properties -> details)
the app name is not yet affected but fell free to implement it

[adamgreg]

right now it's only used for the windows product name (app -> right click -> properties -> details) the app name is not yet affected but fell free to implement it

FYI I just raised #5533 for this