5 ms·

> It's the same reason why I oppose Java-based UIs. No matter which platform you use it on, it never really behaves like the native widgets, and there are incon

by veeti 15y ago

> It's the same reason why I oppose Java-based UIs. No matter which platform you use it on, it never really behaves like the native widgets, and there are inconsistencies big and small that drive users up the wall. Although Eclipse drives users up the wall in every other way, it uses SWT [1], which uses native controls. [1] http://www.eclipse.org/swt/ http://www.eclipse.org/swt/

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 ago
  I 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 ago
  Qt 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.

by veeti 15y ago

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 ago
I 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 ago
Qt 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.