[ptx] thoughts for hugin UI, post 0.5
Pablo d'Angelo
pablo.dangelo at web.de
Sun May 29 22:43:30 BST 2005
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
More information about the ptX
mailing list