My first hugin trial

[HaJo Schatz]

Kai-Uwe,

> Yes xrc need some special efforts. We hope it goes in the standard compile
> of wxWindows once.

Maybe a short pointer in the INSTALL file under requirements (such as
"xrc is required. As of wxWindows 2.4, xrc can be found in the wxWindows
contrib-directory") would help. I've spent most time finding xrc &
accidentally trying to install xrcEd instead ;)

> 
> > - In the Images tab, it's a bit annoying that the preview changes with
> > 'MouseOver'. While this appears neat at first, it's difficult to select
> > a pic, move the mouse to the preview window (without hitting another
> > pic) and changing the parameters. Maybe once the mouse is out of the
> > file listing, the preview should switch back to the selected pic? Or,
> > the traditional way, the preview only changes once the list entry is
> > clicked on.
> 
> You have multi selection in this tab as in the second. Now what to do?
> Changing back to one selected pic is not more meaningfull as let the last
> mouse-over pic staying. The only thing I can imagine is to switch to the
> preview after leaving the list. (Better would be larger icons. If someone
> else says so, we should change.)

Let me describe in detail at an example: I am loading say 4 images
covering a 360deg pano. Now I want to do a first, rough input of the
params. I click on the second image, enter 90deg, click on the 3rd
image, enter 180degs, select the 4th and enter 270deg. When doing this
quickly, I will certainly see the wrong preview on the right -- which
can become quite confusing. On top, I think, the parameters at the
bottom right do then not correspond to the preview on the top. I think
from a ergonomic point of view, this shouldn't be the case, it adds
confusion to the process.

Larger icons might not really fix the problem, as people traditionally
(that's how 99% of all the GUIs out there are written) expect to move
around with the mouse freely without "destroying" anything. I think
generally state changes based on "mouse-over" make sense if there is
only viewing involved, not editing of any sort (which requires the mouse
to go somewhere else to do the editing).

> > I believe an "OnCursorExit" (or whatever the event is called) should
> > commit the changes, an <ESC> in the field should put the original value
> > back into the field.
> 
> I have an other feeling of that. An hugin user is allowed to make a mouse
> move without going in the process. She/he should express his will to go
> further (IMO).

That's probably the same issue as above. I would possibly agree to you
if I would use Hugin full-time and barely use any other application out
there. But the reality is for me (and I guess for many others) that
Hugin contributes to maybe 3% of my computer-work. This means I got used
to a certain way a GUI is expected to behave, and I expect this
behaviour from all the programs I use. Like a colleague of mine ( a GUI
developer for embedded devices) once said: "If I have to adopt to a GUI
rather than the other way round, I am definitely refusing to use it, no
matter how powerful the underlying program". Obvious, but easy to forget
;)


> > I haven't tried too much, as especially the control-point crashes are
> > happening a bit too often for me to really go through it very
> > thoroughly. For me, implementation of "Save/Load project" would be very
> > beneficial to "jump over these crashes" and not start from scratch.
> 
> Sometimes I think we can do the hard way and improve hugin till saveing is
> not needed at all *g*. You may laugh as well ;-)

Indeed LOL! In that case, I'm just not sure whether I would want to be a
serious beta-tester ;)

Again, all thumbs up!

HaJo