[ptx] Re: Renewing hugin OSX Distribution

[Pablo d'Angelo]

Hi Ippei,

> Hello Pablo and everyone,
> 
> On 2006-08-09, at 18:17, Pablo d'Angelo wrote:
>> Pablo d'Angelo wrote:
>>
>>>> Suggested change to hugin itself
>>>>
>>>> In the preference, the paths to enblend and autopano should be the
>>>> choice between "Search Default Locations" and "Specify custom path".
>>>> On Linux, "default search locatins" would be the bin search paths, and
>>>> on Mac, would be "Application Support" folders of user and system
>>>> levels, and inside the .app application bundle.
>>>
>>> Yes, this might clarify things for the user. Do you want to add this
>>> yourself?
>>
>> Hmmm, actually what is the problem of the current approach? On linux
>> all the
>> binaries are usually installed in the path anyway, so the current
>> situation
>> is fine. On Windows, the installer sets the right paths during
>> installation.
> 
> The thing is, on OSX the user can freely move the application around.
> Consequently so does the path to enblend if it is inside the bundle. It
> could be one place, then could be the other on the next launch. It is
> very portable, and it is the operating system's job to find the files
> inside the bundle.

Yes, this is why I would add the bundle to the first place of the search.
This is some code that has to be added to the OSX version.
Then hugin will pick the program up from there if it is specified without
an explicit path (the default configuration).

So the behaviour would be (as it is under unix today):

I.  if the text entered in the preferences doesn't provide a path, just the
command (example: "enblend"), then search for it in the system path. This is
done automatically under unix by the shell, dependent on the users PATH
variable, but might has to be done by hugin on OSX with the FSFindFolder
function to search all the private/system/network folder you mentioned
below, if I understood correctly.
On OSX it would make sense to add the bundle to this path, so that programs
included in the bundle, such as enblend, can be found if the bundle is moved
around.

In short: if no absolute path given: search bundle and then usual directories

II. if an absolute path is provided (example:
"/users/home/my/localprogs/bin/enblend" under unix), no search is required
and the program is just started from there.


> [ ... ]
> To summarise, the locations of the resources should always be decided on
> runtime on Mac, not on installation nor at compilation. I thought the
> Linux executables are the same.

Yes, these directories are set with the $PATH variable.

> By default, so enblend can be anywhere
> in the bin search path, /usr/bin, /usr/local/bin, or ~/bin even.
> Wouldn't it be better to have "Search Default Locations" and "User
> Custom..." options instead of one fixed location displayed?  (Currenly
> HuginOSX searches the path specified in the preferences, then inside the
> bundle.)

I guess the confunsion between sofar was: You thought the TextCtrl should
only contain the directory where the program is located and I thought it
should contain the directory AND the executable name.

>> So the only configuration that needs improvements would be the OSX
>> installation. I think the GUI should be left like it is, and the path
>> should
>> include the main bundle directory where the enblend is shipped.

Maybe that sentence was not formulated well, sorry. I meant:
the search path for the executable should include the bundle. This implies
that the bundle path is added dynamically, and not while compilation or
installation.

>> Then, by
>> default the programs from the bundle are used. If the user would like
>> to use
>> a different version of the helper programs, he can always enter the full
>> path for it. Am I missing something?
> 
> What if the user wants to go back to the enblend inside the bundle or
> the search path on Linux? Currently the user needs to enter a fake path
> where no file can be found on Mac, and I guess "`/bin/which enblend`" or
> something for Linux.

No, he just hits the restore defaults button, which just resets the enblend
 location and file to "enblend". Then the enblend version that is first in
the path will be picked up. On linux this is perfectly understandable. No
further magic or specification of system or local paths required.

>> Also, the user has to be able to specify the command, not just the
>> path to
>> it! Otherwise people can't use any other programs, and would have to
>> rename
>> smartblend.exe to enblend.exe and so on, which is confusing...
> 
> That's when people would use "Custom" option to specify the path to the
> enblend-compatible they wants to use.

Do we really have to replace the Textfield + search button with a
a custom/system path choice control and custom path text field + selector
as well as a Custom Program textfield?

ciao
  Pablo