[ptx] thoughts for hugin UI, post 0.5

[douglas wilkins]

--- Rob Park <rbpark at gmail.com> wrote:
> On 5/26/05, douglas wilkins <dgswilkins at yahoo.co.uk> wrote:
> > I have to say that the interpolator setting in the output options not only
> > makes sense, but I change it on a regular basis, depending on what I am
> doing.
> > It is a part of my regular work flow.
> 
> Ok, then. I'm not sure what effect it has on the output and I've never used
> it.

The warping of the images (roll, pitch, yaw, lens distortion and projection
type) requires that an interpolation of the new pixel positions be done. The
interpolator type determines the speed and quality of this interpolation.
Take a look at 
http://photocreations.ca/interpolator/
and it's associated link


> 
> I think we should use another suggestion I made, in the preferences
> window, add tabs for nona and Ptstitcher, much like there are already
> tabs for enblend and autopano, to keep settings like that. The
> Stitcher tab itself should be as simple as possible for the layperson,
> keep all the complicated advanced stuff in a preferences window, and
> give it all sensible default values that should generally work and
> only need to be changed by advanced users.
> 
> > If on the other hand, it is not part of most users workflow, perhaps we
> should
> > think about an "advanced" portion that can be hidden/unhidden depending on
> the
> > users choice?
> 
> I don't like the idea of hiding stuff behind the "advanced" label,
> that just scares people. I think the interpolator choice would do fine
> hidden on a preferences panel somewhere.

We have to strike a balance between "simple and non-scary for users" and "Best
quality/flexibility for more experienced users". Hiding this option on the
preferences panel would be better for the former, worse for the latter.

> 
> > > But what it sounds like to me is that the two files pano_panel-2.5.xrc
> > > and nona_panel.xrc are going to have to be merged into one big happy
> > > UI layout.
> > 
> > That is going to be easier said than done :-) However, if it makes hugin
> easier
> > to use (and I don't mean less flexible) then I am all for it.
> 
> Right. I've been looking over the XRC files and although I'm having a
> fairly easy time picking up what it means (eg, I can easily look at a
> part of the code and point at what part of the UI it defines), I'm
> having a hell of a time actually editing this file. It's like a
> write-only language.

xrced, which is a graphical interface for writing these (and part of the
wxWidgets distribution) help a lot. There are also tools like wxGlade
(http://wxglade.sf.net) which can be used. I prefer xrced personally because
although it is slightly trickier to use, it is more flexible in my opinion.

> 
> i'm starting to have feelings that we should throw out hugin (or at
> least all the GUI parts of it, and try to salvage the internal code
> that does all the real work), and start over in wxPython.

I have to say- that option fills me with horror for reasons that I cannot
clearly explain without thinking it through :-)
One thing does come to mind immediately - wxPython uses exactly the same widget
set as we use right now. I am not sure what we would gain from switching. It is
clear though that there are deficiencies in wx and Pablo and I have discussed
other options for post 0.5. It all comes down to deciding when the pain of
changing to another UI outweighs the pain of all the problems.

> 
> > My attitude is:
> > If I can't justify why the layout is like this, then perhaps it needs to
> change
> > :-)
> 
> Sounds reasonable. I'm just having difficulty making the jump from
> "good idea" to actually making the change in the code.

That is indeed the difficult part. A clear picture of where we want to go is a
very good first step though.

regards,
Doug




	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com