When using NSSegmentedControl in toolbars (native NSToolbar) with templated NSImage instances the usability has significantly deteriorated on macOS Big Sur.
The selected item has an extremely low contrast in the new style used by macOS 11:
Before macOS 11 selected items were rendered in a high-contrast, inverted style -
the current selection was easily distinguished:
Any ideas on how to change this to make NSSegmentedControls usable on Big Sur much appreciated.
Related
I have a Mac app with a search field in its toolbar (actually a NSTextField, but I tried NSSearchField as well).
My problem is that the text field background on Big Sur is just plain white, which makes it hard to recognize.
Safari's location bar on Big Sur has more contrast. I believe this is somehow achieved by using vibrancy (How to change background color of NSSearchField (like in Messages app in OS X)), but I cannot get the same effect.
I tried:
testTextField.appearance = NSAppearance(named: .vibrantLight)
various combinations of drawing/not drawing backgrounds
various background colors
wrapping my toolbar item into NSVisualEffectView, but that shows around the text field
Edit:
I should mention that I use roundedBezel border style. This alone seems to affect the background color (i.e. background is always white, no matter which color was set).
I'm developing an app for OS X which shows a small window (uses Auto Layout) when exiting. The window's size is about 550 x 290 pixels and it's fixed.
But I'm facing a behavior that seems pretty strange to me:
Starting the app on OS X 10.7: the size of the small window is about as triple as large as it should be (width and height)
Starting the app on OS X 10.8: the width of the window fits but its height is still about as twice as it should be
Starting the app on OS X 10.9: the window has the size as I've designed it
Starting the app on OS X 10.0: same (correct) behavior as with 10.9
I've re-set all constraints to correct settings (Xcode shows no layout issues). Can somebody give me a hint what might be happening there?
I'm absolutely sure that there are no other (conflicting or modifying) constraints within the view.
Update
Below you can find an image containing all constraints of the window. The constraints of the window itself (min and max size) have been set to the current (expected) size.
The image on the left side has been pinned to the bottom, the left and the top and its scaling behavior has been set to proportionally down. So the image should not be the source of the issue.
I've found a solution that works. I think it was a combination of the 2x image within the assets catalog (caused the doubled height) and the labels within the view. The labels contain so much text that they either have to wrap it automatically or stretch them until the content fits (Lion and Mountain Lion seem to do so).
I've added the width constraint to both labels and fixed it at its current value (as given in the Interface Builder). This works for me as AutoLayout seems to keep the label's width and wraps their content (as expected).
Thanks a lot for the hints.
I'm updating my OS X app to use layer-backed views, so I can have Cocoa views on top of my OpenGL rendering (I haven't added any Cocoa views yet). Without layers, I get 60fps. With layers, less than 15fps. My iOS version, where everything is layer-backed, gets 60fps.
I enabled layer backing thusly:
I also had to set the layer's background color to black to avoid bad compositing (I use OpenGL blending, so the final alpha values in the buffer aren't correct for CA compositing).
According to Instruments, most of the rendering time is spent in CA::Transaction::commit:
I tried clearing the alpha channel as recommended here, but this seems to be just an alternative to setting the layer's background color to black.
FWIW, here are the settings for my OpenGL view:
I'm on OS X 10.10 Yosemite.
According to posts on the Apple developer forums, this appears to be a bug in OS X 10.10.
How does auto-layout work to create interfaces in Xcode 6 beta? What are different size classes & how do they work? How to use the "Resizable Unified Storyboard" to create universal iOS app?
I think you are talking about "Size Classes" introduced in XCode6.
A size class is a new technology used by iOS to allow you to custom your app for a given device class, based on its orientation and screen size.
There are presently four size classes.
At any time your device is going to have a horizontal size class and a vertical size class.
You don't need to worry about device size. Whether it is iPhone 4s, 5 or mighty iPhone 6. UI would be handled automatically for you...
For more info read this article.
See this WWDC Video for more clarity..Building Adaptive Apps with UIKit
With that new feature only aspect ratios are defined. Click at the button "blue" area and you will see the description for the aspect:
wAny hRegular -> For all regular height layouts (e.g. iPhones in portrait, and iPads in portrait or landscape)
I built a very simple application with nothing but a single NSTextView in it in xcode / interface builder. I've done nothing to the text view other than change the font face to "Arial" and increase the font size. However, it looks a lot less bold on OS X 10.5 than it does on 10.7. What's going on here?
(10.5 in the top window, 10.7 in the bottom window)
I've tested with Helvetica and got the same results, so it's not something to do with this specific font.
If you enlarge that image enough, you'll see color fringing on the 10.7 sample. This indicates that the text was rendered with subpixel antialiasing, more specifically, using a RGB subpixel ordering. The 10.5 sample uses grayscale antialiasing. While it is generally a good idea to use subpixel rendering, it can look bad on low-resolution screens or CRTs, and it can't be used in a multi-monitor setup where there is more than one subpixel arrangement to contend with. This means that some users will have subpixel rendering enabled for their system, and some won't. Don't try to circumvent that setting in any way, either by overriding the system preference for font smoothing, or by pre-rendering the text into an image. Users are far more likely to notice the one app whose text looks wrong on their system than they are to notice the difference in rendering between two different machines.