wxwindows experiments

[Juha Helminen]

 > Hi!
 >
 > I finally had the time to play a bit more with wxwindows.
 > the hugin cvs contains a src/wxwin directory with two widgets
 > that could be a base for further development:
...>
 > Whats worse than the 33% more code is the high number of macros in 
that code,
 > making debugging more painful, because many bugs won't be caught by
 > the compiler, or only with strange compiler messages.

I think that the good point is that layout is more trivial coding than 
other part of code/other functions. At start of project GUI will take 
more time than later. wxWindows seem to mean also more coding than qt as 
libraries are not as powerful as qt has. I am willing to write basic 
routines when code is reusable.

Strange compiler messages will not be problem if code do not have too 
much gimmicks or compiler dependent features.

 > My conclusion:
 >
 > I do not want to write a significant amout of GUI code with wxwindows.
 > But I also do not want to be the only developer on hugin. If there is
 > real support from other developers I will consider continue writing on
 > hugin. Otherwise I will join the wxwindows fraction, but only if the
 > following things are true:
 >
 > - no usage of the old openptgui architecture (not even at the begining)
 >   This will probably mean the Kai-Uwe's first gui port will need to be
 >   splitted into finer parts. (maybe we could use XRC (allows loading
 >   of window layouts from xml files, takes care of the layout etc.)).
 >   I propose the usage of my model classes as a starting point.

It's OK for me to use hugin model (it's C++ and PT source code cannot be 
linked in an elegant way to C++ code.)

I agree that ptbcbgui have architecture problems (more than just one). 
The mixing of C with C++ with one main frame (BCB make one big class). 
This makes it faster to write new code than try to fit old to new library.

 > - I'll write some gui code, but I mainly want to work on other
 >   functionality (for example: control point searching algorithms).

It's good to have modular layout -> different functions can be made on 
same time and merge to cvs will not be difficult. What about making 
search algorithm so that it do not need to calculate every pixel 
position... Try to find local optimum points and leave out (/no 
calculation) propably bad locations.

 > What is your timeframe with ptopengui? I have some pics sitting on
 > my hd that I want to stitch :)

I do not have timeframe when program should be ready or when to stop 
development. I'd like to see 1.0 version on some day ;)

Juha