More about GIMP environment and portability

In a packager view, current Gimp installer has interesting drawback of its installation method. That is installer put two absolute path during setup:
default.env : Path=C:\Program Files\Gimp-2.0\bin
pygimp.interp : python=c:\python25\pythonw.exe

So why static absolute path is bad? Because nothing can't automatically fix/update it when gimp folder moved (unless you reinstall it of course).. and will render all plugins unusable which also meaning make file association harder. Moved? Yes this post lead to portable thingy. Which currently put my combo gimpscape installer in pending state >,<

Note that "program files" might be taken from %PROGRAMFILES% of system variable. In most case, modern windows application heavily rely path configuration to registry -said, it's faster to initiliaze- but we know that OSS programs especially those ported from linux didn't rely on registry by default.



About default.env
Why Path variable exist?
It's probably to keep plugin executables find its dependency which reside there, this Path isn't the same as windows PATH a.k.a you can't expect by putting "C:\Program Files\Gimp-2.0\bin" in PATH you'll get the same effect while discarding default.env. Nonetheless while inside default.env we can put system environment variables, just this time we must do it in form ${programfiles} instead of %programfiles%.

After look at gimprc I found two interesting variable that could always bring correct gimp folder wherever it moved thus should keep gimp consistently portable.
gimp_plug_in_dir -> <gimp path>/lib/gimp/2.0
gimp_data_dir -> <gimp path>/share/gimp/2.0
from any of two above, we could define bin path like:  ${gimp_plug_in_dir}/../../../bin
I haven't found variable that directly point to bin folder yet.. :(

We could also use ${programfiles}\GIMP-2.0\bin  but then we've just hardcoded gimp folder as "GIMP-2.0" given it's probably funny for user to rename the folder. More, this only benefit gimp when we change "Program Files" Path. For ex. gimp folder moved from computer A to B where B have user defined %programfiles% or have different native language.

About pygimp.interp
After reading the corresponding source code (gimpinterpreterdb.c) there is no path expander (defined as gimp_config_path_expand() function) there. That's why pygimp.interp didn't parse environment variable (unlike default.env) which is my main obstacle in bringing GIMP Portable alongside pygimp. Interestingly enough, gimp just read any files in interpreters folder and parse it for python executable. Therefore pygimp.interp it's not hardcoded filename and could be any plain text file.

Now by intervere variable "program" parsing with gimp_config_path_expand() we will have python interpreter that can be defined more dynamically. (Just recompile it :D)

So, if in packaging process bundled python placed at toplevel folder, in pygimp.interp we could write like this : python=${gimp_plug_in_dir}/../../../python/pythonw.exe

Examples:
default.env problem:
Even with incorrect Path variable, we could expect gimp and plugin (not to include pygimp) to run smoothly from bin directory. To simplify this, we usually run gimp from a shortcut which has its own editable working directory parameter. But what happen if we call gimp as the result of file association? In windows, the simplest method is <gimp executable path as defined in registry>\gimp.exe %1. This way, when double click on <my documents>\logo.xcf (%1) system will call gimp using xcf file path as current working directory. This is totally different with first case, and without correct default.env all plugins will be broken cause they try to search dependencies inside <my documents> not in <gimp path>\bin. To get executable path should use GetModuleFileName() in windows.

pygimp.interp problem:
With current official state this is even worse than default.env, there nothing we can do with pygimp.interp. Of course, we could put relative path like: ../Python/pythonw.exe (which is a solution for non file-associated portable app), but that's is useless when facing file association.

Portability
In gimprc there also interesting variable that will override default setting when set up correctly. That's GIMP2_DIRECTORY, this variable will guide gimp to user defined folder where preference and setting saved (that is e.g C:\Documents and Settings\username\.gimp-2.6), be it as user environment or system-wide environment. In case of portable apps, a batch/loader may set this variable dynamically before execute gimp. Or in my preference create a setup batch command that set the variable permanently and enable file association in a session of usage. Inkscape also have similar variable called INKSCAPE_PORTABLE_PROFILE_DIR. By using %~dp0 cmd variable it's easy to setup Gimp or Inkscape in removable media.

Why gimp not use %appdata%?

This offending code for this is gimpenv.c. Actually almost all except few (AFAIK pidgin and inkscape) have been use %userprofile% for storing user data and settings. Worse using ".gimp-2.6" which is simply invalid folder name at least by explorer (we still able create such with "mkdir" though). This is brought from *nix standart naming where a dot prefixed folder is hidden by system but not for Windows. From gimpenv.c we could change this behavior by set a windows ifdef and passing g_getenv("APPDATA") into home_dir variable. For .gimp-2.6 naming problem, it could be passed during configure by supplying e.g --with-gimpdir=gimp-2.6 

---------
This post of course irrelevant in linux case, where directory structure & naming is governed by standart. Where in windows you can't say "Program Files", "Documents and Settings" or other common location as standart way or preassumed. Even I defined my own %Programfiles% as "Programs" to avoid namespace, most OSS (especially linux ported) should get used to retrieve environment variable more. That's the standart way in windows and personally I won't care any case like "Oh what if there is no %temp% or no %appdata%?" then this is faulty system and faulty user (I could bet, this kind of windows will be reinstalled anytime soon). This should not be supported as exception but must be discarded as errorneous (give them warning that their windows need to be recycled! instead).