On Oct 4, 2015, at 5:44 PM, Alex Hall <[email protected]> wrote: > Thanks guys. So a window at, say, 400x400 would be large on an 11-inch > screen, but wouldn't look comically tiny on a 27-inch display?
Not really. The window will look roughly comparable in absolute size, which means it will take up a much smaller portion of the 27-inch display, but that's the point of a large display. It's to fit more stuff, not to see everything at a larger size. > I guess I always assumed it would, but maybe OS X scales everything up > somewhat? No, it doesn't scale things to fit the display size. What's important is the pixel density and the scaling that the display mode applies. For now, let's ignore Retina displays. An 11" MacBook Air actually has a screen which is 11.6". At a 16:9 aspect ratio, that's about 10.1"x5.7". The resolution is 1366x768 pixels. That makes for about 135 DPI. The 27" iMac is about 23.5"x13.2". With a resolution of 2560x1440, that's about 109 DPI. So, just the physical properties of the displays will cause a 400x400 point window (assuming no scaling so a point equals a pixel) to be a bit larger on the iMac. That's not because OS X has scaled things up. The window will be about 3"x3" on the MacBook Air and 3.7"x3.7" on the iMac. Such a window would be about 15% of the display area of the MacBook Air. It would be about 4.3% of the area of the iMac. And that's fine. As I say, that's the advantage of the larger screen. > Having no idea how this stuff looks visually makes thinking about it quite > interesting. :) For now I'll stick to the default/minimum sizes, that should > work well. As to how you should size your window: if you can, you should let auto layout determine the minimum size of the window. Many views will have an intrinsic size. For many, the compression resistance will be higher than 500, which is the priority at which a window holds its size. For some, you'll set a relatively low compression resistance priority to allow them to compress, but in those cases, you probably want to set an explicit constraint to prevent the size from going below what's useful. For example, you may allow a label to compress and truncate its content, but you probably don't want to allow it to go smaller than a-few-characters-plus-the-ellipsis wide. You should have sufficient constraints relating views to the edges of their superviews so that the superview itself can't compress to the point where the contained views are clipped. For example, if you have several views laid out in a row, you might have a leading constraint from the container to the first, a trailing constraint from the last to the container, and horizontal spacing constraints between all of the siblings. The trailing constraint may be an inequality, like greater-than-or-equal-to standard spacing. (Or you can have inequalities elsewhere along the chain, so long as there's not ambiguity.) But, taken together, the constraints should prevent the view from getting too narrow to show all of the views in that row. Likewise, the chain should continue up the view hierarchy to the window's content view. And, voila, the window now has a minimum size. There are some views which don't have an intrinsic size and also don't really have a chain of constraints from their subviews that grant them an effective minimum size. For example, scroll views can usually get smaller than their document view, allowing for scrolling in one direction or the other or both. There's nothing stopping those from shrinking down to zero size. For those, you'll want to set explicit minimum size constraints. Regards, Ken _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
