[Digikam-devel] the new pano tool

[bkn]

On Tuesday, October 11, 2011 07:38:34 AM Benjamin GIRAULT wrote:

> 2011/10/11 bkn <bkn at ithryn.net>:
> > I am on a quest to get this tool working on OS X. I was able to get it
> > working with a small modification, but i don't know if this change
> > breaks anything else. In short, there is call to
> > KProcess::clearEnvironment() in ActionThread::compileMKStepByStep and
> > ActionThread::compileMK. Removing these two line helps getting the tool
> > to run under OS X. The reason is that clearEnvironment() removes
> > directories in the user's $PATH which contain the stitching binaries
> > and the makefiles generated seem to rely on these tools existing in the
> > user's $PATH rather than specifying the full pathname of the binaries.
> Basically, you are saying that you modifiy locally your PATH, and it
> happens that those local changes are not preserved with the
> clearEnvironment() calls. Am I right?
> 
Exactly. 

> > Is there a specific reason to call clearEnvironment()?
> 
> Yes, KDEAPI says so:
> 
Sounds like a good reason to me.

Fortunately, there are basically two ways of installing Hugin on OS X.
 1) Using macports, in which case the binaries would be in /opt/local/bin
 2) Using the standalone Hugin package directly from Hugin's website, in which 
case the binaries would be in /Applications/Hugin/HuginTools/

Perhaps if digikam is being run on OS X these paths could be explicitly added 
to the environment after cleanEnv. is called. This might also solve the 
problem of locating the binaries in the first place in those cpfindbinary.cpp 
classes and the like. This would likely be helpful for those OS X users who 
are not savvy enough to edit their PATH, or for those who want to launch the 
app from the OS X Dock.

Does this sound like a good general solution? i'm hoping there is a more 
elegant way to at these paths without hardcoding them (actually using `kde4-
config --prefix` appears to work in the first case of using macports). 

Cheers,
 -- brad