Is Code-level support still allowing cases dealing with macOS 10.9 Mavericks?

Question

Created Feb ’23

Replies 2

Boosts 0

Participants 1

I have an issue with my input method project (an open-sourced project offering some crucial features that macOS built-in bopomofo method didn't offer in these decades).

Its candidate list window consists of NSTextFields wrapped with nested stack views.

It works well on macOS 10.13 High Sierra and macOS 13 Ventura.

However, on macOS 10.9 Mavericks it shows nothing, looking like every of its sizable components are shrinked to nearly zero width and zero height. At least, if setting the window Opague to "false", it doesn't show anything.

Here's the candidate window controller:

https://github.com/vChewing/vChewing-OSX-Legacy/blob/ff9eccd22dba22225a858d57b5f1eb9f4b9cbd17/vChewing/Modules/CandidateControllers/CtlCandidateTDK.swift

Here's the candidate view (subclassed from NSStackView):

https://github.com/vChewing/vChewing-OSX-Legacy/blob/ff9eccd22dba22225a858d57b5f1eb9f4b9cbd17/vChewing/Modules/CandidateControllers/VwrCandidateTDK_Cocoa.swift

On update, the window controller regenerates the entire view using a shared backend CandidatePool instance. CandidatePool offers data of Strings and NSAttributedStrings as materials, and the frontend will use these materials to construct the candidate panel.

Note: The codebase of these components are exactly the same (except the lack of SwiftUI-specific things for macOS 10.15 and later) as what used in vChewing Mainstream release (requiring macOS 10.13 and later):

https://github.com/vChewing/vChewing-macOS/tree/ReferenceForApple/Packages/vChewing_CandidateWindow/Sources/CandidateWindow/TDKCandidates

Its SwiftUI version of the candidate view is inside the folder above.

I was thinking of opening a Code-level support ticket, but I just don't know whether they still deal with such compatibility issues with macOS 10.9, the last macOS release that supports Steve Job's Aqua interface (making people want to lick on it).

BTW: I do wonder why SwiftUI lags terribly in this case.

Boost

Answer 1

ShikiSuen_Kongenworks OP

Feb ’23

This issue has been solved. Here's the things to beware of when migrating NSStackView things to macOS 10.9:

(Not talking about macOS 10.10 - 10.12 due to lack of tests.)

macOS 10.9 doesn't draw shadow for opaque windows.
In macOS 10.9, even if you set .isOpaque = true and the background color to NSColor.clear, it won't make clear backgrounds like what macOS 10.13 and later behaves.
NSStackView in macOS 10.9 bugs, requiring every of its components to be constraint-set in order to make the entire view size looks as big as what behaves on macOS 10.13 and later.
The subViews of an NSStackView might be more than the views you actually added into it. Instead of directly enumerating the .subviews of an NSStackView, you create another Swift array to track these subviews before adding them to the NSStackView instance.

0

Answer 2

ShikiSuen_Kongenworks OP

Feb ’23

(Here's a supplemental reply to my previous one.) 5. NSStackView on macOS 10.9 might have serious rendering efficiency issues. At least, in VMware Fusion, its rendering speed is slower than SwiftUI.

0