Jon A. Cruz wrote:
- The user's chosen theme. The theme author should provide icons for
us here. This location is already in gtk_icon_theme_get_default(), and we mustn't touch it.
#1 is not always in the path (hence the mention in the spec). Or rather we need to do a 1.5 for the custom thing.
#1 is always in the path. "Default icon theme" means whatever the user has selected in the appearance dialog, not the Gnome theme or the hicolor theme. It's not the best choice of name but this is what it means in GTK. I also don't know what do you mean by "1.5". I already said that users do not put custom Inkscape icons in Inkscape's data dir, they install icon themes containing icons for Inkscape.
It appears that you seem to be missing one of the main points of the XDG directory spec.
I know what it's supposed to do, because this subject has been discussed to death. You can effectively run with a different set of user data and configuration by just tweaking an environment variable. However, XDG doesn't concern system-wide locations, only user locations. The configure stuff I was mentioning would be for system locations.
Bob Jamison wrote:
binreloc (upon which path-prefix.h is based) -fixes- problems. Now we have the choice of whether to have a static root or a settable root on Linux. We need to keep that.
With path-prefix we can only set the datadir at build time. Other paths are hardcoded relative to datadir. We cannot e.g. install icons in /opt/icons/inkscape (whatever might be the reason) and as I uderstand this is causing some issues with OSX packaging.
Also -- and we have been talking about this forever, and we really NEED to start thinking
about implementing it -- stop using C or C++ strings for paths, and start using URIs.
Simply using URIs instead of paths doesn't solve much, because we would still use hardcoded path (or URI) fragments in many places. A better solution would be to abstract away asset management (markers, palettes, gradients, dash patterns...) into a class, with functions like getTemplateList(), getMarkerList(), getPaletteList(), etc. (what those methods would return needs some thought.) That way the code that uses them need not be concerned with where those assets actually are and how they are accessed.
Regards, Krzysztof Kosiński