On Sat, 2009-03-14 at 11:28 -0700, Krzysztof Kosiński wrote:
Regarding the edit-select all icon: It is probably a weird bug in select-toolbar.cpp because there is only one method to access the icons in icons.svg. All other icons display normally. I'm still in the process of finding out what's going on. The code for SPIcon is not exactly well organized.
Yes, I've been trying to explain that.
Our app now registers as a source of named icons. It needs to render and place the images in the source.
Then where we use icons we don't use the legacy SPIcon info directly, instead we just make the call/set things up to use named icons.
*If* no image exists for that in the current theme, then it falls back to one we placed. However if there is an icon in the current theme in the overall system, that will override the internal one we provided and thus follow the end-user's requests.
Finally, to follow the new "per-application" theme spec, all we need to do is locate the *dynamically* determined settings directory (changes at runtime due to the XDG directory spec), and add that directory to the list of sources searched for named icons.
Note that we want to move away from use of the "stock icon" and use the "named icon".
Look to gtk_icon_theme_append_search_path()
So... to summarize: The ancient SPIcon way was to do all the loading, rendering, caching, fetching and displaying was done directly. The newer way was changing a bit more to eventually *decouple* loading from display. We want to be a themed icon source and fill in our theme with internal images. Then whatever needs to use an icon just uses the themed icon loading to get it from the system, or ours as a fallback.