Previous app should be activated (focus returned) after closing the app menu

[Feuermurmel]

This is meant as feedback to the creators of this app.

The menu opened from the menu bar icon is not a joy to use for me for multiple reasons:

• When opening the menu, it grabs focus from the frontmost window (making it inactive).

  This has the effect of something on my screen that is not (in my mental model) connected to the menu I'm opening, taking away my focus (no pun intended).

  In case you're wondering, I'm talking about this menu:

  

• The menu opens slowly with an animation. This just makes me wait for no reason, which I find annoying.

  The settings window also has a lot animations. Most of theme aren't that distracting. One example that feels annoying to me is the fade-out-fade-in when switching between the top-level categories (e.g. Displays, Groups, …). It just makes me wait for no reason, and the app feels slow and sluggish to use because of this.

  For an example on how this can be improved, look at MonitorControl. Its settings window also uses some animation, but they are subtler and less distracting IMHO.

• The sub-menus (e.g. "Display Mode" in the screen shot above) look like they are submenus that open to the right, but instead the transition the menu's content. I find normal sub-menus, where I can simply hover over the item to open the sub-menu much more effective.

  Within BetterDisplay, each action in a sub-menu feels like click-wait-click-wait-click, instead of click-drag-release in other apps.

  Even more annoying is the fact that it's not replacing the whole content of the menu, only part of it, e.g. the "Tools" section at the bottom is still there, making it hard for me to figure out where the "sub-menu" starts and ends.

Thats all! :)

[waydabber]

Hi there,

Thanks for the feedback!

• Taking away the focus is intentional. This is common and canonical in more complex MenuBarExtra apps that use NSPopover style menus instead of NSMenu. The entire menu can be dragged off and used as a normal window (see below). But I might change this - the downside is that if the window is not key, some SwiftUI elements cannot render in active state which would be weird (or these all must be replaced with custom stuff).

• Regarding all the animations, the app honors the system "Reduce motion" setting. If you want motion globally, but want animations to speed up or go away altogether in the app, simply change this setting to 0:

• Regarding sub menu chevrons, this is now canonical, as Apple uses the same style embedded chevron-submenus in Control Center menus (Display presets, Airpods settings, WiFi etc). If you want more traditional, separately opening submenus, turn off Settings > Menu > Expanding menu items.

[waydabber]

(note: thanks for pointing me to MonitorControl - I am maintaining the project + wrote most of the code so I know about it lol, glad you like it! ;)).

[waydabber]

For more context, MonitorControl is a purely NSMenu app with a lot of Cocoa hacks to make it look something beyond that. If you want something similar in BetterDisplay, the v1.x versions of the app were also pure Cocoa (no SwiftUI) - those versions should work more like old-school menubar extra apps and you might like those better. If you don't have a built-in or Apple display, it should launch mostly fine on current macOS versions as well (if you have an Apple display it will just crash on launch though on the current macOS versions). Here is a link to that version: https://github.com/waydabber/BetterDisplay/releases/download/v1.4.15/BetterDisplay-v1.4.15.dmg

[Feuermurmel]

Hi! Thanks for the thorough response!

Taking away the focus is intentional. This is common and canonical in more complex MenuBarExtra apps that use NSPopover style menus instead of NSMenu.

I cannot converse about the technicalities. I just noticed that there is one other menu bar item I have, from a third-party app, that also steals focus. But none of the built-in menu bar items (e.g. Wifi, Control Center, etc. do this), but I guess they might be using some internal APIs.

	3rd-Party	Steals Focus
Control Center
Fast User Switching
Battery
Wifi
Bluetooth
Sound
Input
FastScripts	x
Resilio Sync	x
VPN Client	x	x
Hakuna Menu Bar	x
MonitorControl	x
Docker	x
BetterDisplay	x	x

The entire menu can be dragged off and used as a normal window (see below).

I did not know this! This is actually quite cool and solves some of the problems I had (having to go into sub-menus multiple times to try different settings). With the dialog and sub-menus staying open, trying different settings feels much less like a chore.

But I would have never figured out that I could drag off the menu if you hadn't told me.

If you want motion globally, but want animations to speed up or go away altogether in the app, simply change this setting to 0:

This actually helps a lot! I also turned off "Hide other unexpanded menu items", this also makes it a bit less confusing to use for me. :)

Regarding sub menu chevrons, this is now canonical, as Apple uses the same style embedded chevron-submenus in Control Center menus (Display presets, Airpods settings, WiFi etc).

I'll give you that. But only after disabling "Hide other unexpanded menu items", I haven't seen how the Display presets and Airpods settings look, but at least in the Wifi menu, the "Other Networks" section can be opened and closed with a row that stays exactly where it is. It doesn't move or change shape/color, which helps a lot with not losing continuity:

If you want more traditional, separately opening submenus, turn off Settings > Menu > Expanding menu items.

Even better. Problem solved! :) Thanks!

(note: thanks for pointing me to MonitorControl - I am maintaining the project + wrote most of the code so I know about it lol, glad you like it! ;)).

Yes, I like MonitorControl a lot, and I like to use it.

---

Now, after playing around with BetterDisplay and its settings for a lot longer than I intended to (initially, I just created this discussion to place some feedback in the open, because I feel that neurodiverse people are not on the minds of UX designers in many cases), I feel like BetterDisplays would work much better as a standalone app with a two-column layout (like its settings use), with "Display Mode", "Color Mode", etc. on the left side, and the sub-menus' contents on the right side.

Some settings of course are handy to have quick access to, via a menu bar item, maybe the app could provide a way to select some settings to appear in the menu bar (similar to how I use MonitorControl, I've disabled everything expect for the brightness control of my external monitor).

I guess that with the menu, as BetterDisplay provides it right, most people will rarely use more than three of the sub-menus it provides. So all the other options are just noise during daily use.

---

Anyways, thanks for taking the time to respond in depth to my feedback!

[waydabber]

Note: you can hide unneeded menu items or configure which menu items show by default (Settings > Menu > Customize App Menu) and which only when a display section is expanded - this way you can streamline the menu for your needs. :)

[waydabber]

Created an issue out of this, the focus should at least be returned to the previous app upon closing the menu: #4447

[waydabber]

Hmm. But alternatively, I could just fully drop the conventional NSPopover approach (which creates this situation with SwiftUI in the first place - NSPopover forces non-active state on all contained controls unless it is made key window - but menubar extra apps should not need to become key windows for the best experience) and use NSWindow directly (positioned under the menu) and override the isKeyWindow property to force active state on all contained controls. This is the method Apple seems to use to circumvent its own limitations in Control Center.

I created a separate issue for this as this would require reengineering large parts of the app menu management code (and also give up the benefit of NSPopover's native anchoring capabilities):

#4448

[waydabber]

Ok, #4448 turned out to be impossible, abandoned that route.