feat: windows app icon + default icon from toml #3753
Conversation
Building with winres is now mandatory since app may build but fail to run due to how default icon for window is managed - fixed default bundle icon path fail for windows
… to the same file
|
Why didn't previous versions support Windows app icons? |
|
windows is windows and always needs something special, aka building a resource file with a specific program |
changed bundle_dir to build_dir
since the app icon is expected, winres should also be expected to avoid successful builds with the app not launching because of that
|
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 |
1. fix winres for workspaces 2. winres will only be created for --release flag
This reverts commit ff109fe.
added icon_from_memory and icon_from_path helper functions for setting icons
Klemen2
changed the title
|
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, |
|
I think the work here is relevant #4958 idk. |
This is a temporary fix until dx bundle is fixed. See: DioxusLabs/dioxus#3753 closes #8
|
This PR #5072 worked on the same code location and created a conflict. |
removed some cfg!(windows) for build.triple.operating_system canonicalize_icon_path now checks if the path is absolute or from workspace tauri bundler does not support AppList icon, it requires .ico
|
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 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 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 |
Added known Properties struct for better distinguishment between what windows will display and what it may not Remove comments and functions that do not apply to this modified version WindowsResource struct now only contains resource and not paths Now it actually matches the target and not the cli build host
other platforms do not have default icon now
|
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
|
default_icon is not implemented on all platforms, remove not used cli const
5 participants
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