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.
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.
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.
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.
Just like the UITableView on iphone.
users can remove or move a row on UITableView.
There is only one button to switch the UITableView to editing mode.
but for listbox on wp7 , I need 3 buttons, one for removing the selected row, one for moving the row up, one for moving the row down.
Welcome any comment
The Windows Phone ListBox doesn't support these features out of the box, but it would be possible to add them yourself using a DataTemplate.
Here's a blog post about creating a custom DataTemplate for your ListItems.
At a high level, you'll need to create a template that contains:
Enter edit mode button
Delete button
Sort up/down buttons
Then in your code, you'll need to toggle the visibility of the delete and sort buttons, as well as handle user clicks on each of the buttons. Doable, but a fair amount of work.
In my opinion, a better option would be to use a approach that's different from what you might be used to but is more familiar to Windows Phone users: the ContextMenu. This control allows you to pop up a menu when the user performs a long touch (tap-and-hold) on an item.
Here's a good tutorial about incorporating this control into your app.
Take a look at re-order ListBox here. It shows how to retemplate the ListBox.
For removing on item, you just need to remove its data source item. See how to use ObservableCollection.
If you want to show effect when an item is removed, use Event Triggers for the Unloaded event.
I want to use the same sort of UI style of Xcode has right above the editor pane, as show below:
I've browsed through all the Views in Interface Builder and can't figure out what type of view this is. At this point I'm merely referring to the bar itself; not to the controls nested inside the bar, though I will be adding dropdowns in the same way as this.
What type of view should I be looking for?
TextMate uses one along the bottom of the editor too, which provides similar controls:
see:
$(DEVELOPER_ROOT)/Applications/Utilities/Accessibility Tools/Accessibility Inspector.app
just open Accessibility Inspector.app and move the cursor over the views you're interested in for details (you may need to enable accessibility options in system preferences.app).
it's also helpful to press cmd+F7 to lock onto a view and then to inspect its children.
so... 3 primary options:
1) if you want drag & drop convenience, you can simulate it with a Gradient Button
2) or you can use the button with a custom image in the button to achieve something closer
3) or just create a new view subclass and render it using a CGGradient or NSGradient