GUI re-write (Was: Re: [ptx] thoughts for hugin UI, post 0.5)

[douglas wilkins]

--- Rob Park <rbpark at gmail.com> wrote:
[snip]
> > > 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.

Not mine - Pablo's :-)
But that aside, there are a couple of (I think) good reasons not to want to
re-write the UI in wxPython:
1. There is a lot of interaction between the UI and the internals for a project
like this, especially in the control points editor. Using two languages with
the associated difficulties of cross language calls could be detrimental.
2. The difficulties of running a debugger on the code when wxPython and C++ is
involved. There are a number of Python/wxPython debuggers available and
obviously a number of C++ debuggers, but no debugger I know of can trace from
python into c++ and back again.
3. I know that my python knowledge is woefully inadequate for the job. :-)
Perhaps the other developers would be comfortable in python, but I don't know
if this is the case.
 
> 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).

The hugin source is a bit opaque untill you really start looking hard at it.
Pablo has already discussed steps post 0.5 to try and fix this. 

As far as the redundancy of XRC files is concerned, this is not something I can
fix. We are working within a framework defined by the wxWidgets project which
uses "sizers" rather than explicitly defining the layout. Perhaps
http://www.wxwidgets.org/manuals/2.6.0/wx_sizeroverview.html#sizeroverview
and
http://www.wxwidgets.org/manuals/2.6.0/wx_xrcoverview.html#xrcoverview
may help

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

C++ actually

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

Nona already is a standalone application.

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

Not having designed wxWidgets and XRC I don't know :-/ 

Some of the GUI designers though (wxGlade and DialogBlocks come to mind) do
allow you to specify these as default parameters so you don't have to think
about them.

regards,
Doug



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