29

Usually I am making iOS app but now I am trying to make an OS X app, and I am lost at the very beginning. Say the style I make the iOS apps are totally programmatic, there's no xib files or whatsoever just because that I have a lot more control by typing than dragging. However in OS X programming, it starts with some xib files with the menu items and a default window. There are quite a lot of items in the menu items so that's probably not something I want to mess around, but I want to programmatically create my first window myself.

So I did this:

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification { NSUInteger windowStyleMask = NSTitledWindowMask|NSResizableWindowMask|NSClosableWindowMask|NSMiniaturizableWindowMask; NSWindow* appWindow = [[NSWindow alloc] initWithContentRect:NSMakeRect(200, 200, 1280, 720) styleMask:windowStyleMask backing:NSBackingStoreBuffered defer:NO]; appWindow.backgroundColor = [NSColor lightGrayColor]; appWindow.minSize = NSMakeSize(1280, 720); appWindow.title = @"Sample Window"; [appWindow makeKeyAndOrderFront:self]; _appWindowController = [[AppWindowController alloc] initWithWindow:appWindow]; [_appWindowController showWindow:self]; }

So here, I have created a window first, and use that windowController to init this window. The window does show up in this way, but I can only specify the inner elements, like buttons and labels here, but not in the windowController. It makes me feel bad so I tried another way.

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification { _appWindowController = [[AppWindowController alloc] init]; [_appWindowController showWindow:self]; }

and after this I want to set the other elements in the loadWindow: function in the windowController like this:

- (void)loadWindow { [self.window setFrame:NSMakeRect(200, 200, 1280, 720) display:YES]; self.window.title = @"Sample window"; self.window.backgroundColor = [NSColor lightGrayColor]; NSButton* sampleButton = [[NSButton alloc] initWithFrame:NSRectFromCGRect(CGRectMake(100, 100, 200, 23))]; sampleButton.title = @"Sample Button!"; [sampleButton setButtonType:NSMomentaryLightButton]; [sampleButton setBezelStyle:NSRoundedBezelStyle]; [self.window.contentView addSubview:sampleButton]; NSLog(@"Loaded window!"); [self.window makeKeyAndOrderFront:nil]; }

Unfortunately, this never works. the loadWindow: never gets called, nor windowDidLoad:. Where did they go?

And please don't ask why I don't use nibs. I wish to make some highly customized views inside, possibly OpenGL, so I don't think nibs can handle it. I am greatly appreciated if anyone could help. Thanks.

And also, who knows how to even start the menu items from scratch, programmatically?

I am using the latest Xcode.

Improve this question
6
  • 2
    Your idea that XIBs cannot handle OpenGL is flat out wrong. Apple provides an OpenGL View to use in XIBs. XIBs can handle anything programmatically created views can, they are simple a way of encapsulating those items. Commented Mar 29, 2013 at 0:34
  • That does fit for some cases, but think about board games in iOS apps. each chess piece is a view with custom images, then you need to move them around. If most of the views in the windows are highly dynamic, with animations, it's hard to imagine how it could be implemented without making a big mess. Commented Mar 29, 2013 at 0:46
  • 1
    If you are doing it OpenGL, you have one view and all the pieces and what not are done in OpenGL. If you are not doing it in OpenGL, the same idea applies, you can have one superview in you XIB and then you can populate that view with your other views programatically. This way you get the benefits of using a XIB while still controlling your game board in code. Commented Mar 29, 2013 at 0:50
  • So what you mean is, making a big custom view in the xib then programmatically make other small views in code? That sounds valid, though there are still a lot more concerns regarding dynamically calculating the size of the small views based on the window size. In OS X it changes, in iOS it doesn't. Commented Mar 29, 2013 at 0:55
  • Look in the autoResizingMask property for views. Or calculate the window size yourself when it changes. Or use a scrollView. Either way, these problems have all been solved before, you just have to find the right approach for your app. Commented Mar 29, 2013 at 1:04

4 Answers 4

Reset to default
49

I spent an entire Sunday digging into this problem myself. Like the person asking the question, I prefer coding iOS and OSX without nib files (mostly) or Interface Builder and to go bare metal. I DO use NSConstraints though. It is probably NOT WORTH avoiding IB if you're doing simpler UIs, however when you get into a more complex UI it gets harder.

It turns out to be fairly simple to do, and for the benefit of the "Community" I thought I'd post a concise up to date answer here. There ARE some older Blog Posts out there and the one I found most useful were the ones from Lap Cat Software. 'Tip O The Hat' to you sir!

This Assumes ARC. Modify your main() to look something like this:

#import <Cocoa/Cocoa.h> #import "AppDelegate.h" int main(int argc, const char *argv[]) { NSArray *tl; NSApplication *application = [NSApplication sharedApplication]; [[NSBundle mainBundle] loadNibNamed:@"MainMenu" owner:application topLevelObjects:&tl]; AppDelegate *applicationDelegate = [[AppDelegate alloc] init]; // Instantiate App delegate [application setDelegate:applicationDelegate]; // Assign delegate to the NSApplication [application run]; // Call the Apps Run method return 0; // App Never gets here. }

You'll note that there is still a Nib (xib) in there. This is for the main menu only. As it turns out even today (2014) apparently no way to easily set the position 0 menu item. That's the one with the title = to your App name. You can set everything to the right of it using [NSApplication setMainMenu] but not that one. So I opted to keep the MainMenu Nib created by Xcode in new projects, and strip it down to just the position 0 item. I think that is a fair compromise and something I can live with. One brief plug for UI Sanity... when you're creating Menus please follow the same basic pattern as other Mac OSX Apps.

Next modify the AppDelegate to look something like this:

-(id)init { if(self = [super init]) { NSRect contentSize = NSMakeRect(500.0, 500.0, 1000.0, 1000.0); NSUInteger windowStyleMask = NSTitledWindowMask | NSResizableWindowMask | NSClosableWindowMask | NSMiniaturizableWindowMask; window = [[NSWindow alloc] initWithContentRect:contentSize styleMask:windowStyleMask backing:NSBackingStoreBuffered defer:YES]; window.backgroundColor = [NSColor whiteColor]; window.title = @"MyBareMetalApp"; // Setup Preference Menu Action/Target on MainMenu NSMenu *mm = [NSApp mainMenu]; NSMenuItem *myBareMetalAppItem = [mm itemAtIndex:0]; NSMenu *subMenu = [myBareMetalAppItem submenu]; NSMenuItem *prefMenu = [subMenu itemWithTag:100]; prefMenu.target = self; prefMenu.action = @selector(showPreferencesMenu:); // Create a view view = [[NSTabView alloc] initWithFrame:CGRectMake(0, 0, 700, 700)]; } return self; } -(IBAction)showPreferencesMenu:(id)sender { [NSApp runModalForWindow:[[PreferencesWindow alloc] initWithAppFrame:window.frame]]; } -(void)applicationWillFinishLaunching:(NSNotification *)notification { [window setContentView:view]; // Hook the view up to the window } -(void)applicationDidFinishLaunching:(NSNotification *)notification { [window makeKeyAndOrderFront:self]; // Show the window }

And Bingo... you're good to go! You can start working from there in the AppDelegate pretty much like you're familiar with. Hope that helps!

UPDATE: I don't create menus in code anymore as I've shown above. I've discovered you can edit MainMenu.xib source in Xcode 6.1. Works nice, very flexible and all it takes is a little experimentation to see how it works. Faster than messing around in code and easy to localize! See the picture to understand what I am on about:

Edit MainMenu.xib

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

Thank you very much for this detailed explanation after this long time. I thought no one would take any care of this after months, but I change the correct answer to this one and commend your work. Thanks very much again.
How do I find my equivalent of 'MainMenu' nib... I am so confused? What is a nib?!!! Ha
stackoverflow.com/questions/32865162/…
I'm a bit confused. You reference view and PreferencesWindow in your solution, both of which do not exist in AppDelegate. Where am I to get these? I can create a property for the view of course, but I'm lost with the PreferencesWindow. Thanks-.
They were just some things I created of my own... you can do what you like with respect to those.
3

See https://github.com/sindresorhus/touch-bar-simulator/blob/master/Touch%20Bar%20Simulator/main.swift

In main.swift

let app = NSApplication.shared() let delegate = AppDelegate() app.delegate = delegate app.run()
Improve this answer

Comments

1

Swift 4:

// File main.swift autoreleasepool { // Even if we loading application manually we need to setup `Info.plist` key: // <key>NSPrincipalClass</key> // <string>NSApplication</string> // Otherwise Application will be loaded in `low resolution` mode. let app = Application.shared app.setActivationPolicy(.regular) app.run() } // File Application.swift public class Application: NSApplication { private lazy var mainWindowController = MainWindowController() private lazy var mainAppMenu = MainMenu() override init() { super.init() delegate = self mainMenu = mainAppMenu } public required init?(coder: NSCoder) { super.init(coder: coder) // This will newer called. } } extension Application: NSApplicationDelegate { public func applicationDidFinishLaunching(_ aNotification: Notification) { mainWindowController.showWindow(nil) } }
Improve this answer

Comments

0

Override the -init method in your AppWindowController class to create the window and then call super's -initWithWindow: method (which is NSWindowController's designated initializer) with that window.

But I generally agree with the comments that there's little reason to avoid NIBs.

Improve this answer

5 Comments

Thanks. Though, it looks like everyone is so resisting not using nibs. For iOS, I used to do it, but it was incomplete, like the storyboard and segues can only do a bunch of limited stuff, so I totally gave up and switched to pure code. Isn't this the same for OS X?
I haven't done iOS development, but I understand that storyboards and segues impose much more structure than just NIBs. NIBs are just "freeze-dried" object graphs that you can reconstitute at will. It's not that you end up doing everything in a NIB and have little or no code. It's just that using NIBs doesn't interfere with doing what you have to do with code and relieves some of the tedious, burdensome coding, so why not?
Storyboards are different from XIBs and yeah, they are way more limited. Like I said in my other comment, XIBs are simply an easy way to encapsulate your views/objects. They don't really DO anything else. They aren't a replacement for views and they aren't a replacement for controllers. They are simply there to make life easier. You are free to not use them, but you are going to end up writing more code to do the same things.
So I would raise another example, when you are doing a full-screen game, from what I can see everything is customized. In that case does it just give up xibs, or it utilizes the native full screen mode and place a single OpenGL view inside that processes everything?
I think you are confused about what XIBs are. Nothing a XIB does would preclude you from doing whatever you want in code. Just think of it as a container. It is not a view and it is not even an object. It is just a serialized container of objects that helps with code organization and basic layout.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.