Use libsfdo-based symbolic/scalable/SVG icon lookup
This PR introduces native Freedesktop Icon Theme support in Mako by leveraging libsfdo for scalable (.svg) and high-DPI icons. Previously, Mako only searched for bitmap icons under hard-coded icon-path directories. Now, users can specify one or more icon themes (e.g. Adwaita:Tela-green-dark) in their configuration, and Mako will:
- First attempt to resolve the notification’s icon_path through libsfdo using the configured theme names.
- Then, if no icon is found via libsfdo, fall back to the existing icon-path lookup logic (unchanged).
Changes:
- New icon-theme config key Accepts a colon-separated list of Freedesktop icon theme names. Example:
icon-theme = Adwaita:Tela-green-dark
icon-path = /usr/share/icons/Papirus # fall back
max-icon-size = 48
-
libsfdo integration Create and configure an sfdo_icon_lookup context using the user’s icon-theme list. Set desired icon size, output scale, and fallback theme (hicolor) via libsfdo. Call sfdo_icon_theme_lookup() to fetch scalable and SVG icons.
-
Fallback behavior If icon-theme is unset or libsfdo lookup fails, Mako reverts to its original icon-path + glob() search logic without any changes.
-
No breaking changes for users who don’t set icon-theme; existing behavior is preserved.
Testing:
- Verified that SVG and high-DPI icons are correctly resolved when icon-theme is set.
- Confirmed that bitmap (.png, .xpm) icons in icon-path still load when no matching theme icon exists.
- Manual tests across Wayland outputs with scale factors 1 and 2.
Closes #555 CC: @arebaka
Need to install the libsfdo library on the build server to pass the auto checks :)
Thanks for the patch! Instead of maintaining two codepaths, could we get rid of the old one? Or are there some lookups we can't support with the new one?
Need to install the libsfdo library on the build server to pass the auto checks :)
This can be done by adding new packages to .builds/*.yml.
New icon-theme config key
Seems like this is a separate, new feature - could you split it in a separate commit, or leave it for a future PR?
Also, it seems like this PR description is (partly?) AI-generated. Is that true? If so, I'd strongly recommend to not use AI, it adds a lot of noise and is cumbersome to decipher.
New icon-theme config key
Seems like this is a separate, new feature - could you split it in a separate commit, or leave it for a future PR?
The issue is that libsfdo uses the theme name rather than the path when looking up for icons. Because of this detail, it wasn't possible to rely on the existing option and simultaneously remove the legacy logic. We need your input on how to proceed if we're planning to switch to the new approach.
Also, it seems like this PR description is (partly?) AI-generated. Is that true? If so, I'd strongly recommend to not use AI, it adds a lot of noise and is cumbersome to decipher.
Yes, I use AI for writing documentation and other human-readable parts of my work, as well as for generating tests - otherwise, my descriptions would be too brief and uninformative. I'm good at coding, but not so good at communicating with people. :(
@emersion review and help with the FreeBSD build so I can update the docs and resolve #581.
@emersion?