Hi, 2011/10/15 zarl <[email protected]>
> Hi Harry, I hope you monitor this thread... > > That's quite interesting... the Hugin builds for OS X use an installer > only for some short time, before that users were able to just drag the > application from a dmg image to wherever one wished (or was able) to > drop Hugin. The latter could have been the user's desktop or his/her > own applications directory (in /Users/<user>/Applications/) whereas an > installer favours /Applications/ and asks the user for an admin pw. > > Apart from the problem Roy runs into there is also one other "feature" > that I think of: it's a lot easier to test the behaviour of different > versions when I'm able to set up different folders with several > versions of hugin. > > Is there an important reason why an installer is to be preferred? And > would it make sense to return to the former behaviour? > > Carl > > I certainly monitor this thread and I already have been thinking about it. The reason I switched to an installer is due to the fact that there is an interdependability between the new set of apps being Hugin, PTBatcherGui and calibrate_lens_gui. PTBatcherGui and calibrate_lens_gui almost 100% contain of symlinks to the tools, libraries and frameworks inside the Hugin.app. This to keep the total amound of data a few more megabytes bigger than only the Hugin.app. With " independent" bundles they would all be the size of the Hugin.app which is a waist of space in my eyes. The current small PTBatchergui.app and calibrate_lens_gui.app should never be seperated from the Hugin.app. Next to that I have the HuginTools folder containing the symlinks to the command line tools inside the Hugin.app. The easiest way to maintain this structure is to use an installer that takes care of that. Today I have been thinking of switching to the following concept, option 1: - Use and maintain the installer only for Release versions to make sure that these are properly installed and registered. This makes it possible to prevent errors that could easily occur with beginners(*). - The development bundles could be delivered as .dmgs containing a Hugin folder with the apps and Hugintools folder inside it, next to the current folders. This Hugin folder then can be dragged/copied to any place of your liking. The drawback of this setup is that when you double-click a .pto, it will be opened by the registered version, which will be a release version. So when working with a development version you have to open the app and then add images or open a pto. Another option (2): - could be to (ab)use the copyright message when you open a dmg. You might remember that about 1-2 years ago, the ControlPoint detector plugin dmgs for autopano-sift-c came with a copyright/license message upon opening. This could be built in again but now displaying something like "copy the apps and stuff together and don't mix versions in one folder, etc. etc.". Option 3: Do both like done on windows: give an installer and a zip (in our case a dmg) and the user decides. Please all give me feedback to options (1), (2) and (3), and if you have more/better options, share them as well. Hoi, Harry (*): Setting up the installer without administrator right means that you can't install inside /Applications. The default installers are not so flexible that it will automatically switch to administrator mode when relevant and to "user mode" when installing to some other location. Maybe a few of the paid installers do but I don't want to use that. -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
