wxwindows experiments

[Pablo d'Angelo]

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: 

CPImageCtrl (displays an image, and allows point modification/creation) 
CPEditor (is supposed to coordinate two CPImage controls, no real
          functionality yet, but it can receive the custom events
	  from CPImageCtrl)

the Control Point stuff is probably one of the more complex parts, so it
was probably a good test to start with it. I can imagine that creating
the other dialogs is easier because most of them can use existing
widgets. 

CPImageCtrl has the same functionality as its QT pendant: CPImageDisplay

I found that the wxwindows interface not as comfortable to use,
especially the sizers still do not work like I wanted them to.

wxwindows uses macros to work around missing functionaltiy in C++,
this can sometimes be a real pain to find errors due to incorrect
macro usage (I spend 4 hours on hunting a bug (CPImageCtrl's scrollbars
were not updated), the problems was that I forgot to change

BEGIN_EVENT_TABLE(CPImageCtrl, wxWindow)
to
BEGIN_EVENT_TABLE(CPImageCtrl, wxScrolledWindow)
when I made CPImageCtrl inherit from wxScrolledWindow instead of
wxWindow.

The custom event that reports point changes / region selection
is also a feast for macro lovers (which I'm not...) 

if one lookes at the file sizes:

wxwin:
island.wh-wurm.uni-ulm.de$ ls -al CPImageCtrl.*
-rw-r--r--    1 pablo    pablo       12773 2003-05-18 17:32 CPImageCtrl.cpp
-rw-r--r--    1 pablo    pablo        6703 2003-05-18 17:32 CPImageCtrl.h

qt:
island.wh-wurm.uni-ulm.de$ ls -al CPImageDisplay.*
-rw-r--r--    1 pablo    pablo        8744 2003-05-12 19:44 CPImageDisplay.cpp
-rw-r--r--    1 pablo    pablo        5899 2003-05-16 10:23 CPImageDisplay.h

one can see that the wxwin implementation needs 33 % more code than the
qt implementation. The main effect for this is the complicated event
definition in wxwin. And the qt signal/slot thing is even more
flexible than the wxwin event system.

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.


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.

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

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

ciao
  Pablo
--
http://wurm.wohnheim.uni-ulm.de/~redman/
Please use PGP