What I'd like to do is basically use a widget like the one in step 4 here:
This is the utilities panel on the right of Interface Builder / XCode, where you can use various Inspector tools, e.g. 'Attributes Inspector', etc.
Does a widget like that exist in Cocoa/Interface Builder? It looks like it's somewhat based on a NSTableView, but I don't see how I'd do the grouping-based functionality using a standard NSTableView (i.e. the 'Show' button on the top-right, or the horizontal line separators between groups), and I also don't quite see how I would do the headers (which span multiple table-rows). The images on top are probably a mix between (visually) a toolbar and (practically) a tab-bar, but it looks like it's integrated in the whole.
I searched somewhat, did see this post, which refers to a non-existing project. I found copies, but they don't appear to work in latest versions of Interface Builder (I'm using XCode 6.1.1). They also appear to be pane/window-based, which is an older version of Interface Builder.
There is no one built-in control to do that. It's a combination of multiple controls, including custom views. Likewise, there are multiple ways to approach implementing it.
There may very well be a tab view to switch out the various inspectors, but, if so, it's "tabless" and the actual buttons to do the switching are customized. There's just a row of buttons and the controller switches the tab view's tab based on which is pressed. If you pick the right button style, set a template image and no title, and set their states so they act like radio buttons (only one "on" at a time), they should draw properly (the selected one will glow blue).
I think it's conceivable that the sections could be implemented using a view-based outline view. It would be a single column and the cells would be the complex views you're seeing. The section headers would be rows at the root level and the sections would be children of those rows, a level deeper in the hierarchy of the outline. Therefore, hiding and showing the sections would be achieved by collapsing and expanding the section header rows. There's even a special view identifier, NSOutlineViewShowHideButtonKey, that NSOutlineView uses to look up a Show/Hide button view from the NIB (or the delegate).
You can also implement the sections and their headers using a stack view. Apple actually has sample code for that exact thing:
InfoBarStackView.
Related
Several places in OS X (in this example, the Users & Groups pane in System Preferences) have circular image views that allow the user to either drag in an image, like in an editable NSImageView but also allow them to click to show a popover that allows various other choices of image sources.
I have checked the ImageKit framework, but the only thing I found similar is the image taking sheet.
How can I make use of this feature in my own Cocoa applications? I'd imagine it is implemented in some standard framework—but any pointers on implementing something like this would be quite appreciated.
You will have to go down the custom control root as this is not available as a stand alone control.
However you have all the prerequisites.
The circular image view
There a several ways to implement this. You could try using a standard Cocoa button and customise as needed. Although it might just be easier to build from scratch by subclassing NSView. This was you can avoid all the NSCell stuff. I would do the latter.
The popover
Roll your own master-details type view controller to be displayed as the popover's content. In the left have a NSTableView (the master), the right have a NSCollectionView (the details). Below the collection view add some buttons.
I want to do something similar to the calendar.app info panels, take a look at the pictures.
Here you can a see a very simple and compact info panel, but if you click on the last row "Add Notes, Attachments, or URL"....
It expands to show additional fields.
How can I achieve this functionality of expanding and collapsing additional controls ?
Can this been done through interface builder and constraints ?
Take a look at Apples example code for NSStackView,
https://developer.apple.com/library/mac/samplecode/InfoBarStackView/Introduction/Intro.html
It will show you how to implement views that collapse and disclose. In Apple's example they do everything programmatically using auto layout constraints, although you could move some of the work to IB if you wanted to.
I would create the view you want and add a tracking area to monitor when the mouse enters and clicks (using -mouseDown: notification) the "Add attachments, notes, URLs" section and use the stack view method to disclose the details.
I’ve been reading through several books on Mac development, but cannot find the information I’m looking for.
The books all describe how to make floating windows or panes, but never mention how to make them all in one window. A simplified example of what I’m looking to create is shown below:
Basically, there will be three windows; A selector window with radio buttons to choose which NSDocument is currently being used, a window underneath that with buttons that show different windows to the right that allow viewing and manipulation of certain data.
For a example, each NSDocument may have a color value that can be set in the window shown by clicking view A, and some text strings that can be set in the window shown by clicking view B.
So the questions are:
Is it appropriate to use a single NSDocument sub-class for each Doc #1 and Doc #2?
Which classes should I use to set up the application as shown? NSWindowController? NSWindow? NSPanel?
I’m only looking for guidance on what to read up on, so any pointers are appreciated.
EDIT:
To clarify this further, I want to have a table view where the buttons are (View A & B), and by clicking them they will cause the other window/view to change it's contents.
It's like the split view in the iPad settings application, there is a table view on the left, and when it's pressed the right side changes.
The radio buttons are there only to illustrate that I want more than one Document. I'm guessing I need more than one to handle this? Or perhaps I should place them all in a single NSDocument? Somehow that doesn't seem right.
To achieve what you want you need one window (NSWindow), one window controller and various views each with their own view controller. There are several ways you could set this up, all depending on your requirements:
You'd have at least 3 views (instances of NSView): one for the selection of the document class, one for the view selection and one for the content. Each view is controlled by a view controller (instance of NSViewController). Additionally you can opt to wrap the views in split views (NSSplitView) so your user can resize the real estate available to each view.
You have one window with a window controller. If you choose a Document based app template in Xcode, Xcode will generate a subclass of NSDocument which you can use as your window controller (or choose to use Core Data and Xcode will generate a subclass of NSPersistentDocument with all bells and whistles you need to access Core Data for document persistency).
So to come back to your questions:
1: Yes, but depending on your requirements. If Doc #1 is a completely different thing than Doc #2 than you might need to re-evaluate. For example Doc #1 might have completely different persistent requirements than #2.
2: There's no single scenario here, but one that worked for me: Take the project template for a document based app (with or without Core Data). Use the generated subclass of NSDocument (or NSPersistentDocument) as your window controller. Use NSView to implement the views in your window where each view is managed by its own controller, which is an instance of NSViewController.
I know this is an old question, but a way to do it how you want would be to use: ContainerViews and set their embed segue to be the view controllers you want.
I think the title pretty much says it all... I'm looking to implement an interface similar to the standard OS X sidebar used in all the above mentioned programs, and I'm wondering if anybody has any thoughts as to the easiest way to do it, namely about what view to use for the left hand selection pane. Really I don't think I even need the hierarchical component as seen in the apple apps, I just need a good looking flat list of choices which determine what's shown in the right hand pane.
The obvious start is a vertical split layout view, but beyond that I'm not entirely sure where to go. A collection view with only one column or something like that?
I've done a few applications that use a similar setup.
I generally use an NSSplitView, with a single column NSTableView in the left pane. Don't forget to disable the headers, and make it display as a "Source View" style.
If you want the disclosure triangles, then you'll want to use NSOutlineView instead of NSTableView, but at least for the first go, I'd stick to a simple NSTableView.
A pattern I also use is to make the NSTableView slightly shorter than the NSSplitView, and have buttons at the bottom (add, delete, etc). I've usually built the program around Core Data, so it's easy to hook up these to methods to create/delete objects, and then bind the NSTableView to the array of objects.
Direct support for this sort of thing was added in Leopard. It's called a 'source list'.
Please see the AppKit release notes. Search for NSTableViewSelectionHighlightStyleSourceList in the document.
Or, drag out a table view and select Highlight: Source List in Interface Builder.
Let's say I have a split view, and I want to fill half of it with a table view (a fairly common use case, I would think). Is there any way to tell the table view to size itself to fit the split view or do I really have to size it manually?
I've done this, the way Jon Hess mentions first. Assuming you're using Interface Builder version 3:
Drag and resize your GUI (tableview from what I understand?) component to fit into the enclosing area the way you want it.
Click it to select it.
Press Command-Shift-I to open the inspector window for this GUI component. The inspector window should now actually show that you've selected a "Scroll View".
Click the "ruler" heading to be able to set the sizing. You'll see to the right an animated representation of how your GUI component will behave within its enclosing GUI component, and to the left another represenation of the same, without animation, but with four springs and two struts that you can turn on or off.
Turn all six things on, making them red.
Voilà :-)
It's generally easier to create the subviews first, then use the Layout/Embed Objects In/Split View menu item to create the split view around them.
As far as I know, doing it manually is the only way to go. However, if you turn on "snap to cocoa guidelines", the inner view will snap to the edges of the enclosing view as you drag towards them. This makes it easier than having to manually mouse the edges into place, or manually edit the sizes to match.
You can set all of the springs and struts of the table view to "on" in the size inspector and that will cause the table view to fill the split view. Alternatively, you can use the outline view in the main document window to place the tableview's enclosing scroll view directly into the splitview instead of in an intermediary custom view.