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:

1. 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. 

2. 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