Allow setting icon colors

[lukelex]

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]

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]

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]

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]

Yes. THE icon, my dear sir.

[fwsmit]

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

[lukelex]

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]

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: https://github.com/dunst-project/dunst/pull/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]

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 https://github.com/dunst-project/dunst/pull/1081#issuecomment-1147134322 and https://github.com/dunst-project/dunst/pull/1081#issuecomment-1148386648. Would that do what you want?

[jfly]

@fwsmit, that seems fine to me! And I'm glad to see that https://github.com/dunst-project/dunst/pull/1081 seems to be moving along nicely =)

[fwsmit]

@fwsmit, that seems fine to me! And I'm glad to see that https://github.com/dunst-project/dunst/pull/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

[fwsmit]

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