I would like to emulate the default shadow applied to NSWindows with a CALayer shadow. I can't quite figure out the exact values for the the following properties though:
theLayer.shadowOffset = ?;
theLayer.shadowRadius = ?;
theLayer.shadowOpacity = ?;
I assume that the shadowColor is black (the default).
Does anyone have an idea what those values could be to get a native (Snow) Leopard window shadow?
EDIT:
To clarify, I'm asking if there's any system API that can give me those values. I don't want to hard code those values, as they have changed in the past and probably will change again at some point in the future.
First, it depends on if a window is in background or in foreground. Windows in foreground have a bigger shadow compared to windows in the background.
For foreground windows you could try the following values:
Color: black
X-Offset: 0
Y-Offset: 4 pixels (downwards)
Opacity: 100%
Radius/Blur: 20 pixels
A word of warning: the window shadow values have changed before (from Leopard to Snow Leopard), so hardcoding values will likely end up looking off in future OS versions.
Related
I am designing a table-like control using Cocoa/Objective-C. Since I want to emulate the look of Finder on Mac, I retrieve system colors when drawing my table.
In particular, use [NSColor controlAlternatingRowBackgroundColors] for the table rows, which looks reasonably good in my opinion. However, when it comes to the table headers, I have some issues:
[NSColor headerTextColor] yields a black color (which is fine for me, since Finder's header captions are black, as well), but I expected [NSColor headerColor] to yield a color against which the text can be read well. However, [NSColor headerColor] yields a pretty dark gray - obviously differing from Finder's header color.
So, is it normal for headerColor to be that dark? How does Finder determine its header colors (is this even documented)?
Table view headers in Finder haven't been a solid color since before Mac OS X 10.0. First they were "lickable" Aqua blue (or white, unselected) gradients, then they got a bit flatter over time, and since Yosemite (10.10) they've used the blurry translucent effect that's otherwise accessible to developers as NSVisualEffectView.
In any case, headerColor and several other NSColor system colors (like gridColor) don't reflect current UI designs. It's probably worth filing a bug to Apple about either deprecating the methods, mentioning in the documentation exactly which colors are still used for what, or both.
If you want headers that match Finder, and you're not using NSTableView (which gets them for free), NSVisualEffectView is probably what you want.
how can I set a minimum size in an universal app (win 10) for the application window? in my project I have only object with Page tag, not Window. I want that the screen of the application can't be resized less off a certein value.
thanks a lot
In the Package.appxmanifest of a Windows 8.1 Universal app, you could set a minimum width, to one of 3 pre-defined values. Setting minimum values on your page will not prevent your application from resizing. Setting maximum values will not prevent resizing either, but it will result in black borders when the application frame is larger than your set dimension. It's worth mentioning that 320 px is the absolute minimum width on 8.1 and on Windows 10 (for phones).
In Windows 10 UWP this property is no longer available. You should AdaptiveTriggers to handle your UI layout on Windows 10.
If you want to check the minimum resize dimensions, keep the scaling of your pc in mind. My laptop scales at 125%, a screenshot of the minimum dimension for the desktop client is 627x441 (~500x350 at 100%) including the space used for the app bar. But it's more common to just use AdaptiveTrigger and 720 pixels as the cut-off between phone and tablet.
you are working on a universal app, you shouldn't set a minimum width . It should be working on every resolution and device.
you should instead use visual state manager and adaptive triggers.
best of luck !
I have converted one of my Windows Store applications to a universal application and added a Windows Phone project to it.
When rendering the graphics (Image and Rectangles with ImageBrushes) the graphics always gets scaled even if I set it to not scale which is not how expect it to work.
Example:
I have an image that is named test.scale-100.png which is 27*27 pixles.
The same image exists as a 32*32 pixel sized image named test.scale-140.png and another named test.scale-240.png which is 59*59 pixles
I use this image in my default layout the following way:
<Image x:Name="imgTest" Source="/Assets/test.png" Stretch="None"/>
When I start my app with the Windows Phone 8.1 WVGA 4 inch emulator the 32*32 image is shown with the correct bounds, but the actual image is scaled (I can see that quite simple because the content gets blurred).
The same happens when I start the app with the Windows Phone 8.1 1080p 6inch emulator; The image is 59*59 pixles but the image is a bit blurred.
How can I force scaling to not be performed?
Thanks in advance for any help!
I am not sure. I am looking for a solution right now too. But I found that scaling is not supported in Windows Phone 8.1. Only Windows Store apps are working with scaling. Take a look at link below.
http://msdn.microsoft.com/en-us/library/windows/apps/dn263244.aspx
So, the way how to scale images is to use height/width propreties to force size of image or you can use BitmapImage and its property DecodePixelHeight/DecodePixelWidth together with Height/Width properties to decode the image.
Hope it helps ;)
I have the same issue, I think this is an OS bug:
Test 1
test.scale-100.png +
test.scale-140.png +
test.scale-240.png
= Blurry result
Test 2
test.scale-240.png
= Blurry result, again
Test 3
test.scale-240.png renamed to test.png
= Sharp result!
The problem occurs only with certain assets, not all. In my case only in some DataTemplates. I think that in some situations the system scale the image incorrectly, with an horrible blurry result. If you leave only the "scale-240" image, it is blurry. If you rename it removing "scale-240", it becomes sharp!
In summary, name the image as test.png and stop.
As MSDN says:
Don't use images that aren't sized to multiples of 5px. Units that aren't multiples of 5px can experience pixel shifting when scaled to 140%, 180%, and 240%.
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh465362.aspx
Your Width="53" Height="53" could be the issue of incorrect behavior
I just noticed the iOS 6/7 Delta property found under the UIView's structs layout.
What is this for and why is this missing from AutoLayout?
Note: I noticed this question a while ago, but I'm only posting my answer now because the NDA has been lifted
Why does it not appear for AutoLayout?
As you may have noticed, iOS 7 brings about a whole new look. The look of UI elements have changed, but also so have some of their sizes (or metrics in general). This can make interface design to accommodate both iOS 7 and it's predecessors a bit of a pain.
Apple's official line is to use AutoLayout to solve this; this should take a lot of the hassle out of laying out UI elements for you. Sometimes incorporating this is not easily done, especially if you must still support iOS 5 for business reasons, or your interfaces are managed in a way that makes implementing AutoLayout difficult. As such, Apple seems to have provided a way to make your job a bit easier if you fall into this niche category, and they've called this iOS 6/7 Deltas.
Ok then, what does it do?
Whilst the label in Interface Builder is a bit unclear as to what 'Delta' means in this context, the code contained in the .xib file that corresponds to this feature is a bit more clear:
<inset key="insetFor6xAndEarlier" minX="-50" minY="-100" maxX="-50" maxY="300"/>
The key name insetFor6xAndEarlier explicitly states what this does; you can provide alternative insets for UI elements when run on iOS 7's predecessors. For example, the above defines the following delta change:
x: 50
y: 100
width: -100
height: 200
Whilst the values stored in the .xib doesn't correspond to the quoted values directly, there is a correlation between them.
x: -minX
y: -minY
width: minX + maxX
height: minY + maxY
The images below shows this change visually. It's quite an extreme example, but it's to demonstrate its ability. I would only expect in practice to have delta changes of only a few pixels.
You may notice that the values are the inverse for the iOS 6 view; this is because the deltas are relative to the type of view you're working with. If you're editing for iOS 6, the deltas there are in order to transform the element correctly for iOS 7 (the reverse of the example above).
In order to view the different styles, you can change the way Interface Builder presents it based on the OS it would be running on. This is contained within the File Inspector->Interface Builder Document (1st tab on the right bar), as so:
Does this exist if I like to code my interface by hand?
Not directly, but you can easily achieve the same effect by having conditional checks on OS version within your code, and setting the correct position/size accordingly. The delta ability exists in Interface Builder because there would be no straightforward way to have conditional positioning without having code to do it, and the point of Interface Builder is to get a much code out of the way as possible for UI.
Overall...
Apple strongly recommend that you use AutoLayout, it makes your life easier in most cases. If you can't use it (for reasons mentioned above), deltas provide you with the flexibility to position your UI elements appropriately, based on the current OS's metrics, without the need to manually reposition them in code. A good example is to adjust for the lack of status bar, but there are plenty of other use cases.
Naturally, if you're only developing for iOS7 and above, you don't need to know this feature/won't discover it. Only if you need to have iOS6 devices running your application when built with the iOS7 SDK, without autolayout, do you need deltas.
At the time of writing (21st August), I can't find any documentation regarding this feature, nor any mentions in the WWDC material. I've had a play around, and after a bit of research, that is what I've discovered.
This actually refers to the Delta between layout position from iOS6 to iOS7.
In iOS7, some views can hide the status bar or have it transparent and, in effect, it is overlaid on top of your view. So if you put a UI element at (0.0, 0.0) on iOS6, it will appear below the status bar, but on iOS7 it would appear partially covered underneath the status bar. So in that case you would want a delta that matches the status bar height (20.0 points) so that the layout looks the same in iOS6 and iOS7.
I believe this isn't needed if you use autolayout, but of course, then you lose iPad1 support, which many of us aren't willing to concede at this point in time.
I know this is already been answered, just adding a small variant hoping it could also help those who don't use auto layout and still want to support iOS 6.1 and earlier versions.
Read this Apple's Transition Guide - Supporting earlier version
Choose 'View as' to 'iOS 7.0 and Later'
Base UI for iOS 7. For iOS 6 give suitable delta value. Use preview to see how this will render in iOS 7 and iOS 6 device.
Quick steps:
Select each immediate children of root view individually and add 20px to its 'Y' value.
Then, select all immediate children collectively and give delta Y as -20px. You can also do this in batch or individually.
AutoLayout requires at least iOS 6.0. If you want to support iOS 5.0 you couldn't use AutoLayout.
And those deltas are used to help you adjust the view position on different iOS version(mainly iOS 7 and iOS version lower than 7).
I use those value to help me like this picture.
To see iOS 6/7 Delta in action, I will demo with a SegmentedControl that appears properly on both iOS 6 and iOS 7 devices.
First, select your .Xib or ViewController in Storyboard. Uncheck Use Autolayout and select "View as iOS 7 and later"
In the Interface Builder canvas, place your SegmentedControl so that its origin.y is 20. In iOS 6/7 Delta, choose -20 for DeltaY
This will make your the SegmentedControl laid below the Status Bar in both iOS 6 and iOS 7 devices
Another useful quotes from Developer’s Guide to the iOS 7 Status Bar
Deltas can be set individually for each view and work as you would
expect. If your storyboard or nib is set to view as iOS 6, then
setting the deltas will cause that view to be shifted and/or resized
by the set delta amount when run in iOS 7. Alternately, if your
storyboard or nib is set to view in iOS 7, then the deltas will be
applied when run in iOS 6
If you are using AutoLayout, then Delta is not available.
Try this (tested in iPhone 4s running iOS6):
- (void) viewWillLayoutSubviews {
//iOS 6 workaround offset
if ([[[UIDevice currentDevice] systemVersion] floatValue] < 7) {
self.view.clipsToBounds = YES;
CGRect screenRect = [[UIScreen mainScreen] bounds];
CGFloat screenHeight = 0.0;
screenHeight = screenRect.size.width;
CGRect screenFrame = CGRectMake(0, -20, self.view.frame.size.width,self.view.frame.size.height+10);
self.view.frame = screenFrame;
}
}
With Snow Leopard the default gamma changed from 1.8 to 2.2. I happen to be working on a few Mac apps that use a very dark custom colour scheme provided by Cocoa. On 10.5 it looks fine but on 10.6 with the new gamma it's much darker and really hard on the eyes.
The colour scheme is defined using numerous [NSColor colorWithCalibratedRed:green:blue:alpha:] objects within a theme class.
Is there any way to 'convert' an NSColor object so that it displays on 10.6 exactly as it would on 10.5?
I know this can be achieved globally from within System Preferences but that's not what I'm after.
The best thing to do is store the color profile for the display on which the color looked good.
Then, use the color profile for the display currently in use to to covert the color.
Basically, what you will have is:
(Original Color with Original Profile) converted to (New Color with current color profile).
You will always have three of the four items - you just need to compute the New Color.
For more information, I would suggest reading:
http://developer.apple.com/mac/library/documentation/cocoa/conceptual/DrawColor/DrawColor.html
The only real problems I have are with dark coloured gradients. 10.4 is still a valid target so I have been using my own gradient wrapper class based around CGShading objects for some time (NSGradient is 10.5+ only).
A simple non-linear correction curve based on the formula below can help:
colour_component = pow(colour_component, 1.0/1.19);
The 1.19 value can be adjusted to create different correction curves.
If 10.6 is detected at run time (using Gestalt) the curve is applied to each of the red, green and blue components for both start and end colours before the gradient is calculated. I have left the alpha values untouched.
I also added a handy user preference to turn this on and off.