Way to remember full dimming brightness setting?

[moritzWa]

Is there a way to make the application remember certain monitor setup settings? I pretty much always connect my Apple Studio Display and then turn off the brightness completely on my MacBook Air. It's a bit annoying to continually do that throughout the day as I only use this monitor and I always have the same exact brightness setup. Is there a way to make the application remember this? If not, can somebody point me to the relevant file so I can add this feature? I would love to help (mostly a TS engineer but have built electron apps and am eager to learn).

[waydabber]

Yes, the app should be able to restore the last settings, but for Apple display by default it does not restore full dimming to avoid user confusion. There is a setting to override this:

[moritzWa]

Thanks @waydabber. I enabled this, but it does not fully work for me. However, even if this is fully working it only solves part of my problem. Also, I still have to manually increase the brightness on my MacBook after disconnecting it from my monitor. It should remember that in this monitor setup (built-in monitor only) i want ~80% brightness.

compressed-video.1.mp4

[waydabber]

Ok, I see the problem. The situation is complicated by the fact that you seem to have the built-in display configured as a mirror of the external display. In mirroring setups the brightnesses are somewhat interlinked (as for example when changing the brightness via the keyboard the app can't fully know/decide which screen's brightness the user actually wants to change) and the app avoids interfering or restoring brightness levels to avoid confusion (although I might need to look deeper in the code to check what happens in this situation).

What is the reason for the mirroring + full dimming setup? I presume this is to get rid of the built-in display in a way that it does not show up in the layout as a separate display. Doesn't the soft-disconnect work for the built-in display (or auto-disconnect when an external display is connected) which should cover this use case exactly?

[moritzWa]

In mirroring setups the brightnesses are somewhat interlinked (as for example when changing the brightness via the keyboard the app can't fully know/decide which screen's brightness the user actually wants to change) and the app avoids interfering or restoring brightness levels to avoid confusion [...].

I don't think that explains why the built-in display suddenly changes to 25%?. The keyboard is not involved here. So, that linking here seems like a bug.

What is the reason for the mirroring + full dimming setup? I presume this is to get rid of the built-in display in a way that it does not show up in the layout as a separate display

I actually just want to disable it/only use the external (This seems like a very common workflow as constantly looking down at my built-in monitor is very unergonomic). Is there a better way to do this?

Doesn't the soft-disconnect work for the built-in display (or auto-disconnect when an external display is connected) which should cover this use case exactly?

I am able to turn off the display in both settings (extended or mirrored setup) but the disable-built-in-monitor setting is not remembered! I.e., if I unplug the monitor the built-in screen turn back on (good). But when I then re-connect the monitor I'm back in the extended display setting and the built-in display in enabled/back at full brightness. This seems like a separate bug?

Thank you.

[waydabber]

Enable this:

[moritzWa]

thanks! One improvement suggestion would be to make this easier to find. The settings feel like a massive long wall of text.

[waydabber]

Yeah, it's a byproduct of having too many features. This one is considered an auxiliary feature of one branch of the featureset of the app. :)

[moritzWa]

I think this would probably fix it: #2414
I'm happy to add this if you want. Seems fairly simple.

[waydabber]

Sadly it is not. The app UI is made to work in Ventura where this feature was not available in SwiftUI and it uses a fundamentally different technique to present the layout + the way things are organized wouldn't help Search much (there are monolithic settings panes).

I'll probably drop pre-Tahoe (and get rid of all the complicated code to support both pre-Glass and Glass UI) and Intel in a next major release and then I'll be free to redesign the Settings UI from the ground with better navigation and Search in mind.