[ptx] thoughts for hugin UI, post 0.5

[Pablo d'Angelo]

Hi all,

Rob Park wrote:

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

Well, I have written the major part of hugin and it was my first big GUI 
project. I have used QT before wxWindows (actually, the first hugin 
prototype was written using QT), but I switched, because I could not use 
the free QT version on windows (due to the lack of a Microsoft compiler 
at that time). This was a step I deeply regret.. However, it has been 
taken 2 years ago.

I'm not sure about your software development background, but as Doug has 
noticed before the devil of GUI development (espcially when done cross 
platform and multi lingual) lays in the details. I have also learned 
that the painful way. In the end, one needs to use workaround and even 
more workarounds to get stuff work consistently, until the code starts 
to look ugly, and needs to be redesigned, which will take even more 
time. Hugin surely has some design flaws, and it is lacking a nice 
document about its internal structure and some design decisions.

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

Having used wxWidgets (which is the underlying system of wxPython), will 
lead to many ugly things in the code, no matter if C++ or python is 
used. I won't support switching to a wx based system.

I haven't looked at the bittorrent client, but I believe a panoramic 
editor is much more complex than a frontend for a file downloading 
application.

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

Nona is already available as an external program... People can use it 
from their own frontends.. Its just that no other opensource frontends 
are available.

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

Urgh... sorry... it is not, I have learned that in the last 2 years.

There are many, many small platform dependent differences, that are not 
visible by reading the documentation. To me the core problem is that on 
each platform wxWidgets uses the native widget sets, and the different 
design decisions, features and bugs of the native toolkits are not 
shielded completely from the programmer.

Things like small example dialog boxes work reasonably well and can be 
implemented with a simple code.

Compared to these problems, the XRC stuff is actually quite nice.
XRC is just another way to avoid writing thousands of lines of code that 
generate the widgets by hand. However, it doesn't change the design and 
usability problems wxWidgets has, its just makes it easier to specify 
the structure of the GUI.

Actually I like the tree structure of the XRC files, and the way they 
are edited for example from within XRCed. A lot nicer than drawing 
widgets onto a canvas, because the underlying structure is immediately 
visible, and one is not tempted to use fixed sizes for widgets etc.
In case of XRC I'm just unhappy with the implementation, not with the 
concept itself.

 > 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!?

Because you have to specify the properties of the widgets. Maybe there 
are nicer ways to handle defaults for other widget systems. A good 
layout algorithm is needed. The its implementation and usage in wx is 
just more clumsy than with in other toolkits. However having the stuff 
inside the XRC files that are editable with another program like XRCed 
is nicer than hardcoding everything by hand. If you code everything by 
hand, you will have to hardcode all the flags and stuff into your 
program (no matter if it is written in python or C++).

The funny thing about XRCed is that it doesn't use XRC for its own GUI. 
This leads me to the question: Does that mean that the people developing 
XRCed do not believe in XRC themself? ;)

I believe you have just discovered that writing GUI's is not as nice as 
using them :-(

I hope you don't take this as a personal attack. I'm as unhappy as you 
are with the current situation.

Additinally I really would like to work on adding real features (in 
terms of functionality directly related to panoramic image creation), 
than on the GUI programing.
So I'm quite happy that people are discussing GUI improvements. However, 
after 0.5 I personally want to work on the interesting stuff, like 
development of a memory efficient remapper, morphing support and some 
code cleanup related to core logic.

I would be even more happy if some people with more GUI design and code 
skills than myself would help to improve the GUI code. If many people 
are unhappy with wxWidgets and the current usage of it in hugin, I'm not 
at all against a rewrite of the GUI, but I won't take a leading part in it.

But one has to think very carefully about it, and try out several 
alternatives (by actually writing code with it, not just by reading the 
documentation !!!). That example code should contain major parts of 
central stuff like the control point editor and some complex dialog 
code, like the Pano panel as well as interfacing with fast, C/C++ based 
routines for preview.

I believe that is the only right way to choose a toolkit/language for a 
complex application like hugin.

ciao
   Pablo