Having created an IBDesignable control for use in Interface Builder, it looks like Cocoa bindings are only available for its "Hidden" property and Tooltip parameter. Am I missing something here? Is it not possible to bind the control's value?
The two bindings exposed by NSControl are in fact inherited from NSView - NSControl itself exposes no additional bindings. Apple provides information about all available bindings in its Introduction to Cocoa Bindings. If you want to use bindings within your control you should consider adding more specialized subviews to the control (e.g. NSTextField, NSImageView) and exploiting their bindings.
Related
Apple’s developer documentation on Nib Files in Interface Builder mentions the Application placeholder (highlighted in the picture above) but doesn’t explain its purpose or when it should be used. The article explains the other two placeholders—File’s Owner and First Responder—fairly well.
I would appreciate any information on the Application placeholder, with links to any documentation that I may have missed.
Also, in the Identity Inspector, why is the Application placeholder of type NSObject instead of, for example, NSApplication?
From the documentation of Interface Builder 3.2.6 (copyright 1999-2010):
In Cocoa nib files, the Application placeholder object gives you a way to connect the outlets of your application's shared NSApplication object to custom objects in your nib file. The default application object has outlets for its delegate object and, in Cocoa applications, the application menu bar. If you define a custom subclass of NSApplication, you can connect any additional outlets and actions defined in your subclass.
In an old MainMenu.nib file from 2009, the delegate is connected to the Application placeholder instead of the file's owner. In a XIB file from 2012, the Application placeholder isn't class NSObject. Nowadays the only use I can think of is binding something to Application.delegate.someProperty.
The proper way of enabling click-though is to override acceptsFirstMouse on an NSView to return YES. (Click-through means that you can click on and use a control even when its window is not focused. For example, the Finder toolbar buttons, and the traffic-light window controls use this.)
My problem is that my application is not based on Cocoa, but GTK. Under the hood, GTK uses some Carbon and Cocoa, and I can get a pointer to the NSView if I want - but I can't get the widget to use a different NSView subclass without editing the GTK source. What are other ways to achive click-through?
(And, if possible, "hover-through" - I'd like to have mouse-over events on the click-through controls, too, so I can highlight them, telling the user that they are clickable.)
I could call Carbon's InstallWindowEventHandler with kEventWindowGetClickActivation, but I'm not sure how to use it, and if it's going to work (I've read Carbon is deprecated and might not work on modern Macs anymore). Alternatively, there must be a low-level mechanism to enable this (the Cocoa mechanism has to be implemented somehow). Any ideas?
I know that in Cocoa, in order to use custom component in Interface Builder I should go to property inspector panel and change, say, my standard NSView to the custom one.
Is there any solution for using custom components in Cappuccino while laying out components in Interface Builder?
You can do the exact same thing.
You have your CPSupaView, you just drop a view in IB and you change the class name to CPSupaView.
When one uses the Interface Builder to arrange the UI Components, there is an option where you have to click to resize or arrange all UI components (buttons, labels, etc.) to fit the view. What is this feature called? And how can you do this programmatically?
I think you are referring to the autoresizingMask property for a UIView.
Have a look at the documentation
I've done a fair amount of iOS development in the past couple of years, so I'm pretty familiar with iOS architecture and app design (everything's a ViewController that you either push, pop, or stick into tab bars). I've recently started exploring proper Mac app development and feel a little lost. I'd like to really just have a sanity check and maybe some advice as to what the proper way to build an app like this is:
I'd like to build a library-style, single window app, that will spawn additional windows during its operation, but not as full-blown documents. The main window will be laid out much like OS X Lion's Mail.app, with a three-wide split view containing:
A source list, or high-level topic selection
A list view of items pertaining to the topic selected in the first pane
A detail view, which shows the details of the object selected in the middle pane
Like I said, really similar to Mail.app as far as looks go.
My question is really how to glue all this together from inside XCode. Here's where my confusion lies so far:
The default project generated a NIB with a main menu and window. I like to encapsulate functionality, so should I make a window controller for this window and somehow hook it up in Interface Builder, or does window-specific functionality belong somewhere else?
If possible, I'd like each of my three panes to be separate view controllers. I created three NSViewController subclasses (XCode automatically generated NIBs), and added (to the main menu/window NIB) view controller objects with each class specified, hooking up each one's view property to one of the three Custom View generic NSView objects I dropped into the NSSplitView. When I tried to set each view controller's NIB, only the main menu/window NIB appeared in the drop-down, and typing the desired one by hand seemed to have no effect (the view's contents didn't actually appear when running the app). This makes me think I'm doing something wrong.
I'm a little fuzzy on what types of views I should use for each of the first two panes. I'll obviously build a custom one for the final pane, but it seems like the first two should be present in the Cocoa framework already.
Anyway, if I'm doing completely the wrong thing, don't bother addressing my questions; just tell me what I should be doing instead. I think I just need a proper Mac developer to point me in the right direction.
With regard to your first question, you don't need to use the main window that Apple supplies in MainMenu.xib. If you want, you are free to delete that window from the nib and then instantiate an NSWindowController in your applicationDidFinishLaunching: delegate method which then loads and controls the main window.
You are definitely confused about NSViewController, which is not really all that surprising, since you might assume that it works like UIViewController.
In fact, NSViewController is completely different to UIViewController and does not have the same level of Interface Builder support. You can't place a view controller in a window in IB, for example, whereas this is standard practice on iOS. NSViewController is a relatively new class on the Mac and generally you use it to load views programmatically and manage the view content.
The class that most closely maps to UIViewController on the Mac is NSWindowController. This has been around a lot longer than NSViewController and in fact many Mac apps don't use NSViewController at all.
Generally, each window in your app should have a window controller managing it. You can use subclasses of NSWindowController to handle a lot of the functionality for each window.
If you want to use NSViewController, then you should use your window controller to manage those view controller objects. This is generally done programmatically due to the aforesaid lack of Interface Builder support. Each NSViewController instance loads its view from a specific nib file. You generally don't add view controllers in Interface Builder.
For your source list you would generally use an NSOutlineView if you have multiple sections or an NSTableView. These two objects are used whenever you need a list of items. NSOutlineView is hierarchical, whereas NSTableView is flat.
I hope this helps.