But the bug is not about append/prepend behavior: path must be appended, like it is now, and NOT prepended. If it was prepended, the apps' theme_path would always be picked first, and any user theme would be ignored. So prepending would prevent themability.
The REAL bug is what evelio said in comment #1: app-indicator searches for alternate icon names before trying an exact match in other themes (including apps "theme_path"). THAT is what prevents an app from changing icons.
A common scenario:
- temperature monitor 'myapp' app has several status-like icons as myapp-{normal,hot,cool,error}.png
- they are in "/usr/share/myapp" , and app sets that when calling AppIndicator3.Indicator.new_with_path()
- app also installs a desktop file and an icon (for dash, launcher, autostart) in /usr/share/icons/hicolor/48x48/apps/myapp.png
- at run time, eventually app tries to set_icon('myapp-hot')
FAIL!
It can't! AppIndicator icon is locked to hicolor/myapp (the 'main' icon), because libappindicator thinks 'myapp' is acceptable and it won't even *try* to look for <theme_path>/myapp-hot
This is a BUG, *not* a Wishlist
A workaround is to rename the apps' "main" icon to 'myapp-icon' (which is quite silly), or install the status icons along with main one (polluting the themes and defeating the whole point of new_with_path(,,,theme_path). And pray there is no similar-named icons in other packages/themes. And not using stock icons as OP wanted.
A proper solution is not to prepend theme_path (it would work, but defeats themability), but to first try *exact* icon name matches in all themes BEFORE it tries this "smart" similarity matching.
This is NOT wishlist, this is a bug!
But the bug is not about append/prepend behavior: path must be appended, like it is now, and NOT prepended. If it was prepended, the apps' theme_path would always be picked first, and any user theme would be ignored. So prepending would prevent themability.
The REAL bug is what evelio said in comment #1: app-indicator searches for alternate icon names before trying an exact match in other themes (including apps "theme_path"). THAT is what prevents an app from changing icons.
A common scenario: normal, hot,cool, error}. png Indicator. new_with_ path() icons/hicolor/ 48x48/apps/ myapp.png 'myapp- hot')
- temperature monitor 'myapp' app has several status-like icons as myapp-{
- they are in "/usr/share/myapp" , and app sets that when calling AppIndicator3.
- app also installs a desktop file and an icon (for dash, launcher, autostart) in /usr/share/
- at run time, eventually app tries to set_icon(
FAIL!
It can't! AppIndicator icon is locked to hicolor/myapp (the 'main' icon), because libappindicator thinks 'myapp' is acceptable and it won't even *try* to look for <theme_ path>/myapp- hot
This is a BUG, *not* a Wishlist
A workaround is to rename the apps' "main" icon to 'myapp-icon' (which is quite silly), or install the status icons along with main one (polluting the themes and defeating the whole point of new_with_ path(,, ,theme_ path). And pray there is no similar-named icons in other packages/themes. And not using stock icons as OP wanted.
A proper solution is not to prepend theme_path (it would work, but defeats themability), but to first try *exact* icon name matches in all themes BEFORE it tries this "smart" similarity matching.
Any chance of this happening?