[ptx] thoughts for hugin UI, post 0.5

[Rob Park]

On 5/27/05, douglas wilkins <dgswilkins at yahoo.co.uk> wrote:
> 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

Sorry, I know (at a high level) what interpolation _is_ (from scaling
images with GIMP), what I meant is that I'm not sure what effect
changing it would actually have on the output.

> > 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.

True.

> 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.

Yeah, I know about xrced and wxglade already. The problem is that
we've got a dozen emails going back and forth and we're answering them
in the  wrong order so we keep repeating ourselves about what to do,
etc.

> > 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 :-)

I understand completely, it's your baby, you don't want to kill it.
But I'm having a difficult time getting into the hugin source, the
redundancy of XRC is _incredible_ (WAY above and beyond the built-in
redundancy of XML itself).

> 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.

I know it does. The reason I suggested wxPython is that I've seen a
few projects implement it successfully (see bittorrent), and Python is
a very nice language. But the hugin implementation in C with wxWidgets
seems to just be a mess.

What I'm suggesting is that you extract things like nona, make them
standalone applications, keep them written in whatever language they
currently are (I assume it's all in C), and then just throw out all
the GUI stuff, and start over in something really nice and simple like
wxPython. The wxPython wouldn't be a total rewrite from scratch, it'd
just be a frontend for the existing tools.

Besides, I think extracting nona into an external program would add a
lot of modularity and orthogonality (in the same way that enblend is
an external program). We could even develop multiple frontends to
serve different purposes.

> 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.

I'm not sure exactly that it's wx that's deficient, it seems like a
nice easy way to do cross-platform applications... it's this XRC stuff
that's really bothering me. It seems like EVERY single widget needs to
be wrapped in a "sizeritem", and then each sizer item is given the
same 5px padding and told to align the widget in the middle both
horizontally and vertically. So you've got code like this:

            <flag>wxALL|wxALIGN_CENTRE_VERTICAL</flag>
            <border>5</border>

Repeated 18 times in one XRC file (in fact this is repeated 360 times
across all the XRC files that hugin uses). WHY!?

-- 
Urban Artography
http://artography.ath.cx