Comment 4 for bug 603057

Revision history for this message
MestreLion (mestrelion) wrote : Re: Appindicators should prepend app specific icon paths instead of append

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:
- 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.

Any chance of this happening?