Icon name search should try exact match in all themes before trying similar icon names

[Evgeny Kolesnikov]

I'm trying to load stock icon by name (appointment-soon [orange clock from gnome theme] and appointment-missed [orange clock with red "!" from gnome theme]) but AI loads another icon with similar name: appointment or appointment-new [gray clock with green "+"]. Tested with Ubuntu-Mono-Light icon theme. Lucid+updates. Here is the code:

import gobject
import gtk
import appindicator

def menuitem_response(widget, buf):
 ind.set_status (appindicator.STATUS_ATTENTION)

if __name__ == "__main__":
 ind = appindicator.Indicator ("example-simple-client",
  "appointment-soon",
   appindicator.CATEGORY_APPLICATION_STATUS)
 ind.set_status (appindicator.STATUS_ACTIVE)
 ind.set_attention_icon ("appointment-missed")

 menu = gtk.Menu()
 buf = "Attention!"
 menu_items = gtk.MenuItem(buf)
 menu.append(menu_items)
 menu_items.connect("activate", menuitem_response, buf)
 menu_items.show()

        ind.set_menu(menu)

        gtk.main()

[evelio (q-launchpad-euresti-com)]

This happens because the app-indicator searches for an icon named 'appointment-soon' and if that's not in the current theme it then searches for 'appointment' before it goes to the next Theme.

The call is g_themed_icon_new_with_default_fallbacks followed by gtk_icon_theme_lookup_by_gicon.

It seems like it should search all the themes before falling back.

PS. This basically stops any app that wants to include its own icons using app_indicator_new_with_path since the path is appended as a last Theme if they say 'myapp-idle', but the default theme has an icon called 'myapp' it will always use 'myapp'.

[Evgeny Kolesnikov (evgenyz)]

I have objection about Wishlist status: this bug breaks theme inheritance ideology in weakly predictable way. And, which is more significant:

"This basically stops any app that wants to include its own icons using app_indicator_new_with_path since the path is appended as a last Theme if they say 'myapp-idle', but the default theme has an icon called 'myapp' it will always use 'myapp'."

This should be Bug.

[Evgeny Kolesnikov (evgenyz)]

Any updates on this?

[MestreLion (mestrelion)]

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?