[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 #16 from brad <bkn ithryn net>  2012-01-10 01:37:30 ---
On Jan 9, 2012, at 4:46 PM, <benjamin.girault at gmail.com>
<benjamin.girault at gmail.com> wrote:

> https://bugs.kde.org/show_bug.cgi?id=286018
> 
> 
> benjamin.girault at gmail.com changed:
> 
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|UNCONFIRMED                 |ASSIGNED
>     Ever Confirmed|0                           |1
> 
> 
> 
> 
> --- Comment #15 from  <benjamin girault gmail com>  2012-01-09 21:46:57 ---
> The patch is reviewed and integrated into the repository. It works (at least)
> on linux. Can somebody confirm that it works on MacOS and Windows?
> 
> Brad: I like your solution to the issue, and only made some changes to make it
> more general and straightforward for the future.

Great! i'm glad i could finally get a patch that would apply, it only took
three tries.

> I only have one question: is
> there a reason why you kept the "virtual" keyword in front of every
> "parseHeader" function of BinaryIFace children?
> 
No good reason, feel free to eliminate that. 


I have tested the new code and noticed a couple of things:

 1) suppose multiple binaries are not found immediately, then when use
navigates to one binary, the will have to navigate to the next binary even if
both binaries exists in the same directory, which is usually the case for the
hugin binaries. In my patch i had come connections in manager.{cpp,h} which
propagated a signal though the classes to add a directory to the search path
list. I can submit another patch off the latest codebase for this.

 2) i appears that if the development version of a binary is being used that
one cannot proceed. for some reason my cpfind binary is flagged as development
version. Looking at it more closely, any version of cpfind that contains the
ThreadQueue text will get flagged as development version since once through the
foreach-loop in cpfindbinary.cpp:64 will set m_developmentVersion to true. If
the binary contains the ThreadQueue text will go through the loop at least
once.

 3) if binaries not found, the window becomes very wide --- too wide for my
laptop to handle. I think that's because of the warning message displayed.

 4) the 'download' link to binaries not found appears below the groupbox, i
assume it is meant to be inline within the rows in the groupbox.

Lastly, i have no idea how this works (or doesn't work) under windows. i do not
have a windows machine to test on.

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