Post

Replies

Boosts

Views

Activity

NSTextField changes its text color when users click on it under dark theme
// //  AppDelegate.swift //  HelloCocoa // import Cocoa @main class AppDelegate: NSObject, NSApplicationDelegate {     func applicationDidFinishLaunching(_ aNotification: Notification) {                  let myAlert = NSAlert()         myAlert.messageText = "Alert Title"         let messageAttributedString = NSAttributedString(string: "Hello,world", attributes: [.font : NSFont.systemFont(ofSize: 12, weight: .bold)])         let myTextField = NSTextField(labelWithAttributedString: messageAttributedString)         myTextField.allowsEditingTextAttributes = true         myTextField.isSelectable = true         myAlert.accessoryView = myTextField         myAlert.runModal()     }     func applicationWillTerminate(_ aNotification: Notification) {         // Insert code here to tear down your application     }     func applicationSupportsSecureRestorableState(_ app: NSApplication) -> Bool {         return true     } } The alert appears like this: but when I clicks on the textfield, the text's color become black: Adding foregroundColor key to attribute dictionary works for me but I really want to know why NSTextfield has such behavior
0
0
564
Jan ’23
Setting NSbutton's keyEquivalentModifierMask doesn't work for control key on macOS 10.15
import Cocoa class ViewController: NSViewController {     @IBOutlet var button: NSButton!     override func viewDidLoad() {         super.viewDidLoad()         button.keyEquivalent = "m"         button.keyEquivalentModifierMask = [.control]         // Do any additional setup after loading the view.     }     override var representedObject: Any? {         didSet {         // Update the view, if already loaded.         }     }     @IBAction func buttonclicked(_ sender: NSButton) {         debugPrint("cliked")     } } but the debug shows that keyEquivalentModifierMask was not set properly button.keyEquivalentModifierMask NSEvent.ModifierFlags [.command]
1
0
577
Jan ’23
deminiaturize(_:) won't call makeKeyAndOrderFront(_:) synchronously on macOS 13
Logs are added for entering or leaving method like this class MyWindow: NSWindow { ... override open func makeKeyAndOrderFront(_ sender: Any?) { debugPrint("will front\(Float(clock())/Float(CLOCKS_PER_SEC))") super.makeKeyAndOrderFront(sender) debugPrint("fronted\(Float(clock())/Float(CLOCKS_PER_SEC))") } ... override open func deminiaturize(_ sender: Any?) { debugPrint("will front\(Float(clock())/Float(CLOCKS_PER_SEC))") deminiaturize(sender) debugPrint("fronted\(Float(clock())/Float(CLOCKS_PER_SEC))") } } when I calls deminiaturize(_:) on macOS 12, the log printed like this every time will deminiaturize42.011353" will front42.012936" fronted42.015907" deminiaturized42.01639" but on macOS 13, the log printed like this will deminiaturize37.431595" deminiaturized37.431637" will front37.491123" fronted37.491623" seems that on macos13, the deminiaturize(:) no longer calls makeKeyAndOrderFront(:) synchronously. Is this a bug?
1
0
745
Nov ’22
Pressing escape key on NSpopover close the popover sender's window when VoiceOver is on
System Version: macOS Monterey 12.3.1 My app has a button which will show popover when clicked the button and make a button in the popover to be the popover's window's firstResponder. When Voiceover is not on, I am able to close the popover using escape key (handled by NSpopover's contentView). But when I turned voice over on, pressing escape key cause both the popover and its parent window to escape, and the debug result showed that the popover's sender received the key event rather the popover (In sender's window pressing escape will close the window). This problem disappeared when I changed the popover's behavior to .applicationDefined (still not working for .transient or .semitransient), but I still want to know why VoiceOver will affect the behavior of NSpopover
1
0
1k
Apr ’22