[ptx] selection of external progams under OSX

[JD Smith]

On Thu, 2006-08-10 at 20:53 +0100, Ippei UKAI wrote:
> On 2006-08-10, at 19:54, Pablo d'Angelo wrote:
> 
> > I'm resending this message, since it somehow didn't show up on the  
> > list.
> 
> The both messages got me alright. I sometimes get my own message a  
> few hours after I receive replies, so might be a same problem.
> 
> 
> > Your suggestion (If I understood correctly)
> >
> > [x]  Use default
> > [ ]  Enblend program: _____________   [browse]
> >
> > First option: hugin searches for program named enblend, reports  
> > failure
> > if it doesn't find anything and asks the user to install enblend  
> > somewhere
> > in the system.
> >
> > Second option: hugin tries to open the program "/wherever/enblend",  
> > and
> > complains if it is missing.
> >
> 
> > Current state (at least UI wise):
> >
> > Enblend program: _enblend______   [browse]
> >
> > If just "enblend" is written in the entry box (default value),  
> > behaviour
> > would be equivalent to "[x] Use system default". Otherwise it would  
> > be the
> > second option.
> >
> > If it isn't found either way hugin would complain about it and asks to
> > install enblend.
> >
> > There is no need to understand the difference between absolute and  
> > relative
> > paths, because if enblend is bundled with hugin, it will  
> > automatically be
> > found without any user interaction. The same if an (not yet existing)
> > autopano-sift bundle is placed somewhere.
> 
> Sorry, but yeah, users don't need to understand paths. My bad. Though  
> my point still remains. The end users have no way to discover "having  
> default value triggers automatically, and manual otherwise" behaviour  
> from this GUI.
> 
> Also there is a problem when enblend is not in the user specified  
> path. If we automatically used the one in the default locations, the  
> user would be confused. If we asked the user to choose one, end users  
> don't know where default enblend is (inside the bundle is invisible,  
> by the way). We should at least add the "Use the one installed"  
> option to "Enblend not found" dialog.
> 
> 
> > If they want to revert to the bundled enblend, they would just  
> > press "reset
> > to defaults". (Maybe this is the real problem for OSX users,  
> > pressing reset
> > to defaults button instead of selecting the "[x] Use default" radio  
> > button ?).
> 
> I think this isn't an ideal approach at all. The user has to wonder a  
> bit how he can get the automatic behaviour back. Indeed they would  
> try resetting things to default sacrificing other settings after a  
> while, but is that the GUI design you take?
> 
> Anyway, I think your point is that end users rarely touch those  
> properties, and the current approach works alright until something  
> goes wrong for them. I agree with that. The fix is not urgent.
> 
> 
> > Can some other users please comment on this?
> 
> I would really love to hear from the users about this too. Anyone?

I'm an OSX user who uses Linux primarily (I'd bet many other Hugin.app
users are similar bi-platform types), so I'm not representative of the
command-line-fearing Mac user, but the ideal bundle would be one which
works by default with no intervention.  If this means putting enblend in
the bundle, that will satisfy 99.9% of all users.  Users saavy enough to
know they might want another enblend will understand how to specify
absolute paths, etc.  Conceptually, this is cleaner in Linux:

Enblend program: _enblend______   [browse]
 
and this is cleaner for bundled (not hand-compiled) Hugin.app:

 [x]  Use default
 [ ]  Enblend program: _____________   [browse]

I think something similar could work for all cases:

 [ ]  Use custom Enblend program: _____________ [browse]

Then if you leave this unchecked (the default), it searches for enblend
in the PATH, and, on OSX, looks inside the bundle too (OSX has PATH
which the shell will search just like any Unix).  Otherwise, you can
specify the other version by hand (Linuxy), or by browsing (OSXy) for
it.

The main goal here was so that no user actually had to go to the
preferences and do anything.  This accomplishes that.

JD

P.S. Pablo, where would you recommend inserting code into the
configure.ac/Makefile.am/etc. bootstrapped compiler stuff to test for
Mac platform and create the needed Hugin.app files, copying the compiled
executable into place?