3 ms·
Qt also "uses native widgets". It doesn't matter, it's still wrong. Yes, the buttons have the right pixels, but nothing behaves exactly right. I think it's act
by natesm 15y ago
Qt also "uses native widgets". It doesn't matter, it's still wrong. Yes, the buttons have the right pixels, but nothing behaves exactly right.
I think it's actually worse feeling than a toolkit like GTK+, which is more of a Linux toolkit that "happens to work" on Mac OS. Qt apps feel like they're trying to sneak something past me (except on KDE, of course), and there's a very uncanny valley-esque effect. A GTK+ application is more "upfront" about it, so at least I understand what to expect immediately.
Cyberduck, a file transfer application, is written in Java, but I had no idea because it uses actual bindings to Cocoa. If you want to provide the best user experience in a Java application, that's the way to go, write swappable front ends for each operating system with the native toolkit bindings.
- nabilt 15y agoI wonder if that is why scrolling in Cyberduck is extremely slow. http://trac.cyberduck.ch/ticket/3799 http://trac.cyberduck.ch/ticket/3799 I don't have a problem with using different UI toolkits as long as they look like native apps. The problem is these toolkits are always a step behind in exposing features of the platform you are developing for.
- veeti 15y agoQt doesn't actually "use native widgets". However, it's capable of using native API's to draw native-looking widgets pixel-perfectly, which is more than enough on GNOME, KDE and Windows. In addition, it takes care of many cross-platform details such as button order and native dialogs, etc. On OS X I'd consider using native API's instead since I've heard so many complaints about Qt there. SWT, however, does actually use native widgets. Try out an app that uses it - it will behave the way you would expect an app to behave.