To view parent comment, click here.
To read all comments associated with this story, please click here.
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.






Member since:
2005-07-08
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