macOS 14.4.1: Settings no longer orders front when activated about settingsaccess HOT 3 CLOSED

Might be a SwiftUI bug, or a change in behavior (hopefully not though).

Does your app run as a dockless menubar app? You may need to call NSApp.activate first to give your app frontmost focus. That might help.

The demo app does it this way using the custom SettingsLink wrapper init:

from settingsaccess.

Thank you so much!! This code now works for me:

SettingsLink {
    Text("Settings")
} preAction: {
    NSApp.activate(ignoringOtherApps: true)
} postAction: {
    for window in NSApplication.shared.windows {
        if window.level == NSWindow.Level.popUpMenu {
            window.close()
            break
        }
    }
}

(For some reason, I was using the openSettingsAccess() injection method before, but SettingsLink now works for me.) EDIT: Could not get SettingsLink to close the popup before, but now works with postAction.

I think the culprit was: for window in NSApplication.shared.windows.... The reason for this code is that it was not closing the menu extra popup when I clicked on Settings. I tried again and confirmed that this code is required in my case. (Why can't SwiftUI just handle that? I think the whole focus is on iOS/watchOS and now the overpriced VR goggles; SwiftUI macOS bugs are taking a back seat. Steve Jobs is rolling his eyes...)

But, problem solved!! The settings window now comes to front, and I don't have to hide all my other windows to get back to it. Man, keeping up with all these frameworks' quirks on different platforms is really something else.

from settingsaccess.

closing the menu extra popup when I clicked on Settings
Why can't SwiftUI just handle that?

I assume you're using a window-based MenuBarExtra? SwiftUI will not auto-dismiss the window since it doesn't inherently know when you'd want to. Definitely a huge issue/shortcoming with MenuBarExtra, and yes it seems another symptom of macOS being second-class citizen to Apple's mobile platforms. There is no native way to dismiss the window programmatically other than the user clicking outside of the window. I built another package called MenuBarExtraAccess that can provide programmatic access to showing/dismissing the window - maybe it will help. But it sounds like your solution may be adequate for your situation.

from settingsaccess.