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

Allow setting icon colors #994

Open
lukelex opened this issue Dec 5, 2021 · 11 comments
Open

Allow setting icon colors #994

lukelex opened this issue Dec 5, 2021 · 11 comments
Labels

Comments

@lukelex
Copy link

lukelex commented Dec 5, 2021

I'm trying to use Font Awesome icons and they come in black, by default. Would be lovely to be able to set a custom color for them, either using a hint or at least globally.

@fwsmit
Copy link
Member

fwsmit commented Dec 5, 2021

You can set a color using markup inside the notification body or the notification format. For the syntax, take a look at https://docs.gtk.org/Pango/pango_markup.html
Unfortunately it's not possible to do markup in the summary, since it's not allowed in the notification spec.

Does this satisfy your use case?

@lukelex
Copy link
Author

lukelex commented Dec 6, 2021

I don't see how to define a markup, and hence the color, of the icon anywhere in the docs.

format doesn't seem to support modifying the icon.

@fwsmit
Copy link
Member

fwsmit commented Dec 6, 2021

Is it the icon? Then there's no way of coloring it AFAIK. If it's part of the text, however, it can be colored with markup

@lukelex
Copy link
Author

lukelex commented Dec 6, 2021

Yes. THE icon, my dear sir.

@fwsmit
Copy link
Member

fwsmit commented Dec 6, 2021

I was confused, because Font Awesome is a font and can presumably also be used as a font for your notifications. That could be a possible solution for you

@fwsmit fwsmit added the Feature label Dec 6, 2021
@lukelex
Copy link
Author

lukelex commented Dec 6, 2021

Yes. I could possibly use the FA icon as part of the body but at this point I might as well use another notification deamon that provides better layout flexibility. ¯\_(ツ)_/¯

Thanks anyways

jfly added a commit to jfly/snow that referenced this issue Aug 29, 2022
We've already got dunst, why have 2 daemons? Espcially when one of them
is so wildly unsupported.

Dunst unfortunately doesn't have baked in support for symbolic icons, so
it doesn't know how to color them (see
dunst-project/dunst#994), so the contrast on
this isn't great.
@jfly
Copy link

jfly commented Aug 29, 2022

For symbolic icons, gtk provides a load_symbolic function that can tweak the icon to match the given foreground, success, warning and error colors: https://docs.gtk.org/gtk3/method.IconInfo.load_symbolic.html. I could see that being a really useful feature for

However, it looks like dunst has worked pretty hard to avoid a dependency on gtk: #376, so adding it back feels counterproductive.

A few ideas:

  1. Just bite the bullet and add a dependency on gtk. Side benefit: I think this would allow us to delete a lot of the loading logic.
  2. Add an optional dependency on gtk just for recoloring symbolic icons.
  3. Or, it might be possible to port just the core "load symbolic" logic from gtk (I think this gtkicontheme.c file is the relevant bit) to dunst.

I could try putting together a PR if a maintainer would let me know which approach we prefer.

@fwsmit
Copy link
Member

fwsmit commented Sep 6, 2022

Adding a gtk dependency would indeed not be an option. I would go for option 4, which you didn't mention. And that is to do what's mentioned in #1081 (comment) and #1081 (comment). Would that do what you want?

@jfly
Copy link

jfly commented Feb 3, 2023

@fwsmit, that seems fine to me! And I'm glad to see that #1081 seems to be moving along nicely =)

@fwsmit
Copy link
Member

fwsmit commented Feb 3, 2023

@fwsmit, that seems fine to me! And I'm glad to see that #1081 seems to be moving along nicely =)

The author of that pr did say that they don't have much time to finish, so we are looking for someone else to finish it. The last 2 comments on that pr say what still needs to be done

@lukelex lukelex closed this as not planned Won't fix, can't repro, duplicate, stale May 23, 2023
@fwsmit fwsmit reopened this May 24, 2023
@fwsmit
Copy link
Member

fwsmit commented May 24, 2023

This issue shouldn't be closed. There is a solution proposed, but it's just not finished. If anyone wants to help, they're welcome

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

No branches or pull requests

3 participants