[Kde-imaging] [Bug 286018] Pano Tool and ExpoBlend tool do not work on OS X [patch]

[brad]

https://bugs.kde.org/show_bug.cgi?id=286018





--- Comment #32 from brad <bkn ithryn net>  2012-01-11 22:43:52 ---
On Jan 11, 2012, at 3:00 PM, Ananta Palani wrote:

> https://bugs.kde.org/show_bug.cgi?id=286018
> 
> 
> However, if hugin cannot be autodetected or if hugin was previously found and
> now no longer found (due to hugin being moved/hugin uninstalled/etc):
> 1. Have to browse for each executable separately. 'Find'ing one application
> does not try auto-find the remainder from the same 'bin' directory.
> 
> Solution: have remainder of executables auto-detected in same directory (re-run
> detection that is done on plugin start-up using new path?)
> 
> 2. After 'find'ing all executables (all icons at left turn green) the buttons
> on the bottom do not activate. Only 'cancel' can be clicked, which causes
> digiKam to forget the new hugin executable locations.
> 
> Solution: enable 'next' and 'finish' (?) buttons after all executables are
> found.
> 
interesting ... i had both of these problems that i mentioned in comment:#16.
However after Benjamin submitted more code -- yesterday i believe -- it seemed
to work. I just double checked to make sure i was checking out a clean version
of the git repo, recompiled and it still works on the OS X end. I'm not sure
what could be wrong on windows.

> Instead, why don't remove the 'find' buttons for each app and instead simply
> have the path to hugin executables listed above all the apps (or a message
> saying hugin could not be found if path is unknown), and a button to browse for
> the location where hugin is installed? After browsing for this location, run
> the executable auto-detect based on the new path and populate your executable
> info table. Just seems redundant to have multiple 'find' buttons and 'download'
> links. Just a thought.
> 
I had mentioned something similar in comment:#8. I had kind of abandoned that
idea because of the difference in linux binaries layout and, say OS X's and
windows. On OS X, if you install Hugin from hugin's website, all the binaries 
are in /Applications/Hugin/HuginTools (in fact i had that hard coded in my
patch since those paths remain reasonable consistent). I assume it is similar
for windows, right? But on linux (i'm familiar with ubuntu), things are
different. How would you have the user to navigate to Hugin on linux? There is
a /usr/bin/hugin -- but that's part of the 'hugin' package, whereas the other
tools are part of the hugin-tools package. I suppose that this may be a
degenerate case since those binaries will be picked up since they're in the
user's path; if that is the case then we can probably code something to simply
navigate to the Hugin package for non-linux OS's -- i do like that solution
better, seems simpler. Then, perhaps we could have an 'advanced' part of the
window/settings where a user could navigate to the individual binaries -- that
might address benjamin's concern about having hugin binaries installed in
multiple locations. 

But ... i think this might just wait until the above three points you made are 
addressed. Although i'd like a solution where you just navigate to where hugin 
is installed for OS X/Windows.

> -- 
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.