As in the question title, what's the relationship between NSAppearance, NSEffectView.Material, and "vibrancy"? I've found through experimentation that, for some materials, the choice of NSAppearance can change how the material appears (e.g. NSEffectView.Material.titlebar will be light or dark depending on the active NSAppearance), while other materials (e.g. .light) don't seem to care.
I suspect that materials like .titlebar are proxies which select from .dark, .ultradark, .light, and .mediumLight depending on the NSAppearance, but then that would seem to be the role of .appearanceBased. I also see in the description for NSAppearance.Name.vibrantLight...
This should only be set on an NSVisualEffectView or one of its subviews.
...which somewhat contradicts a statement from the NSEffectView documentation...
The view’s effective appearance must allow vibrancy... in most cases you set the appearance on the window or on the visual effect view—subviews then inherit the appearance.
...suggesting that it could be correct to set vibrantLight as the NSAppearance of an entire window (if that's the look you wanted).
Finally, I'm confused as to what exactly "vibrancy" is; if someone could explain it, that would be great.
So an NSAppearance generally describes the styling of controls, colors, etc for a view hierarchy that the appearance is set against.
NSVisualEffectView provides a way to achieve two effects: translucency and vibrancy. The former is the more obvious, with the translucent sidebars or titlebars. And the documentation has a really nice description of vibrancy:
Vibrancy is associated with translucency. It describes a compositing mode that does special blending such as Plus Lighter, Plus Darker, Color Dodge, or Color Burn.
Basically describing how the content (text, images, etc) within the visual effect view are composited against the translucency.
So how do these all relate?
Material
Material describes the look of the translucency effect. As you pointed out, some are affected by NSAppearance, some are not. The ones that are semantically describe their usage so that custom UI can resemble that effect regardless of appearance (.appearanceBased, .titlebar, .menu, .popover, .sidebar, .selection) whereas others allow for specific control over the resulting translucency (.light, .dark, .mediumLight, .ultraDark) but should be used in conjunction with their associated NSAppearance so that the content within the visual effect view can match the translucency effect. Unless you need specific control over the material, using appearance-sensitive / semantic ones can result for more standard UI.
Vibrancy
So in order to get the content vibrancy effects that NSVisualEffectView can provide, it needs to be used in conjunction with a vibrant appearance: .vibrantLight or .vibrantDark. Without setting a "vibrant" appearance, NSVisualEffectView will only provide the translucency effect in the background, and the content within it will look plain and not have the special blending modes like you see in sidebars or titlebars.
Related
I am developing a custom slider to support color selection functionality.
This is a screenshot of the current development so far:
The background coloring is very flexible and also offers to use the standard background coloring as implemented in NSSlider using system colors.
The implementation is realized by overriding a NSView rather than NSSlider, since I also want to support flexible sizes of the cells:
I am currently struggling with the shadowing of the knobs. The color sliders should be positioned right next to standard NSSliders. However, if I am not carefully replicated the shadow style of the standard NSSlider, it will look a bit awkward.
Is there any documentation on how the shadow styles (radius, offset, opacity, etc) in the standard controls are designed?
To put it simply: nope.
The control styles are always subject to change, and have never ever been documented. They are what they are and it's up to you to figure it out and mimic them if you need to.
I have a need. I need to make a window. The glass on the window is transparent. I have found some examples:
https://threejs.org/examples/#webgl_materials_shaders_fresnel
https://threejs.org/examples/#webgl_materials_cubemap_refraction
The background of these examples is static pictures.
My background is dynamic. How can I do it?
Maybe you can use THREE.Refractor like shown in this example. It allows you to create a refractive see-through surface. You might have to adjust the respective shader program in order to achieve your intended visual result (the default shader of THREE.Refractor does not perform any distortions).
I have a Gradient Button with the NSAction template. In Apple's apps, this is almost never the way in which configuration options are represented. Rather, the NSAction glyph is used in conjunction with the Disclosure Triangle glyph, in the same Gradient Button. For instance, in System Preferences > Network:
I can't figure out how to add the Disclosure Triangle glyph. How would I do this?
Also, yes, I have already seen this answer. I want to know if there is any official capacity in which to do this, either using Interface Builder, or programmatically with Swift, as is recommended by the Apple Human Interface Guidelines:
When possible, use system-provided images, such as the Action and the Add images, because their meaning is familiar to users.
It should work to just set the type to Pull Down while the style is set to Gradient:
I'm making a completely custom control (NSView), and I want to use the user's preferred highlight color for part of it when it's selected, like NSTableView does.
Unfortunately, there doesn't seem to be any way to get this. The NSColor documentation only lists one (non-deprecated) user-chosen color, selectedTextBackgroundColor, and NSTableView uses a much darker or more saturated (?) color for the selection highlight.
I've tried a couple things, like turning up the saturation (fails for gray), and darkening with shadow() (looks bad, and not like NSTableView), but I'm not an expert on colors.
Does anybody know what NSTableView is doing, to get this color? Is there any way to access it more directly?
NSColor.alternateSelectedControlColor is what you want. The comments in NSTableView.h are somewhat out of date (referring to the color being light blue, when it isn't any more). I don't see the constants in NSColor being deprecated... not sure what you are talking about? (Maybe a documentation bug? When in doubt, look at the headers...)
In Cocoa, specifically the iPhone SDK, the opaque property is described as:
If opaque, the drawing operation
assumes that the view fills its bounds
and can draw more efficiently. The
results are unpredictable if opaque
and the view doesn’t fill its bounds.
Set this property to NO if the view is
fully or partially transparent.
In my experience, if you have a view (label, table cell, etc.) with backgroundColor set to [UIColor clearColor], you do not need to set opaque to NO for it to appear properly (with a clear background).
Intuitively, doing this would require also setting opaque to NO, but I've never run into problems.
Can you mix opaque=YES and clearColor, or am I living on borrowed time? It doesn't seem to be specifically documented anywhere.
Try it and see is the only way forward on the iPhone, because like you say, despite the volume of the documentation that ships with the SDK, it's not very specific in many cases.
As for opaque though, this is just a hint to the compositing engine that tells it it doesn't need to bother to displaying any layers that are covered by the opaque layer. However, the compositing is done by the graphics chip on the phone, so in many cases it is not more efficient to not draw the obscured part of a partially obscured layer, which is most likely why you are not seeing things get messed up at the moment (i.e. cocoa is ignoring the setting in the cases you've tried). By the same token you are not seeing a performance improvement from setting opaque to true.
So my advice would be to stick with using the opaque property the way the docs say because you are risking a buggy rendering for no real benefit.