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.
Interview with Jeroen van der Zijp of FOX
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The link site is about an interesting program which seems to be for OpenGL scene lighting.
The toolkit itself seems to be LGPL, have a bunch of toolkit/scripting bindings (Rexx, python…) http://www.fox-toolkit.org/goals.html
So while not beating out MUI (lots of visual grayspace here, folks) it does seem to have a nice olive branch built in for hosted OpenGL windows! Was not this the year laptops were to have built-in tablets with angle-and-torque-sensing for compatibility with the high-touch cellphone I/O sensibilities? Oh well.
Didn’t see Rexx, but Ruby, Python and Eiffel seem to be supported. Adie looks like quite a nice editor. Xfe is built with it, and that’s a pretty decent testimonial. Maybe Fltk with Python might be an alternative?
Coming at it from the other direction, the number of decent seeming fast light gui kits for Python is amazing.
By looking at the sreenshots, it looks like the widgets are drawn by the toolkit. It doesn’t seem to use native widgets (at least under Windows). Am I right? Am I wrong?
rx182: I think you’re right. I think Fox looks ugly, but I guess in some cases native look and feel isn’t necessary.
I think inconsistent (with the rest of the OS) would be a better world
But not only that. Non-native widgets are always much slower than native ones.
Anyway, while I prefer other toolkits over FOX, I admire the amount of work the author has done. Keep it going!
You are right. I looked at the source code and verified it.
And you got this info where? This is completely untrue. Under Windows the “native controls” are implemented in user mode (well, except some hacks, but they’re not for improving performance) using the very same API that the makers of non-native controls use. Even though I have little experience with other operating systems I know that the common toolkits on Linux all use X11 APIs under the hood and so can do another toolkit. So why exactly would the non-native controls be slower when they can use the same underlying API?! (Of course, they might be poorly implemented, but you said “always”.)
To me the disadvantage of non-native controls is that they usually don’t fit with the rest of the environment. No matter how much you try to imitate the look and feel of the platform you’re doomed to fail, because new version of the platform can be advanced somehow (themes, spell checking, IME or other such feature) and your custom controls won’t reflect that.
Edited 2007-07-13 13:13
To me the disadvantage of non-native controls is that they usually don’t fit with the rest of the environment. No matter how much you try to imitate the look and feel of the platform you’re doomed to fail, because new version of the platform can be advanced somehow (themes, spell checking, IME or other such feature) and your custom controls won’t reflect that.
While there is a lot of truth in your statement, I do not see it as critical. Note that even MS is using non-native widgets in almost any application (e.g. MS Office) and nobody really complains.
Theming APIs are now good enough to integrate non-native widgets in a way that you will not notice uless you are looking very carefuly (e.g. like GUI Toolkit author trying to do this right :-).
Qt, U++, OpenOffice, Firefox all are using this approach and I have not noticed people complaining about e.g. Firefox appearance in Win32 or Linux…
Edited 2007-07-13 15:59
I do complain, but I guess my voice is lost in the outcry.
I’m the first one to complain that MS itself breaks their own GUI guidelines. Unfortunately that makes other corporations follow the trend and do the same (at least from my experience as software developer).
In a risk of getting a bit off-topic I recommend taking a few seconds to read http://blogs.msdn.com/oldnewthing/archive/2004/07/28/199589.aspx (Edited: Don’t miss the discussion …
I perfectly agree on this. My point though was that you can imitate the controls now (with themes and stuff), but you can’t imitate how will they behave in the next Windows release (or another platform for that matter).
Yay, very true, these are the few cases where the imitation of the native controls is almost perfect and most importantly it’s *maintained* and *updated*.
Example of the other kind could be Firefox 2.x on MacOS X where some key behavior is different from the native controls and people used to “the standard” notice it.
Overall you make a good point, so you deserve a (moderation) point from me too
Edited 2007-07-13 22:24
You’re right. However, most toolkits that I used that didn’t use native controls were slow for a reason or another. Swing, for example, is slow because it does all the drawing in Java* (correct me if I’m wrong). GTK on Windows is slow** too. The design of GTK doesn’t work very well with the Windows api.
And to respond to the other guy that complained about message maps, I must say that I agree with him technically speaking. However, pratically, message maps make sense. Object-oriented toolkits that don’t depend on message maps usually rely on vtables. The problem with vtables is that they slow.
*I’m not saying that Java is slow but GUI drawing is really intensive work.
**GTK on Windows is slow as in “slower than native win32 applications”. It’s not too slow however. It’s still usable.
I’d still rather have Swing that AWT!
“I think inconsistent (with the rest of the OS) would be a better world
“
Don’t confuse OS and GUI.
Famous quotation: “I don’t like the Linux file systems – the pictures are too big!” (The term “pictures” refers to icons.)
Inconsistency usually does not matter to the end user. While you may judge from an aesthetic point of view, look & feel usually is very user dependant. Look at Mac OS X, at all these “Windows”, at the various Linux and UNIX GUIs and desktops. Users keep using them, even if some applications use others than the “standard” toolkits or violate the “standard” way of doing things withing a particular system.
“Anyway, while I prefer other toolkits over FOX, I admire the amount of work the author has done. Keep it going!”
Personally, I find FOX with its bindings interesting, but actually won’t use it because I prefer Gtk + C, or GNUstep + ObjC. Surely, FOX may be a good solution for ressource limited systems. Especially the cross-platform sector is interesting if you don’t want to use Java and do only consider UNIX/Linux and “Windows” (allthough Mac OS X variants are possible, too).
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.
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
I wish they had built Gnome on it. GTK seems such a dead end API-wise.
What do they mean by “… one of the fastest and well structured APIs.”? It’s not explained in the article, so I assume someone from OSAlert added it.
Clearly an API cannot be fast? Does it refer to widget rendering speed? Or that the Fox Toolkit code is fast in general? Or how long it takes to develop an application with it? Or how long it took the author to create it? …
The concept of a fast API sounds interesting, although I can’t really imagine what the term would mean. Can anyone give a hint?
Thanks,
Detlef
It means the rendering and “feel” of the guis built with fox are fast. Has nothing to do with the time to prototype. Although it is a pretty powerful toolkit, feature wise on par with Qt without the MVC stuff Qt4 brought to the table.
Aside from some of the irritating design and implementation decisions it’s not a bad toolkit. And it doesn’t take a lot to get up to speed with it, either.
Edited 2007-07-13 23:42 UTC
Ah, thanks for clarifying this.
Hey all-
Being a newbie to programming, I have recently begun writing programs in Ruby for my job (dosing calculators et cetera) but having problems determining which GUI toolkit to start learning to make my programs “pretty” for my users.
I have seen a number of comparisons of various possible toolkits all over the web by googling Ruby + GUI but the reviews are all over 1 to 2 years old. I was looking for something a bit more current and glad to read the article regarding FOX.
That being said, the article doesnt really help me in my decision (I was hoping against hope that it would). Most of the sites that compare FOX say it is nice but not mature; that it’s not using native widgets makes it look bad but that it has potential.
Anyone have a similar experience that was a bit disappointed with this article?