SUMMARY I don't think there's anyone who hasn't come across .desktop files with no icon set, caused by absolute paths not being found. The idea is to allow icon themes to override. Suggestion: in icon search process, convert absolute paths into relative paths by replacing slashes with some non directory related. Eg: /usr/share/icons/Humanity/devices/48/printer.svg to _usr_share_icons_Humanity_devices_48_printer.svg
Is there a specific circumstance in which would would expect a file looked for at /usr/share/icons/Humanity/devices/48/printer.svg would instead be ./_usr_share_icons_Humanity_devices_48_printer.svg? This seems oddly specific.
(In reply to Nate Graham from comment #1) > Is there a specific circumstance in which would would expect a file looked > for at /usr/share/icons/Humanity/devices/48/printer.svg would instead be > ./_usr_share_icons_Humanity_devices_48_printer.svg? This seems oddly > specific. When I say "relative", I'm saying relative to the icon theme, not relative to current working directory (./). The proposal is: if an icon is not found in the absolute path specified by the program (in my example, it is not a program, just a .desktop file), the process responsible for interpreting the path should try to use an icon of the current theme as a fallback (before using the mimetype "empty file" icon). I don't know how ubuntu software center is going since I use manjaro, but a few years ago this was the way USC assigned icons to its programs inside of it, if it was not found within the manifest (or something like that), it uses an icon in this format, being affected by the current icon theme.
Oh I see, so if something asks for /usr/share/icons/Humanity/devices/48/printer.svg and that path is not found, it would instead look for printer.svg in the icon theme instead of saying, "nope, nothing found!" Seems reasonable.
The proposal to convert "/foo/bar/icon.svg" to "_foo_bar_icon" and not just "icon" is, as you may have noticed, the context. eg /my/app/icon/path/logo.svg will be converted to a very generic icon name "logo". "_my_app_icon_path_logo" looks more specific, and can be covered respecting the dev's intentions
What I understand is that if the app dev asks for "icon.svg" from a specific path and it's not found, we can try to find an icon of the same name in the icon theme, but we can't look for a differently-named icon based on combining the parts of the full file path. That wouldn't make any sense and would never return a match.
"would never return a match." Well, this is a concern for icon theme designers. On the team breeze side, they don't have to worry, the most that can happen is what already happens, the icon can't be found, and that's where the sense of third parties contributing their themes comes in. The meaning of using "_foo_bar_icon" instead of "icon", as I said, is the context.
Giving the code an absolute path, is restricting it to that exact path, if it's not found, the search should fail (as it does now).