A lot. It has been a year since I last used Qt, but given the frequency with which I hit bumps in their integration with OSX, I'm quite sure that they haven't all been fixed by now.
Keyboard shortcuts, drawers, and focus passing would randomly fail to work, since Qt was welded into the Cocoa event system and sometimes missed rather important edge cases. For instance, pressing the Esc key was programatically indistinguishable from clicking the 'Ok' button in custom drawers. More often, power-user shortcuts were overridden, didn't respect configuration changes, or entirely absent. Some views (table view IIRC) didn't even try to exactly mimic the native look and feel. Menus worked in fundamentally different ways on different platforms: if somebody designed an app to work on Windows, which does menus on a per-window basis rather than globally, menus would randomly appear/disappear on OSX. Oviously this wouldn't be a problem if all your users knew about it, but they won't. Integration with launch services was absent or crippled. Docking windows required tons of theming if you didn't want them to look like crap. Sometimes constraints or conventions imposed by cocoa were overridden, leading to subtle differences in the positioning of button text and so on. I spent 2 person-days hunting down the cause of a 2-pixel border between the edge of one view and the window backing; the hunt ended in failure when I realized that I would have to monkeypatch or completely replace Qt's layout system in order to get the view snug against the edge. Sometimes Qt's abstraction layer led to unacceptable performance tradeoffs that would be easy to solve on any given platform but were simply not addressed in the Qt API. In general, the UI design tools didn't enforce platform-specific conventions and were miles behind XCode in terms of ease-of-use.
I had a few problems that weren't specific to integration, but they were just as frustrating. The documentation, while great for an open source project, was still far behind the status quo for native libraries. I found their documentation on coordinate systems very difficult to understand (in comparison with the Cocoa documentation) and sometimes it was just plain wrong, e.g. about mouse event propagation within graphics views (and you would think that would be a fairly heavily trafficked page, no?).
If you want your Qt app to seem native, you had better be prepared to dig through Qt itself and patch its deficiencies. This often means being intimately familiar with the native libraries, since the bugs reside at edge-cases the Qt devs weren't thinking about when they wrote the code.
Honestly, if I had to do it all over again, I think I would have just insisted coding the front end twice using native libraries and development libraries each time.
...a cross-platform UI toolkit will never be usable by just recompiling and having you GUI work just fine on another platform. Especially MacOS, which was always somewhat special about everything! It's good to learn just one GUI toolkit, but you'll need to split your codebase and even if you have the same base UI for different platforms, accept that lots of windows and dialogs and menus will have one MacOS version and one Windows version (usually you can skip the Linux one because Windows-style apps play well with Linux except for when abominations like Unity fuck things up...).
I never expected the UI to translate perfectly and effortlessly from one platform to another, since (as you mention) that's clearly impossible due to divergent design decisions in the platforms themselves.
However, it is not inconceivable that one could maintain a unified codebase and use a few platform-specific hacks to ensure that your app "philosophically matched" each OS. Quite possibly, one could still save net effort by implementing these patches vs maintaining a split codebase. If this were the case, I would be happy with Qt and I would sing its praise.
My difficulty with Qt stemmed mostly from the bugs. It simply lacked the polish of Cocoa and .NET in a way which noticeably and negatively impacted productivity. "Platforms are different" is no excuse for incorrect documentation, layout engines that are 1-2 pixels off at the edges, broken/incomplete keybindings, missing integration with launch services, and so on. I have the utmost respect for the Qt team -- I wouldn't have guessed that anyone could come so close to unifying the major UI kits -- but Qt still fell short of where it needed to be if it wanted to compete with the native toolkits.
I was mainly referring to objectively missing features rather than subjective design differences, though Qt has made a lot of progress over the past few years in terms of feature support. However, a quick scan of the applications on my Mac only turned up one Qt application that I hadn't already recognized as non-native, and that app was the Kindle application (which had an obviously non-native text rendering system, but excusably so).
Qt applications have at least made it to the point where the scroll bars are correct and the menus usually include the standard structure and emacs keybindings work in text boxes, but I've yet to find a Qt application that has a properly integrated help system, and almost every one quits the application when the last window is closed, native toolbars are rare, combo boxes seem to be used frequently where pop-up buttons would be more appropriate, and nobody seems to add any options to the dock icon's context menu. I've seen enough to know that Qt can be a very close approximation if the effort is put forth to make the app act native (probably better than any other cross-platform toolkit), but it's far from free, requires a ton of platform-specific code, and apps that try hard are few and far between.
This is the reason I don't use jetbrains products, I use linux and the Java font rendering is absolutely awful, I've tried all the fixes and I can't find any of them pleasing enough to use.
@martinced: You've been hellbanned for the past 5 days. Which is a shame - your comments are long and informative.
> I'm using IntelliJ IDEA on Linux since version 4 or so (we're now at version 12).
> And I agree with you but...
> The trick is to use a pixel perfect font with no anti-aliasing at all and to set the correct vertical spacing between lines and then IntelliJ is just going to look fine (for a Java app).*
> So first you go download a real font (a font made especially for programming, like the Proggy fonts which you can get at proggyfonts) (I take the .ttf version)
> You relaunch IntelliJ and then go to:
> Settings / IDE Settings / Appearance / Editor / Colors & Fonts / Font and then you set your pixel perfect font, say :
> ProggySquareTT (Size: 16, Line spacing: 1.3)*
> (oh and btw IntelliJ is so stupid that if you have "Show only monospaced fonts" checked it won't understand that Proggy is monospaced and hence not show it into your fonts choice list)
> I'm 40 years old and still have 10/10 eye vision, which I attribute to two things: avoid dark characters on light background scheme anytime it's possible and never ever using anti-aliased fonts (which are blurry)
> "Pixel perfect" is the way to go here. And anyway anti-aliased fonts under Linux are so fugly compared to OS X / Windows that you're really not missing much by going pixel perfect.
> Regarding the other IntelliJ IDEA fonts (the ones which are not the editor / console), I'm stealing a Tahoma.ttf from Windows and settings everything to be Tahoma.
> Same for my Emacs but for whatever reason under Emacs I'm using Terminus and not Proggy at the moment ; )
> Now of course it's really sad that the only "ok" desktop UI ever made with Swing is the one made by JetBrains: it took people who wrote the fscking most advanced Java IDE to come up with a reasonably looking Java Swing app : (
> The Eclipse guys didn't even bother and created their own UI (SWT) which kinda speaks volume about the nameless mediocrity that Swing is : (
Simple. Switch to VIM. Or, just write GTK code from scratch directly in the IDE.
It's not too hard. I currently use Swing in Java, all written from scratch - no IDEs to be found. I've also dabbled around with simple GTK+ apps. They aren't as easy, nor as efficient, to work with as the standard Java toolkit, but you get used to it.
I switched back to Swing because I wanted as few dependencies as possible.
So--I'm still missing something. Are you saying that the way to get good font rendering in IntelliJ is to write GTK+ apps? It sounds like you misread the OP.
Ah, I see. I'm sorry about that, but I don't think that there's a solution to fix Swing font rendering in IntelliJ itself. Unless, of course, you dive into the source code.
