Unfortunately that's rather backwards as it means tentatively looking for .desktop files in the same folder, all parent folders, all sub folders and parsing any .desktop that may be found, for every single image opened - when the app had to have done this, more efficiently, wherever the icon paths came from in the first place, this is why I was originally asking "Where do app icons come from?", because there information is there, but lost.
-- You received this bug notification because you are a member of DX Packages, which is subscribed to notify-osd in Ubuntu. Matching subscriptions: dx-packages https://bugs.launchpad.net/bugs/1363015 Title: App icons require shaping at every callsite Status in Ubuntu UI Toolkit: Won't Fix Status in notify-osd package in Ubuntu: New Bug description: In list items, showing an app icon in the correct Ubuntu shape requires shaping it when you are using it: ListItem.Standard{IconFrame: True}. <http://developer.ubuntu.com/api/qml/sdk-14.04/Ubuntu.Components.ListItems.Standard/#iconFrame-prop> That property is set to "True" by default, but it's not obvious why it should be, and list items aren't the only place that app icons get used. The result is that several times now, app updates have ended up without the appropriate frame: - in the System Settings "Updates" list (bug 1354478) - in the "Notifications" screen - in the Launcher the frame is unintentionally different (bug 1332119). Conversely, non-app icons have ended up *with* the frame by mistake: - "Display language" (bug 1288866) - "Orientation Lock" (bug 1365450) - Ubuntu updates (bug 1367136). In notification bubbles, the opposite applies -- you have to set a hint to use an *unshaped* icon: notify_notification_set_hint_string(m_notification, "x-canonical-non-shaped-icon", "true"). <https://wiki.ubuntu.com/Touch/Notifications#Elements_of_a_Notification> Predictably, this has resulted in cases of icons having frames when they shouldn't: - Wi-Fi network authentication (bug 1346904) - alarms (bug 1346925) - Remove Account (bug 1350282). On the API design quality scale, both of these are roughly "Read the implementation and you'll get it right." <http://sweng.the- davies.net/Home/rustys-api-design-manifesto> Worse, they have opposite defaults. I suggest that the toolkit move all the way up to "It's impossible to get wrong", by always shaping an icon when it is an app icon, and never otherwise. Whether an icon is an app icon could (I assume) be detected by its path. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1363015/+subscriptions -- Mailing list: https://launchpad.net/~dx-packages Post to : dx-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~dx-packages More help : https://help.launchpad.net/ListHelp