Ippei wrote: > Yuval Levy wrote: >> I agree they are not relevant to the majority of users, and should >> be optional, with default not to install them. > > That's definitely a TODO then. My friend's first question was "which > program should I open?"
Guido built the Windows installer. He modified for that my .iss file, which is in SVN. If he shares his .iss file, anybody could have a look at that. > Also, the alias should be named "Hugin", not "hugin.exe" if that's > possible. I have no desktop icon (I hate program's that put an icon on the desktop) but the icon inside the Program Files folder is called only Hugin here. What version of Windows does your friend have? > Weird. When I saw it, those aliases on the desktop all bore the same > Hugin icon including the enblend ones. very well possible - as I said, my comment is a general one, based on the snapshots installers I used to produce. Guido has modified the .iss file. It may be one of the changes he implemented there. Or it may be something weird with your friend's Windows box. Registry pain comes to my mind... > What I meant is that how Hugin is organised inside the Start menu. I > know Windows organises Start menu with folders and aliases (or > "shortcut" or whatever), and all hugin stuff would be found under the > "Hugin" folder. But using alias means "hugin.exe" can be shown as > "Hugin" there instead, right? Also, the other tools can be organised > into subfolders like "droplets" "tools" "command line tools" etc. OK, I understand. AFAIK the droplets need to be on the desktop to work. Or has somebody got them to work from the Start menu? yes, hugin.exe can be shown as Hugin. It is like that currently on my desktop. SUre, the other tools could be organized into subfolders. It's relatively easy to do and a good idea. > So no approval while installation or before the autopano process > happens? I am afraid not. Well, standard windows installer ask people to click on a button to accept a license (that they never read), and the license text with my snapshot installer was <http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/platforms/windows/installer/installer_license.txt?revision=2839&view=markup> I don't know how the text looks like on the current binary on SF. We definitely should do something about this. > I guess another TODO then. I actually put .txt manually for the Mac > package too. Couldn't we just break the UNIX convention and put .txt > on the SVN? I second that request. > Mac icons are not based on the files in the source but on an original > design acquired through a personal communication, so there might be > some difference in the situation. If Mac icons are nicer, shouldn't they be adopted also on other platforms? I'd like to see them. Are they in SVN? or how do you apply them? > If anyone is going to work on something new, rather than improvement > just for Windows, please consider to make it as large as 512 pixels. > Apple has declared the conventional 128 pixels is "minimum". I'd say: draw them in SVG... > Okay. I can do that. If anyone needs the converted file, please > specify in what format you want the file in. HTML would be best IMO. Can you add it to SVN? > There's a sort of > failsafe as release tar ball has no svn hence leading to automatic > revision retrieval failing and demanding manual intervention. (I think > that's how cmake is written also.) that's how it used to be. and with windows there was no retrieval at all, so it always demanded manual intervention. the way I have implemented it now is that if there is svn, it does automatic revision retrieval and stores the revision in a simple text file. automatic revision retrieval works for windows too. once the tree is stripped of svn for producing the tarball, the small text file with the revision number is preserved. when the tarball is built, it retrieves the revision number from the text file. last but not least, if the text file is not found, manual intervention is required. >> I hope my comments shed some lights on the particularities of the >> windows build. Maybe they may motivate some of the windows contributors >> to do those things you are suggesting, most of which make sense to me >> but are just too low on my list of priorities to bother. > > Same here. Would be really nice if anyone could take a look. The last > small details like above make a huge difference in the users' first > impression of Hugin. That's the fine line whether the user would go > straight to uninstall or not. In my experience, users often have more > patience to a nice looking software with bugs than to stable software > with unwelcoming impression. yes, you are right. i have not had time to toy with hugin this weekend, and I am unlikely to find time in the coming days. right now on my todo list is to solve the Olympus EXIF thing. I actually have the solution, am bogged down in implementation details. Debugging / playing this with Windows is a nightmare. I need to reboot to Linux, but my Ubuntu install is out of order at the moment. Yuv --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
