Yes, there was an internal discussion, summarizing:
* danrabbit also suggested nuking marlin_icon_info_lookup_from_name and using Gtk.Image.from_icon_name instead everywhere in marlin
* I have suggested using marlin_icon_info_lookup_from_name, and fixing it to avoid crashing in case of inexistent icons, as that's used in more places, which doesn't seem like a strong argument checking that it is called from 6 different places in trunk, 2 of those being the selection helpers, so replacing all occurrences wouldn't be that hard. I checked and it seems to have historical roots, dating back to nautilus times, as nautilus has nautilus_icon_info_lookup_from_name, which implements an additional level of icon cache for the icon views.
* as nautilus uses a similar/the same caching method, I have volunteered to ask around why it's there, and if it could be upstreamed in some way, before completely removing it from our code.
Yes, there was an internal discussion, summarizing: icon_info_ lookup_ from_name and using Gtk.Image. from_icon_ name instead everywhere in marlin icon_info_ lookup_ from_name, and fixing it to avoid crashing in case of inexistent icons, as that's used in more places, which doesn't seem like a strong argument checking that it is called from 6 different places in trunk, 2 of those being the selection helpers, so replacing all occurrences wouldn't be that hard. I checked and it seems to have historical roots, dating back to nautilus times, as nautilus has nautilus_ icon_info_ lookup_ from_name, which implements an additional level of icon cache for the icon views.
* danrabbit also suggested nuking marlin_
* I have suggested using marlin_
* as nautilus uses a similar/the same caching method, I have volunteered to ask around why it's there, and if it could be upstreamed in some way, before completely removing it from our code.