Yuval Levy wrote: > Ippei wrote: > > Lately, I've assisted a friend of mine to install hugin on his PC. The > > following are what I, a mac user, realised:
> > - General: It felt more stable than Mac version, but lacking quality > > assuarance leaving tools that appeal only to geeks and detemined > > users. > > can you specify what you mean by "lacking quality assurance" and > "leaving tools that appeal only to geeks and determined users" ? > what would you expect to be different? I meant the impression of the installed files is somewhat of technical tools, like when I install command line academic tools. Once hugin is launched, it's the familiar hugin interface, which isn't common to all platforms. > > - Installer: By default, leaves tons of aliases on desktop. None > > except one for hugin.exe is relevant for 90% of the users. > > I can't comment about the installer that is on Sourceforge since I have > not built it and do not know the details. > > I have built and distributed snapshot installers whose purpose was > testing. As such, the default of that installer was to install plenty of > things - things that I would not install in a production installer > geared at the general public. I agree with your comment that the default > install should satisfy the majority of users, not the power users; and > it should leave advanced features as options, not as default. > > In general, there is one single icon for hugin on the desktop. All other > icons are droplets for enblend and enfuse, which indeed appeal to power > users. > > In a testing setting I decided that installing them by default was the > right thing to do. Accidentally, it also appeal to power users. > > Erik Krause's droplets are one of the things I do keep on my desktop > (and no hugin icon - I start programs from the QuickLaunch). Because > they are convenient, and easy to use. But 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?" Also, the alias should be named "Hugin", not "hugin.exe" if that's possible. > > why the hell do they all have same icons? > > The droplets don't have an icon at all. This is the default look of a > windows shortcut to an executable BAT file, and they are all BAT files. > To assign different icons is an effort, and obviously nobody has judged > it important enough. Windows users have different aesthetic values as > Mac users. Weird. When I saw it, those aliases on the desktop all bore the same Hugin icon including the enblend ones. > > It also is desireable to add just the "Hugin" 'program' in Start menu > > rather than forcing users to find the "hugin.exe" 'executable file' > > from among many. > > I am not sure I understand what you mean. In Windows, the "All Programs" > entry inside the Start menu is the equivalent of the "Applications" > entry in the Mac's finder. But this is where the analogy stops. 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. > > - Autopano-SIFT: Is the warning against patent violation subtle? > > Didn't realise one being displayed. I guess it was mentioned in the > > loong license text. > > AFAIK it is displayed in the flurry of text that is outputted when > autopano-SIFT-C runs. So no approval while installation or before the autopano process happens? > > - Documents: The README and other files are installed without > > extension. How can I read those files? Who knows... That's how Windows > > works, so please take care. > > This is a regression compared to my snapshot installer. When preparing > my snapshot installers, I would *manually* convert all the README files > (Windows is CR+LF, while those in SVN are not) and add the .txt > extension. I have not thought of how to automate this in the build. > Probably it is possible, and in any case, whoever builds the installer > should indeed take care. 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? > > - Icons: First, they are unly; ... > > plenty of good and valid points. I guess many of them could be > implemented by people with enough time and motivation. I don't know much > about the technical issues of icons on the Windows platform: I consider > it generally an ugly platform, so maybe this is why I don't bother that > much about those things that seems to bother you? I know Mac users value > aesthetics more than Windows users. Well, the problem is not that Windows icons are ugly but that Hugin's ones are too much uglier than Windows norm. I hope someone would take a look. I can provide the icons for Mac in PNG (actually I have put the png icon on my homepage, which was soon after copied to Hugin's homepage and still there). Also, icons for the .pto files should be taken care. I actually couldn't spot it in the source. Is it properly displayed on Linux? 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 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". > > - Lastly, could README_JP file be attached for the Japanese users? I > > can provide converted PDF or HTML files if that's needed, though I > > remember Shift-JIS is considered default for Japanese Windows. > > that should definitely happen. When I worked through the different > readme files in deciding whether to put them into my snapshot installer > (and thus in files used to generate the installer as they are still > recorded in SVN), I tried to open the README_JP file and it displayed > gibberish. Windows is known to have problem with charsets. Other > non-Latin charsets open well on my Windows XP box. An HTML or a PDF > would surely help. Okay. I can do that. If anyone needs the converted file, please specify in what format you want the file in. However, I think the text file uses a standard encoding that most applications can handle if you specify the charset properly and display with Japanese font. > > One more thing: > > - The file downloaded from Sourceforge was compiled from SVN, hence > > appears as a release build. In future we should upload binary releases > > compiled from the source release. > > This was an issue with the CMake build, and I corrected it to the best > of my knowledge with Rev 3503. > > Before that, there was a TODO mentioned in the root level CMakeLists.txt > (actually the comment is still there): > # TODO: at each release, set current SVN revision here! > > This has not happened when the 0.7.0 tarball was released, so that > building it would call the release 0.7.0.0, which is inherently wrong, > and has further consquences on the Windows build, because unlike the > Linux (and Mac?) build extracting the SVN revision number was not > automated. I have automated that, and also the above mentioned TODO at > each release (although it would need to be tested), so that when > stripping the .svn folders from the filesystem tree that will eventually > become a tarball, everything should work automatically. Then building > from the tarball should also work effortless and as intended in Windows. That sort of makes sense. My 0.7.0 build for Mac is manually specified to build release build instead of prerelease. 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.) > 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. Ippei --~--~---------~--~----~------------~-------~--~----~ 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
