feat(cli): add option to make custom icon sizes.

[khuongduy354]

What kind of change does this PR introduce?

• [ ] Bugfix
• [X] Feature
• [ ] Docs
• [ ] New Binding issue #___
• [ ] Code style update
• [ ] Refactor
• [ ] Build-related changes
• [ ] Other, please describe:

Does this PR introduce a breaking change?

• [ ] Yes, and the changes were approved in issue #___
• [X] No

Checklist

• [X] When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• [ ] A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• [X] I have added a convincing reason for adding this feature, if necessary

Other information

[khuongduy354]

Feature requested in this issue. Some keynotes:

• Only apply to .ico and .png
• Added --config to find json config file.
• If no --config provided, use default hardcoded values, as in previous version

[FabianLars]

I don't think there is any value in making it possible to generate custom .ico files. Just like the .icns file it's basically "complete" and there shouldn't be an actual use case requiring different layer sizes.

It's a good start btw! :)

i'll wait with the code nitpicking until it's more feature complete, but one thing already, you can use serde_json::from_reader instead of from_slice. It's a little cleaner and probablyyy faster.

[FabianLars]

Hello 👋 Sorry for the super long delay, it thought you weren't done and then forgot about it after some time :/

Do you still have interest in working on it or should we take it from here?

A few open points i see at first glance:

• It still supports ICO files. As said earlier i don't think this offers much value because the default ico is already "complete"
• There's still a todo for the file name, but that's imo not important because of my next point
• I don't really like the json approach anymore tbh. I think we should go with a more direct cli interaction. What i have in mind right now would be a cli argument that takes an array of sizes, for example tauri icon --extra 123,420,1337, which just reuses the existing png loop, including the default naming scheme. I think letting the users rename the files if needed is not too much to ask for.

[khuongduy354]

I was kinda tight on schedule at moment, but i think i can work on it this weekend, you can leave it to me.

Vào 22:04, T.5, 8 Th12, 2022 Fabian-Lars @.***> đã viết:

Hello 👋 Sorry for the super long delay, it thought you weren't done and then forgot about it after some time :/

Do you still have interest in working on it or should we take it from here?

A few open points i see at first glance:

• It still supports ICO files. As said earlier i don't think this offers much value because the default ico is already "complete"
• There's still a todo for the file name, but that's imo not important because of my next point
• I don't really like the json approach anymore tbh. I think we should go with a more direct cli interaction. What i have in mind right now would be a cli argument that takes an array of sizes, for example tauri icon --extra 123,420,1337, which just reuses the existing png loop, including the default naming scheme. I think letting the users rename the files if needed is not too much to ask for.

— Reply to this email directly, view it on GitHub https://github.com/tauri-apps/tauri/pull/5246#issuecomment-1342868838, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKBJSIICA7VXTKSALKQCZX3WMH2GNANCNFSM6AAAAAAQRDI434 . You are receiving this because you authored the thread.Message ID: @.***>

[khuongduy354]

I made some changes, can you have a look? @FabianLars . It remove json config, and --extra flags generate custom sizes .png with same naming scheme. Should the --extra generate additional besides default png sizes, or it should ignore default ones?

[FabianLars]

Should the --extra generate additional besides default png sizes, or it should ignore default ones?

In my opinion it should create additional files, and keep building the default at the same time.

[khuongduy354]

How is it? If you decide to take it, I'll cleanup the comments and test icon files. @FabianLars

[FabianLars]

Yeah i like that. Another thing we may wanna look into is de-duplication so that we don't end up generating the same icon twice - that can be added after the cleanup ofc.

[khuongduy354]

I don't really get making extra_icon_sizes as Option.

[khuongduy354]

I altered the icon sizes, as you said, it removes the dedup logic, looks better to me. Do u want it or switch back to the old commit ?

[FabianLars]

I don't really get making extra_icon_sizes as Option.

Doesn't really matter anymore. Without the dedup logic it would add more visual clutter than its worth.

One last thing: The 32 and 128 icon sizes are missing now.

[khuongduy354]

So it's done after switching back to prev commit ?

[FabianLars]

That would introduce the 256 / 512 naming problem from earlier. Honestly just do something like this again

for size in [32, 128].into_iter().chain(extra_icon_sizes) {}

and call it a day. We had so many iterations that i'm not sure anymore what i'd like to see at this point 😅

Thanks for following through btw!

[FabianLars]

Sorry that it was such a pain. I'm quite new to this PR reviewing stuff x)

Thank you again!

[khuongduy354]

Thx a bunch, Im a newbie and was busy recently, so i cant focus entirely on this, it such a pain. Anyways, thanks a lot for your guide

[lucasfernog]

LGTM, but maybe we should change it to only run the user-specified icon sizes? Like instead of running tauri icon --extra-png 24 48 to generate all Tauri icons + the extra ones, we could let the user run tauri icon --png 24 48 --output ./assets/img.

[FabianLars]

That was indeed the initial idea from the others, but i thought it feels a bit weird (idk why) so i asked to start with this approach first and wait for other opinions

[lucasfernog]

I've pushed that. We have time to get feedback and revert it if it feels weird :) we still need to audit the next release anyway.