awesomeWM / awesome

awesome window manager
https://awesomewm.org/
GNU General Public License v2.0
6.22k stars 595 forks source link

app_icon does not seem to work in notifications #3463

Open anihm136 opened 2 years ago

anihm136 commented 2 years ago

Output of awesome --version:

awesome v4.3-1210-gaedcd0c05 (Too long) • Compiled against Lua 5.3.6 (running with Lua 5.3) • API level: 4 • D-Bus support: yes • xcb-errors support: no • execinfo support: yes • xcb-randr version: 1.6 • LGI version: 0.9.2 • Transparency enabled: yes • Custom search paths: no

How to reproduce the issue:

  1. Send a notification that sets app_icon property. For example, naughty.notify{text='Example', app_icon='call-start'} or notify-send "Example" --icon="call-start"

Actual result:

No icon is set on the notification

Expected result:

Appropriate XDG icon should be set in the notification

Extra info I have verified that the name call-start is a valid XDG icon name, and is present in the theme I am using (Sardi). I have also added the path to the theme in naughty.config.icon_dirs. Also, other notifications from applications that are providing the image in the freedesktop hints are being displayed correctly.

anihm136 commented 2 years ago

I've been tinkering a bit and figured out a couple of things. Firstly, I missed the documentation where it mentions that I need to set the request::icon handler. I did that, and it worked for a few icons. However, the above example still fails. I did a little bit of digging, and I think I've figured out why this happens -

  1. The theme I have set as beautiful.icon_theme has icons in one additional level of nesting - /usr/share/icons/Sardi/scalable/apps/scalable. This is currently not explored by menubar.utils.lookup_icon, which is being used to resolve the path
  2. menubar.utils.lookup_icon only adds the apps and categories subdirectories if they exist, while call-start generally exists in the actions subdirectory. I don't know what the standard mentions (or if it mentions it at all), but this seems to be a fairly common subdirectory in themes
  3. Some themes may inherit a majority of icons from another theme, which is not handled. Of course, it feels out of scope for a window manager. However, the naughty.config.icon_dirs variable seems to be ignored currently, which I was trying to use to set the appropriate paths

For now it appears that I need to duplicate the logic in menubar.utils and add in the stuff I need

actionless commented 2 years ago

not sure if it's just related or a duplicate of this one:https://github.com/awesomeWM/awesome/issues/908

anihm136 commented 2 years ago

Might be related. To be honest, I did see that one, but did not understand the scope of it, so I opened a new issue. Feel free to close this if you feel it comes under the other one. For now, the workaround is that I have copied the lookup_icon function and modified it to manually inject the search paths from naughty.config.icon_dirs, which is working as expected

aarondill commented 1 week ago

I've noticed this same bug (due to notify-send), and this workaround seems to work for me:

naughty.config.notify_callback = function(n)
  n.icon = n.icon or n.app_icon
  return n
end

edit: sorry for the comment on a 3 year old bug report