github-starred/MonitorControl

Fork 0

mirror of https://github.com/MonitorControl/MonitorControl.git synced 2026-05-15 14:15:55 -06:00

[GH-ISSUE #867] The Menu Bar Extra icon isn't great on low res displays. (Offer) #541

New issue

Closed

opened 2026-05-05 06:12:37 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 06:12:37 -06:00

Owner

Originally created by @jackhinkle on GitHub (Jan 1, 2022).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/867

Originally assigned to: @the0neyouseek, @JoniVR, @waydabber on GitHub.

Before opening the issue, have you...?

Searched for existing issues

Discussion

Hey there.

The icon used for the Menu Bar Extra is really blurry on 1x (non-retina) displays. Here's a picture:

I would normally consider pointing this out to be nitpicking, but I think this is justified because MonitorControl is an app exclusively focused on external displays, many of which are non-retina.

I initially thought of just re-designing the icons myself (with the help of this guide) and making a pull request. But then I realized that there really isn't a good way to fit the glyph (sun.max) into the sizes necessary for a Menu Bar Extra. This is especially evident with the diagonal rays of sun.max, which are horribly blurry no matter how I size them.

I think the only option to alleviate this is to choose a different glyph. Some Control Center features already use (light.max) and (display), so those obviously aren't options. Although I feel like (lightbulb) or (display.2) might be viable. I'd be happy to design new icons for the Menu Bar Extra, but I also feel that it's important for someone who is more in-charge than I am to decide on a less-complex glyph that also fits MonitorControl.

Just a thought.

Originally created by @jackhinkle on GitHub (Jan 1, 2022). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/867 Originally assigned to: @the0neyouseek, @JoniVR, @waydabber on GitHub. ### Before opening the issue, have you...? - [X] Searched for existing issues ### Discussion Hey there. The icon used for the [Menu Bar Extra](https://developer.apple.com/design/human-interface-guidelines/macos/extensions/menu-bar-extras/) is really blurry on 1x (non-retina) displays. Here's a picture: ![IMG_1810](https://user-images.githubusercontent.com/58039705/147861892-d241f521-0610-46c5-a629-99874af852c3.jpeg) I would normally consider pointing this out to be nitpicking, but I think this is justified because MonitorControl is an app exclusively focused on external displays, many of which are non-retina. I initially thought of just re-designing the icons myself (with the help of [this guide](https://medium.com/@acwrightdesign/creating-a-macos-menu-bar-application-using-swiftui-54572a5d5f87)) and making a pull request. But then I realized that there really isn't a good way to fit the glyph (sun.max) into the sizes necessary for a Menu Bar Extra. This is especially evident with the diagonal rays of sun.max, which are horribly blurry no matter how I size them. I think the only option to alleviate this is to choose a different glyph. Some Control Center features already use (light.max) and (display), so those obviously aren't options. Although I feel like (lightbulb) or (display.2) might be viable. I'd be happy to design new icons for the Menu Bar Extra, but I also feel that it's important for someone who is more in-charge than I am to decide on a less-complex glyph that also fits MonitorControl. Just a thought.

gitea-mirror

2026-05-05 06:12:37 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 06:12:42 -06:00

Author

Owner

@waydabber commented on GitHub (Jan 2, 2022):

Well, this is a default SF Symbol and this is how it should be scaled according to Apple. :)

We could try adjusting the weight (.thin, .light, etc.) and see how it looks on a non retina display. Can you try if some weights look better than others? Here is how you can change the weight (it's a bit convoluted): https://developer.apple.com/documentation/appkit/nsimage/symbolconfiguration

Also there is an embedded icon in the app but it is only used for Mojave/Catalina (status.png), you can try how that looks instead of the SF Symbol. We can change the icon somewhat (alternate weight or a custom non-@2x icon) but changing it to something else altogether is problematic imho, requires the decision of all maintainers and probably affects the app icon design as well.

@waydabber commented on GitHub (Jan 2, 2022): Well, this is a default SF Symbol and this is how it should be scaled according to Apple. :) We could try adjusting the weight (`.thin`, `.light`, etc.) and see how it looks on a non retina display. Can you try if some weights look better than others? Here is how you can change the weight (it's a bit convoluted): https://developer.apple.com/documentation/appkit/nsimage/symbolconfiguration Also there is an embedded icon in the app but it is only used for Mojave/Catalina (`status.png`), you can try how that looks instead of the SF Symbol. We can change the icon somewhat (alternate weight or a custom non-@2x icon) but changing it to something else altogether is problematic imho, requires the decision of all maintainers and probably affects the app icon design as well.

gitea-mirror commented

2026-05-05 06:12:44 -06:00

Author

Owner

@jackhinkle commented on GitHub (Jan 2, 2022):

Hmm, I figured a change of the symbol wouldn't really work out. I worked on it a bit more though, and I think I found a potential solution.

You mentioned how the embedded status.png is only used for pre-Big Sur, with Big Sur and up using just the default systemSymbol. I actually had originally assumed that status.png was used regardless of OS version, but then I finally found these lines:

if !DEBUG_MACOS10, #available(macOS 11.0, *) {
  self.statusItem.button?.image = NSImage(systemSymbolName: "sun.max", accessibilityDescription: "MonitorControl")
} else {
  self.statusItem.button?.image = NSImage(named: "status")
}

This made me wonder if we could just use a single asset for all OS versions instead of needing to mess around with systemSymbol. I did find that many existing Mac apps already use this method, with Control Center.app itself using PDF assets for things like the Wi-Fi menu bar item.

With this idea in mind, I went to design a .pdf for both the 1x and 2x variants of the symbol, which produced some promising results.

This would be implemented by replacing the existing status.png assets with my new status.pdf assets, and replacing the previously-mentioned code (above) with:

self.statusItem.button?.image = NSImage(named: "status")

The resulting build passed without issue. If these changes are alright, I'd be happy to implement them and make a pull.

@jackhinkle commented on GitHub (Jan 2, 2022): Hmm, I figured a change of the symbol wouldn't really work out. I worked on it a bit more though, and I think I found a potential solution. You mentioned how the embedded status.png is only used for pre-Big Sur, with Big Sur and up using just the default systemSymbol. I actually had originally assumed that status.png was used regardless of OS version, but then I finally found these lines: ``` if !DEBUG_MACOS10, #available(macOS 11.0, *) { self.statusItem.button?.image = NSImage(systemSymbolName: "sun.max", accessibilityDescription: "MonitorControl") } else { self.statusItem.button?.image = NSImage(named: "status") } ``` This made me wonder if we could just use a single asset for all OS versions instead of needing to mess around with systemSymbol. I did find that many existing Mac apps already use this method, with Control Center.app itself using PDF assets for things like the Wi-Fi menu bar item. ![SS 2022-01-02 at 18 20 42](https://user-images.githubusercontent.com/58039705/147892067-5233cfc5-88d3-4de8-b8f7-f30ee1e28f84.png) With this idea in mind, I went to design a .pdf for both the 1x and 2x variants of the symbol, which produced some promising results. ![dfaskjs](https://user-images.githubusercontent.com/58039705/147892245-c17dc2e3-3650-45ca-9afe-d92141a4111f.jpg) This would be implemented by replacing the existing status.png assets with my new status.pdf assets, and replacing the previously-mentioned code (above) with: ``` self.statusItem.button?.image = NSImage(named: "status") ``` The resulting build passed without issue. If these changes are alright, I'd be happy to implement them and make a pull.

gitea-mirror commented

2026-05-05 06:12:47 -06:00

Author

Owner

@waydabber commented on GitHub (Jan 3, 2022):

Looks ok to me. I actually wanted to eliminate the custom asset when we dropped Catalina support and only use sfsymbols but it's not a must. Does the status.pdf contain a single vectorized image or does it contain a bitmaps? If the former, then why have 1x and 2x versions, if the latter then it would be more beneficial to simply stick to using png and status@2x.png as straighforward bitmap file formats (but with a more a version that looks better than the old catalina icon). The vectorized pdf icons are indeed working and actually come from the old days when macOS desktop compositor was somewhat PDF based (built upon some NExT foundations) and resolution independence was envisioned as a vector based thing in macOS (as it is now in Windows - fun fact: this was actually partially implemented in macOS and could be invoked via terminal commands up until Apple moved away to the fixed Retina 2x/oversampled assets+scaling as an alternate solution resulting the current semi-resolution-independent desktop).

@waydabber commented on GitHub (Jan 3, 2022): Looks ok to me. I actually wanted to eliminate the custom asset when we dropped Catalina support and only use sfsymbols but it's not a must. Does the status.pdf contain a single vectorized image or does it contain a bitmaps? If the former, then why have 1x and 2x versions, if the latter then it would be more beneficial to simply stick to using png and status@2x.png as straighforward bitmap file formats (but with a more a version that looks better than the old catalina icon). The vectorized pdf icons are indeed working and actually come from the old days when macOS desktop compositor was somewhat PDF based (built upon some NExT foundations) and resolution independence was envisioned as a vector based thing in macOS (as it is now in Windows - fun fact: this was actually partially implemented in macOS and could be invoked via terminal commands up until Apple moved away to the fixed `Retina` 2x/oversampled assets+scaling as an alternate solution resulting the current semi-resolution-independent desktop).

gitea-mirror commented

2026-05-05 06:12:49 -06:00

Author

Owner

@jackhinkle commented on GitHub (Jan 7, 2022):

This looks good. I'm making a pull.
The PDFs are vectors, and there are separate @1x and @2x variants because the @1x icon has to be aligned differently to retain sharpness.

@jackhinkle commented on GitHub (Jan 7, 2022): This looks good. I'm making a pull. The PDFs are vectors, and there are separate @1x and @2x variants because the @1x icon has to be aligned differently to retain sharpness.

gitea-mirror referenced this issue

2026-05-05 07:05:07 -06:00

[PR #541] [MERGED] Add Dutch translations #1119