OSNews

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

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