Hi, everyone!!
Just thought I'd visit the maillist today. ^^
On 3/14/2009 4:22 PM, Krzysztof Kosiński wrote:
Jon A. Cruz wrote:
INKSCAPE_PIXMAPDIR is something very old and broken, and needs major fixing. It also is a *major* issue when it comes to OS X, since packaging is different than on Linux.
It should be defined at configure time, but someone decided to hardcode it relative to $(datadir) in path-prefix.h. Supposedly it is that way to support Autopackage. We need two things to fix it:
- A way to set it (and other path defines) on configure time. Essentially,
remove path-prefix.h and add some stuff to configure.
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.
- A set of functions that return those defined locations on Linux and
figure out the correct absolute paths on Windows. Otherwise the CLI on Windows will remain totally broken because now we chdir to Inkscape's installation dir.
Setting the current directory was to fix a different problem, with how executable searches are handled in Windows. The executable's dir and current dir are searched separately, unlike Linux. Like if you were in c:\a\b\c , and executed c:\f\g\h\something.exe, then 'c' and 'h' would both be searched, even if 'h' is not in PATH.
But, yes, I think the fix itself is broken and we need to handle it in a better way than cd-ing. SetCurrentDirectory() doesn't really affect paths very much. Maybe command-line stuff.
The correct way is to build paths relative to the executable path fetched using GetModuleFileNameW.
...which is how we mimic binreloc in Win32 (see prefix.cpp), and other things in Inkscape.
I suggest that we don't take away its current functionality (which does work fine for its purpose) but add to it. How about instead of a single root which is prepended to a resource name, we perform a search, like PATH does, or Java's classpath?
like instead of
resource = SOME_PATH_MACRO("specified/path");
resource = findSomeKindOfResource("specified/path");
This would allow the real files to be located in a variety/multitude of places, -including a cache-. A cache could be useful in the future. Mozilla does this. It would fix OSX's problem. And there could be a system and personal directory.
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. URI's not only have specific semantics, but their algorithms for resolve() and normalize() give predictable results for resource references. They would fix so many of these little problems with which we have been struggling.
actualURI = searchForResourceType(specifiedURI);
Whatever fixes we do, they need to be vanilla enough to work the same on at least our 3 main platforms identically. Linux-specific can be just as bad as Windows-specific.
(By the way, the only Win32 I use myself is this personal laptop. Everything at work is Unix).
bob