3 ms·

I hear this quite a lot and am always curious to know which bits of the QWidget hierarchy are insufficiently native on the Mac - I've run in to many problems wi

I hear this quite a lot and am always curious to know which bits of the QWidget hierarchy are insufficiently native on the Mac - I've run in to many problems with Qt on the Mac over the years but that hasn't really been one, though our current app doesn't really use native-looking widgets anyway. As for QWidget being semi-deprecated, this is not the case. They made some noises in that direction around the time Qt 5 was being developed but I think they thought better of it, so it's alive and well and still being developed.

comex 7y ago
For instance: - Text fields are not backed by native NSTextViews, so automatic substitutions, spell checking, and the options you usually have in the right-click/Edit menu are all missing. - Pop-up menus (but not top-menu-bar menus) are also custom, and the appearance and animations are way off. And there are some discrepancies in behavior: a. Suppose you right-click and hold (which opens the right-click menu in a mode where you select menu items by releasing instead of clicking), then release while over a menu item that's either disabled or a submenu. With native menus, the menu gets dismissed; with Qt menus, it stays open. Sounds incredibly minor, right? But it's something I grew to subconsciously rely on, over years of using macOS. When I started using a Qt app, I kept instinctively trying to dismiss menus that way and getting frustrated when they stayed open. b. If the mouse cursor leaves the menu area, native menus stop highlighting any item, while Qt menus keep highlighting whichever item was last highlighted. In the press-and-hold mode, this makes it seem like releasing the button might choose that item; it actually dismisses the menu, same as with native menus, but it's confusing.