mikeash.com pyblog/friday-qa-2013-04-05-windows-and-window-controllers.html comments

Alex - 2016-11-29 22:55:00

Tue, 29 Nov 2016 22:55:00 GMT

This is a good article, as far as it goes. It'd be great to see a similar article for setting up an NSDocument scenario. There's a lot more going on, so it's not entirely clear to me how all the pieces fit together.

And of course, NSViewController recently got a lot more powerful, and NSStoryboard is new, so I'd love to hear your ideas on how to use them, too, if at all. One-xib-per-window sounds good, but being able to set up a bunch of common operations straight from IB sounds good, too. I think there's ways to let storyboards span multiple files, but I'm not clear on how that works.

Cheers!

mikeash - 2015-09-29 21:02:04

Tue, 29 Sep 2015 21:02:04 GMT

If you create a text editor, do you create a separate nib for each of the quintillion possible documents your users might write? Of course not. You make one nib for one window which is able to contain and display arbitrary documents.

Likewise, for alerts, you'd create one nib and one window controller for a single alert window that is configurable to show the hundred possible alert messages you have in your app. And of course this is so common that Apple has already done this for you with NSAlert.

Don't search for problems, search for solutions.

Motti Shneor - 2015-09-29 20:02:20

Tue, 29 Sep 2015 20:02:20 GMT

What about nsalert sheet windows I need over my window? Do I need to create a separate nib for each of the hundred possible dialog alerts I have in my App?

7stud - 2015-05-29 00:04:58

Fri, 29 May 2015 00:04:58 GMT

What about cleanup under ARC?

1. The user closes the window.
2. How do you release the WindowController?

HB - 2013-08-26 20:17:27

Mon, 26 Aug 2013 20:17:27 GMT

Guess I'm a couple months late discovering this very helpful explanation of NSWindowControllers.
My code was very similar but you have some better stuff so I changed my code to match. :-)

One instance of the controller works just fine but I can't seem to have multiple instances at the same time.
The [_importantThingControllers addObject: controller];
part of your tutorial doesn't work for me. The window pops up briefly and then disappears.
Not sure what the problem is and it's getting irritating.
Help appreciated!

jamie - 2013-04-27 00:04:05

Sat, 27 Apr 2013 00:04:05 GMT

"Do you not recommend creating windows programmatically? I've been moving to the 1 window, 1 window controller approach but skipping the xib file."

I'd be curious to see examples of this, I know you can do it, but I wonder what best practices are: should you do it in the view class, in another class that "decorates" the view, do you do it at init time or show time, shortcuts for setting up bindings, etc...

Allen - 2013-04-17 17:29:14

Wed, 17 Apr 2013 17:29:14 GMT

Do you not recommend creating windows programmatically? I've been moving to the 1 window, 1 window controller approach but skipping the xib file.

Marc Haisenko - 2013-04-16 07:59:41

Tue, 16 Apr 2013 07:59:41 GMT

s/should be called/should not be called/

Marc Haisenko - 2013-04-16 07:58:43

Tue, 16 Apr 2013 07:58:43 GMT

Nice article. But I prefer a different "guard" for methods that should be called by users: the __attribute__((unavailable("A description string"))).

In your class interface, do:



- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil __attribute__((unavailable("Use 'init' instead!")));

The advantage is that the compiler issues a warning/error at compile time rather than getting an exception at runtime.

Anonymous - 2013-04-15 04:34:43

Mon, 15 Apr 2013 04:34:43 GMT

@MikeAsh: Allan reminded me a possible Q&A topic, the NSController methods. I've never understood that class and assumed it's not really useful ever. Is this true? If not, how is it to be used?

Ian - 2013-04-14 12:10:24

Sun, 14 Apr 2013 12:10:24 GMT

@jamie: Maybe Mike will pick up the mantle and take on that topic, but I've tried making my own Xcode templates, and my experience was that it was SO painful as to not be worth it. And I even make lots of new projects (part of my normal workflow)... The cure is worse than the disease.

Allan Odgaard - 2013-04-11 19:01:16

Thu, 11 Apr 2013 19:01:16 GMT

It’s worth mentioning that prior to 10.8 it was not possible to make a weak reference to NSWindowController objects. This is an issue when you want the window controller to be the delegate of an object in the view hierarchy (where the property should be weak). I believe that all Apple’s classes use “unsafe unretained”, so it’s only a problem with custom classes.

Also worth mentioning that NSWindowController does not descend from NSController or implement the NSEditorRegistration protocol, this means you generally need to bind the views’ properties to an intermediate NSObjectController (where the window controller is set as the content) to have the commitEditing and discardEditing methods.

Lastly, I am surprised that you stress the need for a xib. Since embracing auto-layout I am moving more and more of my GUI from xib files into source form. The advantages of having your GUI in code are many: version controllable, easier to refactor, ability to cut, copy and paste GUI code, no need to sync class info between code and GUI editor (with a lot of run-time errors eliminated related to this), and everything is 100% explicit and searchable.

Benedict Cohen - 2013-04-09 08:44:45

Tue, 09 Apr 2013 08:44:45 GMT

It's worth noting that "one window = one nib + one NSWindowController subclass" is conceptual similar to the default iOS approach for view controllers.

Mark Aufflick - 2013-04-09 02:15:12

Tue, 09 Apr 2013 02:15:12 GMT

Of course the other way to deal with the property/lazy loading issue is to use bindings. In the simple example given, you can just have regular NSString properties, and then bind the NSTextField stringValue to it.

jamie - 2013-04-08 16:58:59

Mon, 08 Apr 2013 16:58:59 GMT

"Apple does a grave disservice to new Cocoa developers with their poorly constructed Xcode templates."

Here's a Q&A topic: How can I create my own Xcode templates for files and subclasses?

Peter Huber - 2013-04-06 12:31:57

Sat, 06 Apr 2013 12:31:57 GMT

Great article and thanks: I could never think of a situation where I would actually use the default initWithWindow: call that XCode's template provides, but I always kept it around "just in case". I guess I figured that there must be a profoundly logical reason why Apple chose to provide it and that one day I would have a revelation, then go back and refactor all my old code :-).

Ken Thomases - 2013-04-06 06:58:21

Sat, 06 Apr 2013 06:58:21 GMT

Thanks for writing this. I strongly concur with your thesis. Apple does a grave disservice to new Cocoa developers with their poorly constructed Xcode templates.

Anonymous - 2013-04-06 00:41:48

Sat, 06 Apr 2013 00:41:48 GMT

Are there any downsides to just skipping the init methods and overriding -(NSString*)windowNibName?

Also, to avoid the problem you mentioned of the window not yet being loaded, I usually just use bindings. For example, for a simple login panel, I'll have two public NSString @properties on my NSWindowController subclass, named 'username' and 'password', and in my window I just bind the text fields to them. Bindings work beautifully for solving this problem.

Ari Weinstein - 2013-04-05 20:12:26

Fri, 05 Apr 2013 20:12:26 GMT

Well huh. I've been writing Mac apps for a while, and I only use NSWindowController sometimes... and I often bundle a bunch of windows into MainMenu. Good points here, though, I'll have to reconsider my ways.

Michaël Fortin - 2013-04-05 17:13:11

Fri, 05 Apr 2013 17:13:11 GMT

Phew! I've been doing it the right way.

Interesting read as always, keep it up!

Anon - 2013-04-05 17:01:09

Fri, 05 Apr 2013 17:01:09 GMT

documneted -> documented
Nowe -> Now