Jeroen van der Zijp, the author of Fox Toolkit, has kindly given kerkythea.net
an interview. The Fox Toolkit is a platform independent GUI that has matured over the last years to become one of the fastest and well structured APIs.
To read all comments associated with this story, please click here.
Member since:2006-01-06
After dealing with Qt for years (my company owns the first 2 licenses ever sold), and playing with fox and fltk, well, I agree about the message mapping.
Fox's problem is that the author tried to make C++ act like objective-C. Because of that it's full of (void*) arguments and strange enumerations and macros. Then there aren constructors so huge as they're totally illegible. Enough to easily scare any folks looking for clean, elegant design. I'm also a little nervous about how tightly coupled the layout policy and the individual widgets are.
Qt (feature wise most similar) has become annoying. It's crushed itself with bloat. Sadly there's 4 or more ways to do event handling, also lots of strange behavior for any complex widgets. (my company owns the first 2 licenses ever sold by troll tech, btw). The only notable improvement of qt4 is the decoupling of the layout management and the widget creation.
fltk looks okay, but imho it's a hack job. Code rife with single letter variables, single letter function calls, etc. No serious work towards smart layout policy, which IMHO is a core feature for anything considered a modern toolkit. No gui code should require any pixel locations or pixel sizes to ever be specified for anything.
Regardless though, it's very important for developers to keep their application logic totaly separated from the display code, using some sort of logging/tracking structure that's independent of any toolkits (gui or console based) for computational management.
Edited 2007-07-13 16:14 UTC
Member since:
2006-03-20
Any self-respecting GUI developer knows that message maps are bad. I don't understand why MFC, wxWidgets and FOX violate the C++ object model by using message maps.
I have developed my own GUI toolkit for a custom application based on Win32, and I did not use any MFC-related trick: no message maps, no macros, no DECLARE_FUNKY stuff or PreCreateWindow or anything like that. The base class Window had a virtual method 'WndProc' which was used to dispatch messages to methods of the object. The class Window only provided the method 'paint' and the methods regarding mouse and keyboard events; the default handlers passed their parameters to the default window proc. Subclasses of class Window handled specific messages in the appropriate way.
The Win32 Window was created within the constructor of the widget, and destroyed upon object destruction. I used the window data trick to keep the Window object and the win32 window together: if the win32 window was created first, then the object was destroyed.