In order to categorize a wide variety of unique views, I have an elaborate setup: main categories are selected via a toolbar, and then specific panes are selected in a category's NSScrollView. This looks like: window -> NSViewController controlling five views -> sub-NSViewController for each view controlling X views -> each view contains a core-plot graph. In short, nested NSViewControllers with a core-plot CPLayerHostingView at the end of nearly every path.
Before I even get to my question, feel free to point out that this is a poor implementation. In terms of user-friendliness, I think it makes sense, but the sheer number of nested objects makes me wonder if there's a better way.
Now then, assuming I've designed it the best possible way, the question itself: suppose I have selected a category and then a sub-item within, and am looking at a rendered graph. I desire the graph to resize appropriately if the window is resized. In Interface Builder I have done everything necessary to make this happen: everything from the CPLayerHostingView to the NSView in the main window have been set to autosize in all directions. Despite this, if I resize at runtime, the graph stays still and does not resize or move. In a design with zero or one NSView tiers this would be much simpler to debug, but I'm out of ideas in this scenario.
What tricks, programmatic or IB-based, can I use to make sure an NSView resizes according to a window resize many, many levels up?
Not only do you need to set the springs and struts, but you also need to make sure "Autoresizes Subviews" is checked.
Related
I'm currently working on a prototype for a todo type app. I have a table which contains the user tasks. What I want to do is only present the user with pertinent task information. But to edit additional information, they would click on a disclosure button to expand the cell.
I was thinking of two possible ways to handle this:
Expanding NSTableViewCell
Using an NSStackView as the contents of each cell
If using the NSTableViewCell, I would probably have two NSViews to represent the cell (top part and lower part).
If using the NSStackView, I'd have an easy means of encapsulating the parts.
I suppose another method could also be just building it entirely with NSStackView.
The more difficult aspect of this seems to be related to the actual expansion/collapse of the cell.
I understand this could be deemed the type of question that's asking for an opinion. I've never built a MacOS app. So I'm looking for some guidance as to the best method to approach the problem versus spinning my wheels on approaches that are destined to not be productive.
Thanks!
In the end, it looks like the best thing to do is use an NSTableCellView with two NSViews for the top and bottom half. I had the case of this as well as the NSStackView working. But in the end, I found that using NSStackView to collapse or expand requires a call to make noteHeightOfRows work anyways.
So it would initially seem that it's not worth the effort of expanding it unless I have a more complicated cell where say I wanted a top, middle, and bottom, where the middle could expand and contract. While I would still need to use noteHeightOfRows, it would allow for it.
However, there is one benefit of using the NSStackView. The animation is much smoother for the collapse. I've found the NSTableCellView method with a top and bottom NSView shows signs of "tearing" as it collapses. This is what appears in the bottom edge, while horizontal, jitters. This is particularly apparent if you either spam the button or if the cell is selected because the bottom of the outline can sometimes grow in height.
I also found that when using NSAnimationContext to help make it look a little smoother, I'd see strange behavior. Like the hide would happen at the wrong time (even though it was in the completionHandler. I think the root cause of that are what becomes overlapping animations.
First time building a user interface, had a few general questions
1) Does it really matter if you drag and drop view objects into view controller.. or if you programmatically add subviews and specify frames and fonts? What's the better approach to take?
2) In the programmatic approach, I end up guessing frame values, (x,y) points, and then checking in simulator if I like it. Is this the right approach, or are there faster, better ways to build out the UI? Maybe methods I'm not aware of?
3) Any useful tutorials/pointers in the right direction on how to get started?
Thanks!
1) Both approaches are fine, but the Interface Builder is usually better if you have a more static UI. In a more dynamic app (where views appear and disappear, or if you use UIViewController containment), you need to add/show/hide some of the views in the code. Even in that case you can design individual views in the IB, to make sure they look good, and then instantiate and display them in the code.
2) If you design your views in the IB, then the problem of guessing the sizes largely disappears. In some cases it can be useful to have an empty view added in the IB, which acts as a placeholder for your dynamic content. Then, when you add a view to it in the code, you just use the superview's dimensions so your view fills the placeholder.
I want an NSView that can be resized by dragging its the bottom right corner around, just like an NSWindow. I want to be able to embed this NSView into a parent NSView. Is there a component like this in Cocoa or any of its extensions?
If you get more specific with your question, I can get a little more specific with the answer. :-)
There is nothing like this available that I know of, but it's not terribly difficult to create. The decision to make is "who handles drawing the resize grips and resizing / dragging logic?"
Views Handle Their Own
If your user-resizable view handles drawing the grips and responding to the resizing/dragging actions itself, then you have to choose whether you want the grips drawn atop the view's contents or "around the outside." If you want the grips "outside," the "usable area" decreases because your content has to be inset enough to leave room for you to draw the resizing controls, which can complicate drawing and sizing metrics. If you draw the grips "atop" the content, you can avoid this problem.
Container View Handles All Subviews
The alternative is to create a "resizable view container view" that draws the resize grips around any subviews' perimeters and handles the dragging/resizing logic by "bossing the subviews around" when it (the container) receives dragging events on one of its grip areas. Placing the logic here allows any type of subview to be draggable / resizable and gives you the added benefit of only having one instance of the slightly-heavier-weight view (versus many instances of subviews that have the more complicated logic in them).
The Basic Mechanism
Once you've decided that, it's really just a matter of creating your subview, which does the drawing, manages NSTrackingArea instances (for the grip areas), and responds to the appropriate mouse methods (down, moved, etc.). In the case of each subview handling its own, they'll manage their own tracking areas, grip drawing, and mouse moved, setting their own frame in response. In the case of a container view handling all this for its subviews, it will manage all subviews' tracking areas and draw their grips on itself, and set the targeted subview's frame (and the subview is blissfully ignorant of the whole thing).
I hope this helps give you at least a general idea of possible mechanisms. Had I not just gotten up and started my morning coffee, I'd probably be able to write this more succinctly, but there you have it. :-)
EDIT 7 YEARS LATER
Because there wasn't much detail about what the OP wanted, I gave a very generic answer, but I should make a few points:
Always prefer an NSSplitView if it can be made to work for you (ie, if the views align with each other and divide the common container view's space). A split view lets you customize grip areas, etc. and does all of this to your subview for free.
AutoLayout didn't exist when I wrote this answer and it greatly complicates rolling your own solution for the view-handling-multiple-sizable-subviews scenario.
If you really do need a UI element that can be dragged/resized within some container, try your best to get away with using CALayers inside a master view that handles all the layout/sizing logic if you can.
If you can't do the above (ie, the resizable view contains complex controls and layout, has its own NSViewController, etc.), try a hybrid approach (use layers to display cached images of non-selected views and only add a full, interactive sizable subview for the selected item (or subviews for items).
Because of the complexities of AutoLayout, I really can't recommend the real draggable subview approach at all unless it's unavoidable. If you're designing a view that contains movable, sizable things, it's best (and most efficient) to make everything inside it that view's responsibility. Example: a graphics app with lots of shapes should have a Canvas view that represents the shapes (and any GUI decorations like size/drag grips, etc.) using CALayers. This takes advantage of graphics acceleration and is far more efficient than a bunch of (very resource-heavy) NSView subviews. All the move/size/select logic is handled by the "Canvas View" and the only subviews might be overlaid controls (though if your Canvas itself needs to be enclosed in a scroll view, it's best to use NSScrollView machinery to allow stationary overlay views for this purpose).
If designing a view that draws lots of things (for which you should definitely use layers to represent those things) but allows selecting only one thing, the approach of adding a subview is manageable enough even with AutoLayout. If the "selected for editing" thing has lots of complex controls that become visible when editing, an "editor subview" with accompanying view controller makes sense and is a good tradeoff in maintainability (because view controller compartmentalizes all editing functionality/UI handling) vs. container view complexity (because one subview isn't going to break the resource bank and maintaining temporary AutoLayout constraints for keeping its position during container view resizes & editor interactions isn't overly complex).
All of this assumes macOS; if designing for iOS, definitely bend over backwards to use layers and the new (as of this writing) drag and drop machinery, of which I know precious little at present.
In summary, the answer was incomplete as well as somewhat outdated, so I feel my original advice isn't as good as it could be these days.
Instead of using views, you can use windows and set the style mask of the window to NSResizableWindowMask.
Another option is using an NSSplitView, if you have two resizable, contiguous subviews.
I’m starting to develop my first full-blown Cocoa application containing a view which I would like to behave (and look) similar to Automator’s AMWorkflowView.
The basic features I’d like to achieve:
Positioning of subviews
Display of subviews in expanded / collapsed states
Multiple selection
Drag and drop
In order to get accustomed to Cocoa, I started with a custom NSView which mainly served as a container for the custom subviews and handled their positioning and multiple selection.
The subviews are also subclasses of NSView, and contain a variable amount of views themselves, like buttons, labels and popup menus, and therefore can have different heights.
This worked quite well, but before going on, I want to make sure to have everything neat and tidy according to the MVC pattern.
I suspect that there already is a class in Cocoa that facilitates the implementation of a view container, like maybe NSCollectionView.
It seems that there is no (easy) way to display differently sized views in an NSCollectionView, though. Should I continue implementing my custom NSView (probably using an NSArrayController for selection and sorting support), or are there better ways to go?
Any help is much appreciated
Unfortunately the answer is you'll have to roll your own. NSCollectionView does not allow for variable-sized items (which also rules out expanded/collapsed states).
For a limited number of items, you can accomplish this rather easily (you just need a container view that arranges the subviews properly when asked to layout, then you need to make sure you re-layout when things change). For many subviews, however, you'll need to take care to be as efficient as possible. This can start with laying out as little as possible (only those "after" the resized view, for example) and get as complex as caching a visual representation of a prototype view, drawing the cached images (fast!) for all but the view being edited, and only using/positioning a "real" view for the view being edited.
Drag and drop works the same as it always has, but none of the above accounts for the pretty animation NSCollectionView gives you. :-) It's fast and beautifully-animated precisely because all the subviews are uniform (so the layout calculations are fast and simple). Once you add irregular sizes, the problem becomes significantly more complicated.
The bottom line: If you need variably-sized views, NSCollectionView will not work and you'll need to roll your own or find someone else's shared code, but performance and beautiful animation will not be easy.
I'm relatively new to Cocoa programming, but I've managed to figure a fair amount out. One thing I haven't been able to figure out yet is how to have an element that is visible over all views. Like a volume control that is always visible just above the tab bar at the bottom of the screen.
How should I go about doing that?
If you just need to bring a view to the front, you can use bringSubviewToFront:, like so:
[self.view bringSubviewToFront:yourSubview];
If you need to position subviews so that they overlap in a certain way, you'll want to make use of CALayer. Just be aware that overlapping UIControl elements goes against Apple's Human Interface guidelines.