the new pano tool

[brad]

Digikam-Devs,

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.

Is there a specific reason to call clearEnvironment()?

Thanks,
 -- brad


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Benjamin Girault]

I Brad,

2011/10/11 bkn <[hidden email]>:
> 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?

> Is there a specific reason to call clearEnvironment()?

Yes, KDEAPI says so:

<clearEnvironment() documentation>
Empties the process' environment.

Note that LD_LIBRARY_PATH/DYLD_LIBRARY_PATH is automatically added on *NIX.

This function must be called before starting the process.
</clearEnvironment() documentation>

--
Benjamin.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[brad]

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

> 2011/10/11 bkn <[hidden email]>:
> > 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


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Benjamin Girault]

2011/10/11 bkn <[hidden email]>:

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

There should be a way to not hardcode such a thing, since the QT and
KDE APIs are meant for OS abstraction.

Have you set your PATH with /etc/paths, or in a file in the directory
/etc/paths.d/? Those seems to be the standard way of setting the PATH
under Mac OSX.

--
Benjamin.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[brad]

Benjamin and Devs List,

Just want to give a update to the PATHs problem on OS X. Just to re-cap, there
are two two ways to install Hugin,

H-1) User can install Hugin through macports, in which case the binaries would
be in /opt/local/bin (or to put it in a non-hardcoded fashion,
KStandardDirs::installPath("exe") ).

H-2) User can install Hugin through the standalone Hugin package directly from
Hugin's website, in which case the binaries would be in
/Applications/Hugin/HuginTools/

Also, there are also two scenarios of launching digikam on OS X.

D-1) User can launch digikam from the command line by executing the binary
explicitly, in which case PATHs that a found in .profile, .bashrc et al are
loaded into QProcess::systemEnvironment() as well as paths from /etc/path,
which you mentioned previously.

D-2) User can launch digikam from Finder.app, which is how most people launch
applications in OS X. This means the user navigates to the application and
double clicks on it to run it. The same affect applies when launching from the
OS X Dock Bar. In this case, no paths are loaded from any shell environment;
so anything in /etc/path, .profile, .bashrc et al is not used. This scenario is
the most difficult to handle, but it is the likeliest of scenarios.

If the user installed Hugin using method H-1, it is straightforward to set up
paths since we know these binaries live in the kde prefix, but the environment
still needs to be setup after calling KProcess::clearEnvironment, which can be
done by calling QProcess.setProcessEnvironment(
QProcess::systemEnvironment()). It also might be necessary to add the kde
prefix to the env too.

If the user installed Hugin using method H-2, things are more difficult, and I
haven't found a good solution yet (even simply adding
/Applications/Hugin/HuginTools/ to the path in the KProcess instance didn't
seem to work).

I think a decent solution is if the plugin can't find autooptimiser (the frist
Hugin binary it tried to find), an option is given to the user to navigate
where Hugin is installed and set up PATHs based on that information.

I'm going to try a few things. It is likely going to take a couple of weeks.
I'll report back when i have some kind of solution in place. I also have a
hunch that a very similar problem will exist on windows when using the
panorama tool.

Cheers,
 -- brad


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel