EDIT: Brain-fart: Firefox != Mozilla.
I still remember discovering uTorrent. I'd tried about 4-5 Bittorrent apps before then, including 3 wxPython-based ones and Azureus. They also basically did what I needed - they let me download, they let me keep track of existing transfers, and they let me throttle bandwidth. The difference was that uTorrent didn't take up a few hundred megs of RAM and didn't peg my CPU. The developer accomplished this by doing an end-run around all the layers of abstraction and keeping an eye on performance; it's much harder to do this with a cross-platform library in the way.
I wrote some small Qt GUI applications (mostly frontends to scientific tools), and most people don't notice it's not native.
Also, this depends a bit on your market. Some markets are more sensitive to nativeness than others, for instance, by operating system:
OS X > Windows > Linux/UNIX
In OS X people are quite used to polished native applications that conform to Apple's HIG, they will also expect it. Windows is somewhere in the middle, there are some widely used applications that do not look native. Linux/UNIX users seem to be completely oblivious to nativeness, since they are used to having a mix of Qt/Gtk+/Tk/Lesstif/whatever applications.
Users become very sensitive to the details of the windowing system, and when a program breaks their expectations, they often consciously recognize what's wrong with the program, they just get frustrated. I'm thinking of things as subtle as whether you can create and rename folders from within a Save As... box, or what the tab order of fields in a dialog is, or what cursor shows up when you drag & drop items. It's very easy to get the look & feel 99% right and still have users feel that something is still very wrong with the app.
On Windows, Mac OS X, KDE and GNOME, these static functions will call the native file dialog when possible.
http://doc.trolltech.com/4.7/qfiledialog.htmlQT is way better than Swing. It's a laughable comparison, really. QT does such a better job at being native.
1. I'd personally use C. But, thats only because I'm more comfortable in C than any other cross-platform language (C++, Java or any other JVM-based language, etc).
The problem with cross-platform apps is that you end up programming to the least common denominator of the platforms you support, and your app never has the performance or look & feel that users expect. Contrast: uTorrent vs. Azureus, iChat vs. Pidgin, TextMate vs. jEdit, etc. In a hyper-competitive desktop space, that often means death. Giant companies like IBM (Eclipse) or Mozilla (Firefox) can get away with it because the scale of what they're doing is very difficult for a small startup to replicate, but most micro-ISVs can't.
Yes, this is one reason why developing desktop apps sucks.