Post

Replies

Boosts

Views

Activity

Reply to SMLoginItemSetEnabled helper tool questions
Since the state of the above mentioned setting isn’t persistent between macOS restarts, we need to apply it every time at login (as long as user has enabled this preference). Can we have a background daemon that starts at login in order to apply a setting (daemon is immediately terminated afterword)? Or is it necessary for Mac App Store distribution to have the full main app always launch? ⠀ Is that a typo? ‘cause I figured that all the checkboxes in your app were important (-: I think I choose words intentionally ;-)
Dec ’21
Reply to Selectively Removing Default Menu Bar Menus (like File, Edit, View, Window)
Four years after the introduction of SwiftUI, the framework still lacks a clean, straightforward, idiomatic way to remove the default system CommandMenu top-level containers – specifically, File, Edit, and View. Scenario 1: a utility app is designed to disable the zoom button and full-screen mode, doesn’t use tab bar, toolbar or sidebar – the View menu will be empty upon build. Despite this, the View menu remains visible even though it’s completely empty. This is clearly a bug. Scenario 2: a utility app lacks text entry, and has no need for undo/redo or copy/paste, the Edit menu becomes unnecessary. However, the operating system automatically injects Autofill, Start Dictation, and Emoji & Symbols submenus and commands into the Edit menu. Another clear bug. Scenario 3: when using Window instead of WindowGroup to present a Scene in a single, unique app window, macOS still provides a Minimize All option if you hold the Option key while clicking on the Window menu, even though the app has, and can only ever have a single window. Although the zoom command is intentionally disabled as mentioned above, it becomes re-enabled as Zoom All when the Option key is held while clicking on Window menu. This is not a bug. This is carelessness. Why is there a File menu in the System Settings app, which doesn’t deal with files (saving, exporting, printing, etc.)? More perplexing is the presence of a Close All command when the Option key is held down and the File menu is clicked. A complete lack of attention to detail and quality control on Apple’s part.
Nov ’23
Reply to Simulating Fn (Globe) + Arrow Key Events Ignoring Fn Modifier
I made adjustments to the example code since the original had leftover elements from experimentation. import SwiftUI @main struct LittleKeypressDemo: App { var body: some Scene { Window("Keypress Demo", id: "keypress-demo") { ContentView() } .windowStyle(.hiddenTitleBar) .windowResizability(.contentSize) .windowBackgroundDragBehavior(.enabled) } } struct ContentView: View { var body: some View { VStack { KeyPressButton( icon: "arrowtriangle.right.fill", keyCode: 124, eventFlags: [.maskSecondaryFn, .maskControl] ) KeyPressButton( label: "C", keyCode: 8, eventFlags: [.maskSecondaryFn, .maskControl] ) KeyPressButton( icon: "arrow.down.to.line", keyCode: 119, eventFlags: [ /* .maskSecondaryFn, */ .maskControl] ) } .padding() } } struct KeyPressButton: View { let icon: String? let label: String? let keyCode: CGKeyCode let eventFlags: CGEventFlags init( icon: String? = nil, label: String? = nil, keyCode: CGKeyCode, eventFlags: CGEventFlags ) { self.icon = icon self.label = label self.keyCode = keyCode self.eventFlags = eventFlags } var body: some View { Button(action: { simulateKeyPress(keyCode: keyCode, eventFlags: eventFlags) }) { HStack { if eventFlags.contains(.maskSecondaryFn) { Image(systemName: "globe") } if eventFlags.contains(.maskControl) { Image(systemName: "control") } if let icon = icon { Image(systemName: icon) } else if let label = label { Text(label) } } } .controlSize(.large) } } func simulateKeyPress(keyCode: CGKeyCode, eventFlags: CGEventFlags) { guard let eventDown = CGEvent( keyboardEventSource: nil, virtualKey: keyCode, keyDown: true ), let eventUp = CGEvent( keyboardEventSource: nil, virtualKey: keyCode, keyDown: false ) else { print("Error creating CGEvent for keyCode \(keyCode)") return } eventDown.flags = eventFlags eventUp.flags = eventFlags eventDown.post(tap: .cghidEventTap) eventUp.post(tap: .cghidEventTap) }
Oct ’24
Reply to Applying Custom Rounded Corners to a macOS Window
I’ve reverse engineered the macOS inner rim stroke color used for windows, popovers, menus, etc., and the value appears to be … Color(red: 26 / 255, green: 26 / 255, blue: 26 / 255).blendMode(.plusLighter) … which corresponds to the NSColor.gridColor value in dark mode. In usage: .background(.ultraThinMaterial.materialActiveAppearance(.active)) .overlay { RoundedRectangle(cornerRadius: 16) .strokeBorder(Color(red: 26 / 255, green: 26 / 255, blue: 26 / 255) .blendMode(.plusLighter)) } I hope this will be of use to someone in the future.
Oct ’24
Reply to Simulating Fn (Globe) + Arrow Key Events Ignoring Fn Modifier
Apple’s own macOS onscreen Keyboard Viewer also suffers from the same problem, where simulating the combination of Fn + Control + directional keys behaves incorrectly, further confirming this as a bug in the event handling system. Steps to Reproduce: Open the macOS onscreen Keyboard Viewer. Press the combination Fn (Globe) + Control + C and observe the correct window management behavior (the key window beneath will position to the center). The appropriate menu item Window → Center will flash and highlight. Now try to simulate the key combo Fn + Control + Right Arrow (corresponding to the menu item Window → Move & Resize → Right). The expected behavior is that the key window should move and resize to the right half of the screen, but it doesn’t. Filed under FB15532267
Oct ’24