Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using custom icons on Kando nodes #383

Closed
D3vil0p3r opened this issue Apr 13, 2024 · 21 comments · Fixed by #520
Closed

Using custom icons on Kando nodes #383

D3vil0p3r opened this issue Apr 13, 2024 · 21 comments · Fixed by #520
Labels
feature request New feature or request

Comments

@D3vil0p3r
Copy link
Contributor

Hello @Schneegans , I'm reading from docs that the user can mainly use as icon of a node only Google Material Symbols, Simple Icons or emojis.

Is there a way (now or in the future) to use also custom SVG icons stored in the system (as in FlyPie)?

@Schneegans
Copy link
Contributor

Hi there! This is not yet possible, but I'll definitely add this option in the future!

@Schneegans Schneegans added the feature request New feature or request label Apr 14, 2024
@D3vil0p3r
Copy link
Contributor Author

When it will be available, I start to implement it on Athena OS

@rairay91
Copy link

rairay91 commented Jun 4, 2024

I too want that option 🥳

@D3vil0p3r
Copy link
Contributor Author

@Schneegans is there a planned date for it?

@Schneegans
Copy link
Contributor

@D3vil0p3r It's definitely been frequently requested. So I think that I'll try to add this in 1.2.0. The next version (1.1.0) will come in a week or so bringing Keyboard Macro Items and App-dependent menus. Then I'll start implementing this, most likely together with custom themes. So maybe in a month or so?

@Schneegans
Copy link
Contributor

I was just wondering how to approach this. I basically have two options in mind:

  1. Add a new Icon Theme called "Custom Icons". This is empty at first but there will be "+" button which opens a file picker which you can use to add images to the theme. Somewhere in the settings we would need to store the paths to all the icons added this way.
  2. There could be a predefined directory in Kando's config directroy (e.g. kando/icon-themes) and any directory you put in there would show up as custom icon theme. Kando would automatically list all icon files in those directories in the icon picker.

Do you have other ideas? Having both approaches seems a bit overkill to me. I personally tend to the second approach as it seems more versatile, effective, and fosters sharing of icon themes. The first one may be a bit easier to understand, though. However, we could show a prominent hint in the icon picker telling the user where to put custom icons so that Kando will find them.

@D3vil0p3r
Copy link
Contributor Author

The option 1 is the same there is on FlyPie, right?

@Schneegans
Copy link
Contributor

Well, in Fly-Pie it's somewhat "worse" in the sense that there is no list of previously selected icons. You always have to use the file picker to select a custom icon. Even if you want to select the same icon multiple times.

@D3vil0p3r
Copy link
Contributor Author

Ah ok

@D3vil0p3r
Copy link
Contributor Author

D3vil0p3r commented Sep 7, 2024

Hey @Schneegans is there the chance to use also the icons stored in standard directories /usr/share/icons and ~/.local/share/icons so, if I have already a system icon theme, I prevent to copy duplicated files (and occupy disk space) on ~/.config/kando/icon-themes?

Furthermore, by default there are 4 icon themes already set to be chosen. I note that if I select one, for example "Emoji" and I set an icon, when I want to set another icon on another element, the selected icon theme returns to "Material Symbols Rounded" instead to keep my previous selection (in this example "Emoji"). Is it possible to keep the last icon theme/directory entry when you must set the next icon?

@Schneegans
Copy link
Contributor

Hey @Schneegans is there the chance to use also the icons stored in standard directories /usr/share/icons and ~/.local/share/icons so, if I have already a system icon theme, I prevent to copy duplicated files (and occupy disk space) on ~/.config/kando/icon-themes?

This is a very Linux-specific thing. I am not sure how to do this in a proper manner... Of course, we could make Kando obey the Freedesktop Icon Specification but this would be quite a lot of work. Simply loading all icons from the system icon directories would not be elegant as there are usually dozens of duplicated icons with various sizes in there. You can try copying all your icon themes to ~/.config/kando/icon-themes to see what I mean.

If that would be fine for you, a ln -s /usr/share/icons ~/.config/kando/icon-themes should do the trick without copying anything.

Furthermore, by default there are 4 icon themes already set to be chosen. I note that if I select one, for example "Emoji" and I set an icon, when I want to set another icon on another element, the selected icon theme returns to "Material Symbols Rounded" instead to keep my previous selection (in this example "Emoji"). Is it possible to keep the last icon theme/directory entry when you must set the next icon?

I see that this is a bit inconvenient when setting multiple icons. But when you open the icon picker, the currently selected icon is shown in the picker. If the previous theme would still be selected, the icon would change only when opening the icon picker which would not be ideal either... Or how do you expect this to behave?

@D3vil0p3r
Copy link
Contributor Author

My concern is about the packaging of some icon themes. In Athena OS I use different color themes and packaging in Linux can only place files in system folders, not in HOME folder. So if I install a icon colored theme by a package, I cannot install it directly in ~/.config/kando/icon-themes directory, so the user should copy them manually... that is not what the user expects to do

@Schneegans
Copy link
Contributor

Mhh... What if Kando would load icon themes also from /usr/lib/kando/resources/app/.webpack/renderer/assets/icon-themes/ (or where ever Kando is installed to) similar to how it loads menu themes currently?

@D3vil0p3r
Copy link
Contributor Author

Mhh... What if Kando would load icon themes also from /usr/lib/kando/resources/app/.webpack/renderer/assets/icon-themes/ (or where ever Kando is installed to) similar to how it loads menu themes currently?

It could be a good solution too.

@D3vil0p3r
Copy link
Contributor Author

D3vil0p3r commented Sep 7, 2024

@Schneegans I tried to use your suggestion about linking directories by ln -s but Kando settings does not see the linked folder. Can this be fixed?

Furthermore, is there no chance to specify directly the absolute path of the icon? It could solve my concern.

@Schneegans
Copy link
Contributor

@Schneegans I tried to use your suggestion about linking directories by ln -s but Kando settings does not see the linked folder. Can this be fixed?

If you link the entire icons directory (ln -s /usr/share/icons ~/.config/kando/icon-themes), it should work. Kando currently ignores symlinks inside the icon-themes directory. We could change that.

Furthermore, is there no chance to specify directly the absolute path of the icon? It could solve my concern.

In theory, this would be easy. The problem is the UI. If an icon is loaded from file, we would need some kind of file-picker so that the user can change the icon. This is currently difficult as the menu editor is shown as a full-screen, always-on-top window. So we need to wait for #468 for this.

@Schneegans
Copy link
Contributor

I created #614 and #615 accordingly.

@D3vil0p3r
Copy link
Contributor Author

Thanks for the last issue tickets. I think that allowing symlinks inside icon-theme directory could make kando more flexible. So I prevent to link all icon directories.

@D3vil0p3r
Copy link
Contributor Author

I created #614 and #615 accordingly.

Hey @Schneegans is there an ETA for them?

@Schneegans
Copy link
Contributor

My current focus is #468. #615 will only happen after #468, so this will take several weeks, I guess. However #614 should be pretty easy to implement. There are some other, rather low-effort issues, so maybe I'll publish another version before #468 is done.

But even this can take some time as I am currently very busy due to a paper deadline in "real life" 😅

@Schneegans
Copy link
Contributor

#614 is now done via #631. Feel free to test it in the current main branch!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants