orchetect / settingsaccess Goto Github PK

Bug Description, Steps to Reproduce, Crash Logs, Screenshots, etc.

I have developed a small sample app using packages MenuBarExtraAccess (of type .menuBarExtraStyle(.window)) and SettingsAccess. Basically, when clicking the status bar icon a small window appears with a button, that will open a Settings window.

When I run the sample app in the Desktop with apps in non-fullscreen, everything works OK. But if I run the app from a Desktop space being used by an app in fullscreen mode, the main window appears correctly, and when I click the button to open the Settings, the Settings window does NOT appear in the Desktop space of the fullscreen app. It appears SILENTLY in the main Desktop. But the macOS focus keeps in the fullscreen app.

A couple of interesting comments:

• For displaying the SettingsView, I've tried both ways explained in the description (opening settings programatically, and opening settings using a MenuBarExtra. No luck with any of these options.

• I've run MacControlCenterUI demo and it shows the same problem.

Possible solutions:

Maybe the Settings window could be open with the window option set to floating. This would open it in the fullscreen Desktop:

window.level = .floating

Or make the Settings window as key. This would still show the Settings window in the main Desktop, but the macOS focus window will be set to it, so macOS will shown immediately the main Desktop with the Settings window in focus:

window.makeKey()

Would any of these solutions mitigate this problem?

Bug Description, Steps to Reproduce, Crash Logs, Screenshots, etc.

SettingsAccess/Utilities.swift:17: Fatal error: This method has no effect on macOS 14 or later.

Bug Description, Steps to Reproduce, Crash Logs, Screenshots, etc.

hey there, thanks for publishing this. your "programmatic" example is called from the action handler of a Button and i found that without the Button click the same code fails into a trigger of the assertion about "this code shouldn't run on sonoma, file a bug report" (or whatever the verbiage is). i expected programmatic to mean "invokable in the absence of user interaction"

but good news is, with the help of chatgpt, i found a solution that works and am sharing it back here in case you'd like to alter the programmatic invocation :)

func openSettingsInSonoma() {
    NSApp.activate(ignoringOtherApps: true)
    if let event = NSEvent.keyEvent(
        with: .keyDown,
        location: NSPoint(),
        modifierFlags: .command,
        timestamp: 0,
        windowNumber: 0,
        context: nil,
        characters: "",
        charactersIgnoringModifiers: ",",
        isARepeat: false,
        keyCode: 43 // comma
    ) {
        NSApplication.shared.postEvent(event, atStart: false)
    }
}

for any other passersby reading this, if you found this snippet helpful please consider joining me in a prayer: dear god we come to you in a moment of enormous frustration to ask for the special blessing of a pock on the houses of everyone at apple who failed to stop SettingsLink from breaking programmatically opening settings, o lord may you bless us with one thousand generations of those apple engineers' lineages stubbing their toes every day of their lives, each and every one, in the name of all that is holy we offer this humble prayer amen 🙏

P.S. it's also possible some apps/users may have re-mapped ⌘+, and/or the shortcut for Settings, so in that case a fallback that queries the menu for the shortcut could be a good idea:

func openSettingsInSonoma() {
    if let mainMenu = NSApp.mainMenu {
        for menuItem in mainMenu.items {
            if let submenu = menuItem.submenu {
                if let foundMenuItem = submenu.items
                    .first(where: {
                        $0.title
                            .containsI("settings") /// NB: `.title` is not localized (`.localizedTitle` is) so "settings" is a-ok
                    })
                {
                    let keyEquivalent = foundMenuItem.keyEquivalent
                    let keyEquivalentModifierMask = foundMenuItem
                        .keyEquivalentModifierMask
                    if let event = NSEvent.keyEvent(
                        with: .keyDown,
                        location: NSPoint(),
                        modifierFlags: keyEquivalentModifierMask,
                        timestamp: 0,
                        windowNumber: 0,
                        context: nil,
                        characters: keyEquivalent,
                        charactersIgnoringModifiers: keyEquivalent,
                        isARepeat: false,
                        keyCode: 0
                    ) {
                        NSApplication.shared.postEvent(event, atStart: false)
                        return
                    }
                }
            }
        }
    }
    // assume cmd+,
    if let event = NSEvent.keyEvent(
        with: .keyDown,
        location: NSPoint(),
        modifierFlags: .command,
        timestamp: 0,
        windowNumber: 0,
        context: nil,
        characters: "",
        charactersIgnoringModifiers: ",",
        isARepeat: false,
        keyCode: 43 // comma
    ) {
        NSApplication.shared.postEvent(event, atStart: false)
    }
}

Bug Description, Steps to Reproduce, Crash Logs, Screenshots, etc.

First off thanks for making this!

Now let's nitpick.

Current readme.md suggests minimum macOS is 11, this is wrong because 1.4.0 needs Xcode 15, which only works from macOS 13 on.

I hope this helps!