[ptx] Hugin 0.6 on OS X Crashing

[JD Smith]

On Sat, 2006-08-05 at 10:57 +0100, Ippei UKAI wrote:

> mkdir $buildDir/HuginOSX.app
> mkdir $buildDir/HuginOSX.app/Contents
> mkdir $buildDir/HuginOSX.app/Contents/MacOS
> mkdir $buildDir/HuginOSX.app/Contents/Resources
> echo "APPLHgin" > $buildDir/HuginOSX.app/Contents/PkgInfo
> cp $infoFile $buildDir/HuginOSX.app/Contents/Info.plist
> cp -r $xrcDir $buildDir/HuginOSX.app/Contents/Resources
> ...
> chmod ... # should be needed, but don't know how #
> 
> I don't know Makefile syntax, but in Shell script, a few lines like  
> above can make a bundle structure easily. No need of the structure  
> itself in CVS, is there?

Thanks for this, very easy to use.

> >>> 3. (optional) Borrow their make-package script to make a compressed
> >>> installer package .dmg file.
> >>
> >> Well, .dmg is just a disk image format. Probably a good idea to make
> >> a lisence enabled dmg file for HuginOSX.app and a separate package
> >> (proper Installer package or just .tgz file) to distribute command
> >> line tools.
> >
> > The .dmg contains a .pkg, which runs automatically in OSX's installer.
> > So it does everything for you.
> 
> I thought Apple suggests dmg+DnD installation be the primary means if  
> possible. If we bundle enblend in HuginOSX.app, DnD works perfectly.  
> Installer package would be the solution if we have to separate them,  
> as we can make users to read the each project's read me files and  
> decide whether to install both.

Yes, that's right.  Emacs uses it to install all the /usr/local/emacs
stuff (which isn't in the Emacs.app package).  We could do the same if
we need to distribute the other tools, but keep them separate, and
prompt for license agreement at install time.  Otherwise Drag and Drop
is preferred.

> Of course autopano-sift can be dealt in the same manner, but it has a  
> very different stability issue. We should deal with it on a separate  
> thread, but please note autopano-sift on Mac is like a chunk of hacks  
> at the best. Shell scripts should not be used in this extent if one  
> wants to support a product for end users after all. (I really mean it  
> after dealing with crazy Matlab for Mac...)

Yes, especially for Macs, relying on autopano-* is troublesome for a
variety of reasons, such as no support except for 8-bit images, mono
framework required, etc.  I wonder if we could convince someone
(Sebastian?) to "vigrafy" autopano-sift, and position it more like
enblend (or even as part of the Hugin library set)?

> >>> We could even copy enblend and autopano-sift into Contents/MacOS
> >>> (assuming license issues with the later don't interfere), and pre-
> >>> configure Hugin to look for them there.
> >>
> >> This is what I have intended to do and technically it's already
> >> possible. Eventually it's not done for license and/or other moral
> >> reasons. (Don't ask me...) I'm attaching AppleScript applications
> >> that let users to do this by their selves. My enblend lives in /MacOS
> >> and autopano-sift lives in /Resources/autopano-sift. With those files
> >> inside the bundle, simple DnD installation is possible.
> >
> > Yes, and as Roger pointed out, this is confusing for the end user.  We
> > should either stick to enblend and autopano-sift as separate, and have
> > them linked to in their normal place in the directory hierarchy
> > (adjacent Hugin.app, I guess), or just embed them.
> 
> You mean I should disable the preferences for those paths if it  
> should be in normal places or embedded?
> (By the way, usual places on Mac are "Application Support" folders;  
> adjacent is a bad idea as no one wants enblend in /Applications.)

I just mean that we should provide Hugin.app the default paths to the
location for where the installer puts enblend and autopano-sift, either
in a folder, relative to the Hugin.app bundle (for drag and drop), or
in /Library/Application Support/Hugin/ (for real package based
installation).  In the latter case, we could have Hugin/AutoPano/Enblend
license agreements shown in the .pkg installer, which might help ease
the situation w.r.t. license and patent concerns.

> > I actually see no issue with embedding Enblend and autopano-sift into
> > Hugin.app, since both are GPL.  The patent issue is a separate one; I
> > believe it's still pending in the US, but even if it weren't, patent
> > infringement has nothing to do with copyright (for instance, it's
> > estimated that the Linux kernel infringes 300 or more patents).
> 
> Let's see what the Project Managers have to say to this. I think it's  
> OK to bundle enblend and autopano-sift ready to use IF we give enough  
> notice to the end users that those are not part of Hugin Project and  
> may have different terms-of-uses (though they happen to be all under  
> GPL).

I think a package installer with click through "Agree" button might just
do a nice job with this.

Thanks,

JD