Slashdot Mirror
Cross-Platform GUI Toolkits (Again)?
Futurepower(R) queries: "It has been 2 1/2 years since the previous Ask
Slashdot about GUI Toolkits. There were many helpful comments then, such
as this
one. Since then, Slashdot has discussed wxWindows vs. MFC and considered the book, Creating Applications with Mozilla. The best comparison table is
apparently still the GUI Toolkit,
Framework Page. Which is the best cross-platform GUI toolkit that provides
native look and feel? Which is the best overall? What IDEs and other tools do
you use? What are the problems?" Slashdot also had a match-up between GTK+ and Qt, but some of you might have missed that one. How have recent changes in this ballpark changed your feelings on the issue?
The Fast Lightning Tool Kit is very nice. I've used it on Sun OS, Linux and Windows. Compiles between platforms without much change to the source at all...mostly its the system calls that needs to be changed, nothing related to the GUI.
I personally think that Cocoa and GNUstep deserve to be mentioned among the best-designed toolkits around. Both follow the OpenStep guidelines rather closely, and the OpenStep guidelines are very well-documented on Apple's site.
GNUstep is also quite portable -- I have used it on three or four platforms, and have no doubt that others work great. My only complaint about GNUstep is its idiosyncratic build system, but I believe that's a left-over from NeXTSTEP, the precursor to OpenStep.
If you're interested in learning more about Cocoa and other OpenStep-compliant toolkits, check Apple's developer site and the Hillegass book, published by AW.
unixkb.com -- articles on practical Unix issues.
Swing is functional and cross-platform, free-beer, and widely understood.
I have discovered a wonderful
Nice and portable and reasonably consistent feel and appearance.
And for those who like to use it in a scripting environment, use it as is. Use it with Perl, C, C++, etc...
I stick to walls...
If your looking to Java for cross-platform development and cli is not your thing, Eclipse is a nice IDE that works nicely on windows and linux. Its also open source.
If you're talking about true cross-platform compatibility, combined with ease of development and deployment, then Tcl can't be beat. It's always been good, but recent developments, such as the Starkitpackaging and runtime system, make it a hands-down winner.
It is hard to admit it, but when the mono team gets windows forms working correctly, C# and .NET are going to pick up a great deal of momentum, specially in the cross-platform GUI development area.
Okay, I'll bring it up now: IBM's SWT is great. I've been using Eclipse lately under gnome2 and it's wonderful. Nice native look and feel (great anti-aliased fonts) and very responsive.
If you don't know, Standard Widget Toolkit (SWT) is a java GUI framework that uses JNI to call the native OS windowing API. It's an excellent example of how java can successfully be used for client desktop applications. IBM developed it for the open source Eclipse IDE.
Who said Freedom was Fair?
I like wxWindows and especially it's a child project wxPython. wxPython is my favorite way to develop GUI apps because it is easy, flexible, cross-platform, and looks great. My only major wish for it is a Java port so Python/wxPython programs could be made portable to Jython. :)
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
At my new employment I had a project that needed to be cross platform. I was itching to use Kylix, however it wasn't due to be finished for another 8 months. Looking into the details I saw that they built the corss platform support on QT.
After checking out the QT tutorials I was immediatly hooked. QT is intuitive; I can't think of many other APIs I would grace with this description. In addition to being well thought out it has a superb implementation. I've been using it happily for 2 years.
The only thing I miss is the strong third party component community that Delphi/Kylix has. I'm a huge fan of "buy don't build". You can really put quality touches on your app by finding the right component someone else has already made.
-R
available with Eiffel Software's EiffelStudio development suite. It's called Vision2 and provides platform independent look and feel by using a bridge pattern to separate an interface layer from the underlying implementation layer (which uses the Win32 API and Gtk+ for the platform dependent stuff).
You can download the full EiffelStudio suite for linux (and Windows) and use it free for non-commercial software, Vision2 is included and is available here, it's free!
-- You see what happens when you have fun with a stranger in the Alps?
For the kind of GUI-I-Wanna-Slap-Atop-A-Database, I like to use Tcl/Tk. Works great for programs where you just want to have something quick, rapidly prototyped AND cross platform.
If you really want a well orchestrated OO GUI toolkit (with the exception of some nasty hacks), QT is a great thing to couple with C++. I know there are many out there that cry foul at the MOC. For the uninitiated, QT uses a macro processor to add a few keywords to C++ for their Observer(or Publish/Subscribe) pattern. I feel that these extensions are minor, and do not significantly detriment the portability of the code. That is, unless you are insane and derive EVERYTHING from QObject - then you are going to be heavily dependent on QT. In a well abstracted interface, your main code tree shouldn't contain much, if any, GUI code.
I have a lot of respect for GTK+, but it just isn't for *me*. GTK programs do generally feel a little more responsive on slower hardware, and are generally lighter weight (being mostly pure C), but the question seems to revolve more around cross platform programs, and GTK doesn't seem to integrate very naturally with the other platforms - at least not the programs that I have seen.
The author has spent a lot of time looking at existing UI libraries and tried to learn from them before writing his own.
See the website for more info.
Eclipse does have a few glitches in the Linux version.
For those that don't know, Eclipse is based on a unique IBM GUI toolkit called SWT. It has a Java API, but the underlying code is native. The supposed advantage of this is that it can be used by any Java programmer as an alternative to Swing, but it's faster. The problem is that it's only available for Windows and Linux, and since the underlying code is native, it has to be separately developed and maintained. Since more GUI apps are run on Windows, there's more pressure to make the Windows code work right, and the Linux code is always a little behind.
I don't think there's any advantage to SWT these days, with Swing programming coming along so well. For anyone who doubts this, have a look at IntelliJ Idea, a really nice Java IDE that's Swing-based, and super fast. Frankly, I think Eclipse and SWT was a move to establish an IBM-centric Java community, with lots of vendor lock-in. Hijacking Java from Sun, if you will.
Eclipse *is* a really nice application, but I don't think IBM's motives in creating it were at all community-minded. And I don't have high regard, or high hopes, for SWT.
Trolltech's QT costs $1550 each, per developer, for commercial use on Windows and Mac.
QT versus Java (PDF file)
QT versus MFC, in English (See the French below.)
QT versus MFC, in French (MFC contre Qt)
It looks like Qt does native widgets everywhere. I haven't coded with it, but source compatibility bewteen Windows, OS X, X11, and Qt/Embedded seems pretty promising. But personally, I'm still using the tried and true cross platform GUI toolkit known as HTML :)
__
Choose mnemonic identifiers. If you can't remember what mnemonic means, you've got a problem. - Larry Wall
I myself would favour Swing over others, though I'm really only fully conversant with MFC. But I fully realise that it depends what you're doing.
If you're building a mass-market app you plan to sell you all of the great unwashed out there, then you probably need to make it look very Windows-centric. Practically speaking, something like a turbo tax is probably going to get 99% of its revenue from Windows users. Its crazy to use anything - like Swing - that doesn't give you the best, most up-to-date look on Windows (though Sun would claim it is native look and feel). Use MFC or something like that.
If on the other hand you're building something like an IDE, other factors come into play. The fact that your app runs on linux as well as Windows will probably be a key sales point to your target audience. And your app is probably far more complex than a mass market app - meaning you need good productivity and a strong underlying architecture(which, IMHO, Swing gives you). Your users are likely to care less about the memory requirements of a technology like Swing.
Or as a final example, if you're writing a game, then screw their sheety GUI ! Code everything yourself from lines, dots, and mouse events. Make your list boxes scrollable using human skulls as thumbtabs, have rats running up and down inside your text fields to show focus. (personally I would also use Swing for this but realise that may be straying into personal predjudice).
In summary, its no good saying "whats best". It depends on what you're coding.
[x] auto-moderate all posts by this user as insightful
Hmm... ya, you're right. I remember the days when word processors and 3D modeling applications were all written in HTML and javascript for all to use... fucking microsoft...
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
on PyQT:
http://www.opendocspublishing.com/pyqt/
Python: cross platform
QT: cross platform, native-working widgets.
QT, however, isn't free for commercial use.
S
And these are just my biggest objectsions. The Tk widget set is not bad. It is quite ugly and limited, but good enough for a small GUI app. The underlying language though is absolute crap.
The only good thing about Tcl is that it provides a (relatively) easy way of interfacing with C code: you can expose C functions as Tcl commands (e.g. you could map Tcl command foobar to C function MyFooBar()). This is, in fact, what Tool Control Language was designed for: exposing C functions to a high-level script to facilitate easy automated testing. However, trying to write a real application in Tcl is an excercise in futility. There are much better alternatives available. But, if all you have is a hammer, everyting looks like a nail -- that is why Tcl is the "past and future king".
___
If you think big enough, you'll never have to do it.
Except when you introduce "themes" a la 99% of X users or more and more Windows users (as XP is adopted). This renders Swing more or less useless if you want the application to blend in to the rest of the windowing system.
Additionally, Swing is still all tied up in The Way You Code It. We have an application that uses Swing but we have to force it to use the Metal/Steel/whatever-it's-called look-and-feel because we had expanded the widget set to do various other things that just Didn't Work when they were in the Windows look-and-feel. This is the reason why i coded it in AWT first, because it was supposed to run on Windows, but because Sun never fixed the bugs (i think there are still plenty in their bug database i entered that are still open or ignored) we had to convert to Swing... and now we have a weird-looking app for both Windows and X users.
One of the KEY problems in GUI development that i see is fonts. Fonts are fucked up and all different between the windowing systems, and this was precisely the reason why we needed to implement our own widgets in Java. The names of fonts are different, the sizes they are are different, the way they're rendered is different... Yuck. We ended up having to make a flakey, probably illegal font pack for Linux, made up out of MS fonts, just to use Linux as our development platform, and even then they didn't render exactly the same (especially when we needed a widget to be a specific fixed width). From what i understand, MacOS does it different all over again. This is even a problem in supposedly cross-platform HTML too. Fonts just suck.
I could go on forever about this, about how GTK applications look like shit under Windows (they don't "refresh" or "paint" properly for starters), most every client app written in Java that's more complex than a JDBC form looks weird under Windows, ugh. I think the original poster is conceptually correct in what he was saying. Unless MacOS, X and Windows all start using a common method to implement themes and font rendering, cross-platform GUI development is going to continue to be utter hell.
I got a sig so you would remember me.
After using Qt for a couple of years, for both open source and commercial software, I can say it does the job admirably. It is easy to pick up, and using it is fun :)
Qt is not necessarily only for GUI. There are lots of convenience classes available to make your life easier doing cross-platform work: Text/Unicode handling, image, containers, networking, database, XML, etc. Many of these classes are highly optimized. I use Qt even when I'm writing a console app.
Though I have not used Java, I am told the API is very similar in style (to Swing?). The upside to Qt is that it is compiled and uses C++, so it is fast and you can mix and match system code. A common myth about cross-platform software is that you must cater to the lowest common denominator, which is absolutely not true with Qt.
Even if you are doing development for a single platform, you may still want to use Qt. It is generally easier to use than whatever is native (though I have heard very good things about Cocoa/ObjC), and it secures you that 'out' in case you want to port later.
For some examples of cross-platform projects using Qt, see Opera and Psi.
The low-level Windows API solution is the each object has a window handle and the interface that goes with that -- a WinProc. That means every window object has to expose the same, complex interface with a zillion Windows messages to every other window object it can come in contact with. This leads to (what some people) consider ugly -- the Giant Switch Statement in C implementations or those even uglier message map macros for C++ MFC (I believe wxWindows uses message maps too).
The Grand Quest is some simple mechanism for making direct signalling connections between objects without breaking encapsulation -- exposing the inner workings of every object to every other object: kind of like how to be on the Internet and disclosing your e-mail address without losing your privacy or worse.
The solution is to create some bridge class -- a courier with a personal knowledge of the recipient but a courier which publishes only a very generic interface to those seeking to contact the recipient. In Delphi that courier is an event type, in Java, it is an inner class with an ActionListener interface, in C# it is a delegate.
Qt has this mechanism called signals and slots, and to pull it off they had to extend the C++ language with this macro processor called MOC, and this has the BVDs bunched of C++ purists because they are in effect extending the language.
As someone who writes SWT and eclipse apps for a living, I can say quite definitively that if you're aligning your widgets based on assumptions about pixels and whatnot you are in fact a moron. Microsoft won't let you use their logos with any app that does this either; they know that when Microsoft Windows 2008 comes out they might drastically change what your Win32/MFC calls produce on the screen and they want you assuming as little as possible. No professional programmer hacks it until it works, and if they do, it's certainly no more SWT's fault that it is GTK's fault when someone in a right-to-left language finds out how you didn't stick to the recommended methods.
Layout in SWT can be done any number of elegant cross-platform ways and only as an absolute last resort should you ever have to use absolute pixel amounts. And don't think this is just a cross-platform issue -- people who jack their font sizes for certain widgets up (namely, me) but not others find improperly laid out controls very very quickly. I can vouch that Eclipse in fact does not have much of this if at all. Typically, if you're coding this way, you need to go back to Layout Managers 101.
What did you eat today? http://www.atetoday.com/
First, a shameless plug: I'm working on a couple of C++ applications that are currently using FOX for the GUI (and other parts). The first one is a front end to the open source stats language R and it is called Obversive. This is the most active project, but it is still real tiny. The second project is a little chat client I'm writing called Bombyx which will work on the SILC and hopefully IRC. In addition to Bombyx, I've also developed a little GUI generator with Lua that makes FOX widgets pretty quickly. It's called GIG and you can get it from the Bombyx site mentioned previously. The intention with GIG is to make it work for any toolkit, but right now it does FOX only.
When I was working on these projects, I went through a huge number of toolkits and actually tried developing fast "mock-ups". My test was to see if I could get the first window I wanted in each project using available resources. If that worked, then I would try a couple of other windows. I also reviewed the designs of each and then went with what worked best at the time.
Here's my review of each of the toolkits I used. These are just my opinions, but they are based on actually using them in various platforms (or trying to).
FOX After all of this evaluation, I found that FOX was pretty much the best at the moment for clean, simple GUI building. It has pretty good docs (way better than wxWindows), and is fairly natural for coding. It also has some nice language bindings for various languages like Python, Ruby, and Eiffel. It doesn't have quite as many controls as wxWindows, and it doesn't work natively on as many platforms, but it is much easier to build and work with and much smaller. If you are porting a Windows application to another platform, you will probably be better off with wxWindows since they try to mimick the API design as much as possible (and of course, all it's problems too). Also, if you hate macros then you'll have a problem with FOX (and wxWindows too). A testimony to how easy FOX is comes from Obversive, where one developer had no C++ or FOX experience and has already created several complicated controls. Another developer has good C++ skills, but only worked with KDE previously. He not only developed an excellent Twin Table control, but also added lots of great features to it and in very little time.
FLTK I did the original work on Bombyx with FLTK. FLTK is a nice library, but it was just missing too many widgets to be useful. It was also rather buggy and it was a real pain to do delegation. There are, however, two really nice things about FLTK: no macros, excellent GUI builder. One of huge problems with ALL other toolkits I've ran into is that, when the developers start to make their GUI builder, the decide they need an entire IDE. I already have one thank you. I doubt some OSS project is really going to out-do my tool chain right now, especially if it's also working on the widgets. Just give me a simple builder please. FLTK got it right with FLUID--their GUI builder. It's real easy to use, super fast, and does one thing well: build interfaces. It was a little weird at times, but I checked out the latest and it worked great. Also, FLTK does not use macros for messaging which is nice for the C++ purists.
Cocoa I love Cocoa, but, Apple made a huge mistake by making it a MacOSX only beast. I think Apple could rule the world if I could spend my time writing my apps with a nice UI, great tools, and an easy language (Objective-C), and then click a button and have a Windows, Linux, HP-UX, and Solaris binary. You could do this with the original NeXT stuff, but Apple crippled Cocoa and friends. So, I reserve Cocoa for other useless programming that I only do on my MacOSX. There is GNUstep, but I couldn't get anything to work with it, and half the fun of Cocoa development is using Interface Builder (IB). BTW, IB is another GUI builder that is excellent, and also does just GUI building. Let's hope the wxWindows guys figure out this pattern and write a small GUI builder rather than their entire IDE which nobody seems to be able to compile but three dudes inside the cabal (sorry, it really burns me).
wxWindows I must say that wxWindows has a ton of nice widgets (I may steal their HTML widget) and works on a huge number of platforms. But, I kept getting burned in three areas: docs, dependencies, and bugs. Their docs are horrible. You have to hunt around the net looking for tutorials which are not very good anyway. Half the example applications in the distro don't even work so you can't rely on them, and it's just really hard to figure out what to do. I also hated having to add a billion other libraries to my build just to get wxWindows to work. I found it a problem when linking my application took longer than compiling all the files from scratch. Finally, just about everytime I went to use some widget, I found some bug or limitation that made it unusable. They have improved quite a lot from what I have heard, and people really rave about it, so I think everyone should give it a try. One thing also that annoyed me about wxWindows is that it does not support delegation very well. All the other toolkits I used either support delegation easily or practically require it. In wxWindows, I spent the better part of a week just trying to get one simple delegation design working and couldn't do it despite lots of help from people on various IRC channels. To me, things are broken if I have to subclass every time I want a widget. The wxWindows XML based resource files are supposed to fix this, but I won't hold my breath.
JFC/Swing The original version of Obversive was done in Swing with lots of other goodies. Java is my primary work language, and I really wanted to use it on the Obversive project, but we just kept running into performance problems. Frankly, Swing is just a P.I.G. and is really hard to code. None of the GUI builders available we tried proved to be that useful, and eventually we dropped it becuase it was just too huge. Ironically, we were able to prototype an almost complete GUI using FOX which runs on Linux, *BSD, Windows, and MacOSX (through the XDarwin or Apple X ports) in about 3 weeks time. This was mainly in part due to the slick design of FOX and simplicity, and partly in part because of the GIG code generator I put together. Oh, and we looked at SWT, but balked at the Linux or Windows only (and the fact that the flagship, Eclipse, ALWAYS crashes on Linux does not make me happy).
So, that's my experiences with these toolkits. I hope that helps answer the question, and I hope the reply wasn't too long. To summarize: Use FOX if you need C++ and good design. Use wxWindows if porting from MFC or if native controls are important. Use Swing if speed is not a problem, but cross platform really is. Use Cocoa if you only care about MacOSX and need to get something out quick. I actually prototype some UIs in Interface Builder on MacOSX, which says a lot.
It would seem to me that the whole reason for .Net was to port vendor lock-in to new platforms in case Windows died and also to try to compete with Java. Now that Microsoft is being forced to stop distributing a sabotaged variant of Java and to instead distribute Java as specified in the original contract, Java is even more useful.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
I have been using Qt for the last 1.5 years to develop an application for post-processing of segmented (medical) image data as part of my master thesis. The application is available under the GPL at sourceforge
:-)
During development one major disadvantage of Qt has surfaced, and I think it shows that the Trolltech has choosen a terribly wrong solution to a complex problem.
In order to support their signals-and-slots mechanism (which is an elegant concept, and allows for easy implementation of both the model-observer pattern and the mediator pattern) they have added two new keywords to the language, namely signals and slots. In order to support these you _HAVE_ to run a preprocessor called moc (Meta Object Compiler) for your program to link. But moc does not support templates.
Mostly we have managed to work around this limitation by having a non-template superclass which declares the signals and slots (luckily slots can be virtual) and then have the template parts in a subclass, but this leads to unnatural class hierarchies.
Other libraries have managed to support a signals-and-slots mechanism without such an ugly hack. Both Boost.signals and libsic++ implement them. However their syntax is not as nice as Qt's. If C++ really need even more syntax is of course another question
While not all applications rely upon templates, they have some interesting uses, and if an applications first starts to use them, most classes easily ends up as template classes. See the book Modern C++ Design for "new-school" uses of templates. This could easily be the direction C++ development is headed, and it's a shame Qt will not be able to be a part of it.
Remember Pascal? At one time, Pascal was the major development language. Pascal was taught at all the universities. But, an amazing thing happened. In a period of about 4 years, Pascal died. Hundreds of thousands of people had spent millions of hours learning the particular quirks of Pascal and of Pascal compilers. All of that time was lost.
If you have never lived through the loss of a major direction in your life, you may not even realize it can happen. The people saying I'm a troll in this thread probably haven't seen technology die.
Remember Powerbuilder? At one time there were about 1.5 million active Powerbuilder programmers.
No really, is Java dying? Now, I'm seeing, or think I'm seeing, the same thing with Java. The expected energy and support and standards have not appeared. Or have they? If I'm wrong, prove me wrong; I would like Java to be a success, that would simplify my choices. We bet part of our lives on our choices of specialization.
What frightens me is that there is so little support for GUIs in Java. When programmers don't work to improve their tools, they are consciously or unconsciously deciding that the technology does not warrant improvement.
I've seen Java programs that are unacceptably slow.
Sun mismanagement of Java makes people look elsewhere. The world is beginning to realize more fully that proprietary means, "I'm a dog on a leash; I'll bark whenever you yank my chain; please abuse me."
When you use Java, or any language in a way that is not fully compiled to native instructions, you give away your source code. Sure, what you give away is without comments or variable names, but nevertheless you may give away important routines. That's fine if you intend to make a gift of your work to the world; you should have the option not to do so. There has been surprisingly little work on full Java compilers; until Java has acceptable compilers, it hasn't proven itself. Is GCJ mature?
Visual Basic and Perl are written in C. Should it bother me about other languages that they are written in C or C++? Why not eliminate the middleman? Can an acceptable result for application development be achieved using something like Boundschecker and avoiding pointers and using automatic garbage collection where appropriate?
Slashdot has a moderation problem. You can't comment on and moderate the same story. So, moderators by definition moderate stories that don't interest them much.
Bet wrong and go back to being a novice. As I write this, the parent post has been moderated Flamebait=1, Insightful=1, Overrated=1, Total=3. The question is a real and important one, not a troll. When you pick a technology, you lose part of your quality of life if you are wrong; you go back to being a novice at something else.
If you know better, educate me. If I'm wrong, and you know better, educate me. That's the entire purpose of Ask Slashdot.
And I mean it. You would probably be hard pressed to find even one correct sentence here. For those interested, here are a couple of refutations.
X is based on a networking concept where anyone can access anyone else's screen as a network resource.
Wrong. Only those with permission can access it. But that would be programs, not people. For people to access the screen, they would have to physically be there, and that is no different than any other windowing system.
This leads to multi-threading issues as it is possible for two people to use the same desktop, even same application, simultaneously
Wrong. While many people can sit in front of one computer if it's enough space for them, that doesn't mean anything will be more multithreaded. Also, the display server will have to do exactly the same kind of resource multiplexing as it does on windows (whether the apps displaying windows are executing remotely or locally is of little difference, they are still in different threads and usually also different adress spaces).
As a result, toolkits that have their origins in that environment like GTK and wxwindows have strong multi-threading support not to mention strong networking support.
Wrong. Few, if any, X11-toolkits support multithreading. This is a direct result of the age of the X11 core libraries, which themselves does not support multithreading. Most everyone agrees that this is a bug, but it's also one that's hard to fix.
OTOH, Windows was built around a single user concept, which from a networking perspective is more secure because a person's desktop isn't a networking resource (but that's neither here nor there).
Wrong again. How do you think those Citrix farms work? Windows isn't built around a single-user concept any more than Unix is (I am talking about NT/2000/XP of course). It might be the case that your typical windows distribution is only useful for one user at a time, but the underlying technology very much supports several users. As for not exposing anything on the network, sure that makes it more secure. Nobody in their right mind allows X11 through their firewall. But windows has plenty of other security holes.
This results in the base windowing subsystem's reliance on processes as the fundamental object of execution (as opposed to threads).
Again wrong. XFree86 uses a simple request-response loop (no threads or processes). There do exist multithreaded X-servers however, but not for the reasons you say. Mainly, if they are multithreaded, it is purely for performance-reasons.
Whether processes or threads are used, have absolutely nothing to do with networking, but more to do with taste, and programmer preference.
As for windows, it uses threads. Lot's of them, so even there, you are wrong.
So toolkits built upon Windows (MFC, OWL, QT) are able to harness Windows's windowing support in a way that more easily and effectively takes advantage of the features of the subsystem.
I fail to see any correspondence between the "cause" and the "conclusion" here. In any case, it is wrong. On the other hand, windows is a more mature and stable GUI platform. And this is more than enough to explain why X11 GUI's generally suck in comparison (even when they are cross-platform).
Attempting to port one toolkit from its home platform to a foreign platform leads to problems of "look and feel". AWT and Swing are prime examples of toolkits that look strange whereever they are used. Likewise, wxwindows feels funny running on Windows and GTK looks funny. Hell, MFC doesn't even run on X.
True. However, MFC apps can (more or less) run on X11, if you want to pay enough for it, and you really need it. There are companies selling that sort of thing.
What this all boils down to
Well, the only thing it can boil down to, is that either you are a troll, or someone seriously likely to talk out of his ass about anything he doesn't know about.
The final "conclusion" is obviously right, but I fail to see why you needed all the errors above to "support" it.
As I read the question, it was about a cross-platform toolkit with native look-and-feel. I definately interpret this as being native to the platform where it's run, not native to the toolkit! Otherwise the statement would be meaningless.
The discussion has, as usual, talked a lot about Tk, which has it's own look-and-feel and therefore certainly not is native. Qt is cross-platform, with applications that look native, but necessarily aren't.
There's more to a platform's look-and-feel than how the buttons look. The location of the menu-bar is one example. The placement of OK/Cancel buttons another, and standard quick-keys a third. Mac OS X has GUI guidelines which specify how far apart different controls should be, and they are almost guaranteed to not match KDE's guidelines.
Mac OS X/Cocoa also has the concept of sheets, which are basically modal dialogs attached to one certain document window in an application. There's no similar concept in e.g. Gnome, and a toolkit would therefore be hard pressed to find a replacement within the native look-and-feel. In fact multi-document applications in their entirety are differently handled on Windows, Linux and Mac. And I don't even think Gnome and KDE agree on all details of look-and-feel.
Cross-platform with native look-and-feel is therefore a lot more complex than just using Qt or Tk. What would really be needed is actually a way of abstracting away the GUI part of an application entirely, basically making the entire presentation into a Stylesheet of sorts, somtehing like what you do to strings and numbers for i18n/l10n.
But I haven't seen any real efforts to do this. It might work without it for Linux vs. Windows, because neither have very strongly enforced standards on look-and-feel, and you can therefore get away with doing things almost right (or even doing them wrong).