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

[Ananta Palani]

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





--- Comment #27 from Ananta Palani <anantapalani gmail com>  2012-01-11 20:00:10 ---
(In reply to comment #24)
> Just compiled and tested and it looks great! well done! i like the new layout
> with the icons on the left, uses left horizontal space. i think the development
> version issue was related some missing connections related the adding to the
> search paths. It all appears to work now. I'd like to see if this can be run on
> windows.

There still seems to be some problems. Only one of them is a blocker, but the
other two are import usability considerations.



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.

If hugin is autodetected, works great except:
3. No option to change the hugin executables

Solution: Alter 'find' button text to something like 'change' if executable is
known.

Is there any reason why each executable is identified separately anyway? It
would be safest to assume that all hugin executables are only compatible with
their packaged versions, so why would I want to be able to browse for each
executable separately when they could possibly be from different versions?

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.

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