#nsview

Prototyping constraints can be introspected (and removed) in UIView but not in NSView. Removing prototyping constraints is essential when you have a custom component that you want people to be able to position visually (intuitively) in IB but where you want to create the constraints yourself (e.g., to align it in relation to another component).

This is so wrong! And I saw it in many StackOverflow answers.

I have a Retina Mac which is almost always plugged to an external non-retina 22” monitor: some windows are drawn as retina and some are not. And it matters. The shortcut I’ve seen too often is [[NSScreen mainScreen] backingScaleFactor]. My main screen is the built-in retina one so this call will always return 2.0f ; then what about the windows on the external non-retina display? They will be drawn for a retina display, and then uglily scaled down by the system.

Why people are getting confused with NSScreen?

This back practice is probably inherited from iOS, where everyone’s dealing with the UIScreen. Well, this is wrong on iOS too, since an iOS device can have multiple screens and windows. Think about AirPlay.

The right answer

It's so simple. If you are drawing in your NSView or NSCell code, just call -[[myView window] backingScaleFactor]. In the case the window is moved across screens, all will be redrawn with the new backing scale factor. Though, it’s a little trickier if you’re using a CALayer. In your -[CALayer drawInContext:] method, get [self contentSize]. This part is easy, but the view backed by the CALayer needs to keep the layer updated by any change of the scale factor:

- (void)viewDidChangeBackingProperties { [super viewDidChangeBackingProperties]; [[self layer] setContentsScale:[[self window] backingScaleFactor]]; }

Typically, the solution involves iterating through NSView's - [NSArray subviews] and invoke the child's - (void)removeFromSuperview method. This is tedious. A much easier solution is to set an empty list of childs on the parent NSView, like so:

[self setSubviews:[NSArray array]];

윈도우의 크기가 변경됨에 따라 서브뷰의 크기를 리사이징 하는 경우

현재 NSView 의 크기를 제한하는 방법은 아래와 같습니다. (이를 위한 설정같은 건 없더군요..)

일단은 NSView 를 상속받은 커스텀 뷰를 생성하고, 

아래와 같이 Bounds 가 변경되는 Notification을 허용하도록 설정하고,

Notification 을 등록합니다.

{

[self setPostsBoundsChangedNotifications:YES];

 [[NSNotificationCenter defaultCenter] addObserver:self 

 selector:@selector(viewContentFrameDidChange:)

 name:NSViewFrameDidChangeNotification

object:self];

}

Notification을 수신할 때 처리한 메소드에서 크기변경을 제한하기 위한 코드를 

삽입하면 됩니다. 아래 내용은 테스트코드입니다.

- (void) viewContentFrameDidChange:(NSNotification *)notification

{

NSSize superSize = [[self superview] bounds].size;

NSSize changedSize = [self bounds].size;

// 현재뷰가 지정된 크기보다 커지면 최대값으로 설정 

if (limitedMaximumWidth <= superSize.width)

 {

changedSize.width = limitedMaximumWidth;

 [self setFrameSize:changedSize];

}

// 현재뷰가 지정된 크기보다 작아지면 최소값으로 설정 

else if (limitedMinimumWidth >= superSize.width)

{

changedSize.width = limitedMinimumWidth;

[self setFrameSize:changedSize];

}

// 상위뷰가 최대값보다 작아지면 상위뷰의 크기로 설정 

else if (limitedMaximumWidth >= superSize.width)

{

changedSize.width = superSize.width;

[self setFrameSize:changedSize];

}

NSView 에는 배경색상을 설정하기 위한 별도의 메소드가 없습니다.

가장 심플한 뷰인데 이런 메소드가 없어서 직접 커스텀 뷰를 만들어서 NSView를 상속받고,

- (void) drawRect:(NSRect)dirtRect;

메소드를 Override 해야합니다.

참고로, 인자로 넘어오는 dirtRect 는 NSView 의 전체 프레임이 아니고,

갱신되어야하는 영역입니다. (invalidate rect 를 생각하면 될 듯..)

* 배경색상 채우기

- (void) drawRect:(NSRect)dirtRect

{

[[NSColor blueColor] setFill];

NSRectFill([self bounds]);

}

위 [NSColor blueColor] 를 변경하기 위한 멤버만 추가하면 되겠군요..

* 배경패턴이미지 채우기

- (void) drawRect:(NSRect)dirtRect

{

[[NSColor colorWithPatternImage:patternImage] setFill];

NSRectFill([self bounds]);

// This is the code to make an NSView a layer HOSTING view [view setLayer:[CALayer layer]]; [view setWantsLayer:YES]; // This is the code to make an NSView a layer BACKED view [view setWantsLayer:YES];

The two code samples are almost identical. So what's the difference between a layer-backed view and a layer hosting view? The Apple docs explain it fairly well, but to summarize:

In a layer-backed view...

The contents of the view are just cached onto a backing CALayer

Enables you to use some of the Core Animation goodness with the NSView with no changes to the actual drawing code

You cannot manipulate the layer directly, it is owned entirely by the view itself

In a layer hosting view...

The view simply serves as a host for the layer

The layer can be manipulated, sublayers can be added, etc. (more flexibility in terms of Core Animation, but less flexibility when it comes to operating as a standard NSView)