5 ms·

Qt, Qt, Qt. Basically the only toolkit that gets native look & feel right.

by veeti 14y ago

wtallis 14y ago
Qt is great for getting the native look, but it's never mastered the native feel, at least on OS X.
- rosser 14y ago
  What do you find missing in the subjective experience of using Qt-based tools under OSX?
  - jjoonathan 14y ago
    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.
    - nnq 14y ago
      ...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...).
      - jjoonathan 14y ago
        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.
  - wtallis 14y ago
    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.
zura 14y ago
wxWidgets is worth mentioning. And instead of mimicking, it uses native widgets/controls under the hood. The non-GUI part of the framework is a quite decent as well.
- tonyedgecombe 14y ago
  I used wxWidgets on two projects and it was a terrible decision. I'd never recommend it for anything substantial.
  - kelvin0 14y ago
    I would really like to know what elements made it a terrible decision? Is the whole library broken? Or just some parts of it?
deleted 14y ago
[deleted]

Qt, Qt, Qt. Basically the only toolkit that gets native look & feel right.

by veeti 14y ago

Qt, Qt, Qt. Basically the only toolkit that gets native look & feel right.

wtallis 14y ago

Qt is great for getting the native look, but it's never mastered the native feel, at least on OS X.

rosser 14y ago
What do you find missing in the subjective experience of using Qt-based tools under OSX?
- jjoonathan 14y ago
  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.
  - nnq 14y ago
    ...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...).
    - jjoonathan 14y ago
      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.
- wtallis 14y ago
  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.

zura 14y ago

wxWidgets is worth mentioning. And instead of mimicking, it uses native widgets/controls under the hood. The non-GUI part of the framework is a quite decent as well.

tonyedgecombe 14y ago
I used wxWidgets on two projects and it was a terrible decision. I'd never recommend it for anything substantial.
- kelvin0 14y ago
  I would really like to know what elements made it a terrible decision? Is the whole library broken? Or just some parts of it?

deleted 14y ago

[deleted]