tauri icon indicating copy to clipboard operation
tauri copied to clipboard

[Feat] tauricon: Allow for additional custom generated icon files.

Open phisch opened this issue 3 years ago • 14 comments

I have the use-case where I serve my front-end as a tauri app and also as a web-app with PWA support. Instead of maintaining two sets of icons, I would like to just generate one set that is used by everything. This is probably a pretty common use-case.

So it would be nice to have a way to define alternative icon formats, sizes and file-names, that are also generated by tauricon.

Currently, the files to be generated are defined here: https://github.com/tauri-apps/tauricon/blob/dev/src/helpers/tauricon.config.ts

Probably the easiest implementation would be to keep that same structure and provide it via the cli as a json file:

npx @tauri-apps/tauricon icons/logo.svg --target icons --extra icons/extra.json

And then the icons/extra.json could be something like this:

[
  {
    "folder": "../frontend/src/assets/icons",
    "prefix": "icon-",
    "infix": true,
    "suffix": ".png",
    "sizes": [72, 96, 128, 144, 152, 192, 384, 512]
  }
]

What are your thoughts about that?

phisch avatar Jul 09 '22 22:07 phisch

Can I take this as a newbie? What i'm going to add in this file is:

  1. take path to extra.json as a cli argument
  2. import the json from path
  3. call another tauricon.make() with json as option parameter

khuongduy354 avatar Sep 17 '22 05:09 khuongduy354

We always appreciate contributions! The only problem here is that the tauricon (js) package was deprecated and we won't accept any PRs for it anymore (the repo will be archived soon too). As of tauri-cli v1.1 tauricon is now part of the main cli again - relevant file: https://github.com/tauri-apps/tauri/blob/dev/tooling/cli/src/icon.rs

FabianLars avatar Sep 17 '22 10:09 FabianLars

Btw idk how other people see it but i'm not too happy about the prefix/suffix json bloat. What do you guys think about an optional {} in the filename which would be replaced with sizexsize?

  {
    "folder": "../frontend/src/assets/icons",
    "name": "icon-{}.png", // would be icon-72x72.png for example.
    "sizes": [72, 96, 128, 144, 152, 192, 384, 512]
  }

FabianLars avatar Sep 17 '22 10:09 FabianLars

Btw idk how other people see it but i'm not too happy about the prefix/suffix json bloat. What do you guys think about an option {} in the filename which would be replaced with sizexsize?

  {
    "folder": "../frontend/src/assets/icons",
    "name": "icon-{}.png", // would be icon-72x72.png for example.
    "sizes": [72, 96, 128, 144, 152, 192, 384, 512]
  }

this looks cleaner & more straightforward to me.

khuongduy354 avatar Sep 17 '22 10:09 khuongduy354

One thing I think could be done is to have some smart defaults here that don't require a user to setup a custom json file. For instance, have filenames with mac-512.png, windows-512.png, linux-512.png, etc. could be a useful defaults (but a user could always give alternatives).

lorenzolewis avatar Sep 17 '22 14:09 lorenzolewis

Since this issue is in a deprecated repo. I want to clarify it a bit. The relevant file is here.

The goal is to allow custom configs for icons. Something like

yarn tauri icon target-icon.png --ouput icons --config icons/config.json

The configuration for generating icons is currently hardcoded. So, a json format is needed, as I was suggested above:

[
  {
    "folder": "../frontend/src/assets/icons",
    "name": "icon-{}.png", // would be icon-72x72.png for example.
    "sizes": [72, 96, 128, 144, 152, 192, 384, 512]
  }
]

And of course, there'll be default configs if user don't want to customize anything. Is everything all right?

khuongduy354 avatar Sep 18 '22 14:09 khuongduy354

As far as i am concerned, the current default output must stay unchanged and this json approach looks fine to me.

That said i didn't really understand Lorenzo's proposal tbh. Also i think there are no other defaults we could/should provide that we don't already have (or will have for new build targets).

Edit: One additional thing: i personally would like to keep it restricted to png for now, if this was in question.

FabianLars avatar Sep 18 '22 14:09 FabianLars

As far as i am concerned, the current default output must stay unchanged and this json approach looks fine to me.

That said i didn't really understand Lorenzo's proposal tbh. Also i think there are no other defaults we could/should provide that we don't already have (or will have for new build targets).

Edit: One additional thing: i personally would like to keep it restricted to png for now, if this was in question.

https://github.com/tauri-apps/tauricon/blob/dev/src/helpers/tauricon.config.ts
do you think the linux defaults above fit ?

khuongduy354 avatar Sep 18 '22 14:09 khuongduy354

Yes, otherwise i would've changed it when i ported it to rust :D

But we couldn't change it anyway, because it would be a weird breaking change, and at least the .deb bundle does use these files currently.

As i said, we can't change anything about tauri icons current output, except for the appx images since they are not used right now. But we decided to just keep them anyway 🤷

FabianLars avatar Sep 18 '22 14:09 FabianLars

I don't really get it about the default output, you mean the paths or the sizes? Why it can't be changed ? It's hardcoded in the code, can i move it to a json instead ? image Edit: Ok, i understand that it'll make a breaking change. So I just move them to json, and keep the number the same, it gonna be fine, right?

khuongduy354 avatar Sep 18 '22 14:09 khuongduy354

What i mean with the default output is the files it currently generates if you call tauri icon, both the size and file names (and the path logic i guess). We need it to generate these files like this no matter what.

It's hardcoded in the code, can i move it to a json instead ?

I'd prefer it in the code tbh, but if you can come up with something nice, i'm willing to reconsider.

FabianLars avatar Sep 18 '22 14:09 FabianLars

@FabianLars I tried using it with serde, it seems good, like the fn icns here. But there're things I'm not sure:

  1. there're 4 sizes covered in fn ico, but only 1 .ico is generated, is it a bug or is it made that way? image
  2. in fn png image Is @2x necessary? Can I make it to 256x256 instead, cuz it will fit the format you suggested easier.

Also, I want to ask a bit about workflow. Should I ask for help, or discuss in Discord or comment here? And how can I effectively share my prototype code for others to review without making a PR? I'm still a newbie, I'd appreciate it if you could guide me through this stage.

khuongduy354 avatar Sep 19 '22 13:09 khuongduy354

there're 4 sizes covered in fn ico, but only 1 .ico is generated, is it a bug or is it made that way?

This is how the .ico format works. These are just "layers" contained in a single file. Here again, all these sizes need to stay, and the order is important too (32 must be before 16 and 24 so it's the first layer)

Is @2x necessary?

Yes, because it's the 128px icon for high dpi mode. I'd recommend not really touching the current code for now and just slap your own stuff on top, we can refactor it later before merging.

Should I ask for help, or discuss in Discord or comment here?

Discord is preferred for live communication aka chatting. Otherwise the general approach (that i like) seems to be to first try to explore the basics of the topic in the issue, and then if you have some kind of PoC implementation, create a draft PR and move the discussion about specifics over there and only report back major things in the issue to not annoy issue subscribers 😅 But in the end it really doesn't matter too much, it's more about what you're comfortable with.

FabianLars avatar Sep 19 '22 13:09 FabianLars

Here is my first PR

khuongduy354 avatar Sep 20 '22 14:09 khuongduy354