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

benjamin.girault at gmail.com benjamin.girault at gmail.com
Wed Jan 11 20:45:47 UTC 2012


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





--- Comment #29 from  <benjamin girault gmail com>  2012-01-11 20:45:47 ---
(In reply to comment #27)
> 1. Have to browse for each executable separately. 'Find'ing one application
> does not try auto-find the remainder from the same 'bin' directory.
> 
> 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.

Are you sure you have the latest code from the repository? Those two should be
corrected in my latest commits (and after testing again, it is still working on
Linux).

> 3. No option to change the hugin executables
> 
> Solution: Alter 'find' button text to something like 'change' if executable is
> known.

Good point. I'll change that.

> 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?

Actually, one could use Hugin's binaries from different version of Hugin in the
plugin, it doesn't matter (those binaries "communicate" through pto files, i.e.
Hugin project files whose syntax hasn't changed for a while).

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

One reason would how to handle the case where the binaries are in different
location. In that case, writing the GUI part would be a nightmare. Anyway, I
intend to reduce the number of necessary binaries during the Coding Sprint to
keep it to a minimum, and use directly Hugin's API.

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


More information about the Kde-imaging mailing list