As shown below I have a NSScrollView with 2 panels (3 actually but not shown in the image). I am wondering if this is simply a performance issue or something more erroneous to do with auto layout?
Neither of the views are particularly complicated or have very complicated constraints. The left view hierarchy is,
Left NSSplitView's view
|-- Custom view NB lowered the trailing priority here... view]-(0#250)-|
|--NSTextField
|--NSTableView
The most advanced thing I did was to lower the priority which attaches the container view to the superview. this is because I want the panel to be able to cover up the left hand side without the left hand side resizing. When the divided is fully to the left the views there still have the same size it's just that the right panel now is above the view left panel's views.
Is there a better way to achieve this effect?
What could be causing this drawing artefact?
Related
I have a window with two custom views stacked on top of each other. I use auto layout constraints, as follows:
Top view leading, top, and trailing edges are tied to superview.
Bottom view leading, bottom, and trailing edges are tied to superview.
There is a fixed vertical space constraint between two views.
Bottom view has a fixed height constraint.
Top view has a it's compression resistance set to 751.
So far so good. The idea is that the bottom view height is fixed and as the window is resized, the top view height adjusts to compensate.
Both top and bottom views have other views/controllers loaded in, as appropriate. The bottom view ends up containing an outline view with a half-dozen entries. I would like that outline view not to scroll. In other words, I would like to automatically adjust my bottom view fixed height constraint to match the height of the outline view required for it not to scroll.
Ideally, I'd prefer to solve this with auto layout without having to write code. But, if that's stretching beyond what auto layout can do, code help would be appreciated as well.
I have a window into which I horizontally add two subviews. Into each subview, I place a variable number of subviews made up of a vertical slider, a text field rotated 90 degrees and placed to the left of the slider and another textfield, placed just under the slider. The slider subview's constraints are done in code, the parent views are both done in IB. When I add more slider views to the left window than the subview can handle in its default size, it resizes horizontally and forces the window's content view (and window) to also resize horizontally. Great, that's just what I want. But if I add more slider subviews than can fit in the right subview, they just get squeezed together and the subview does not expand as the left. I layout the slider views using code with this category converted to support NSViews, instead of UIVews:
UIView+AutoLayout1: https://github.com/jrturton/UIView-Autolayout
The constraints for the left and right subviews are more or less the same. I can't figure out why the right view does not resize as the left view does.
Here is a link to a sample project that demonstrates the problem:
SliderTest
Some someone help me out with this?
Also, a secondary question as I think my slider view could use a little work:
When a view is rotated using setFrame(Center)Rotation, do the top, right, bottom and top edges remain along the same edges or do they reflect the new orientation of the rotated view?
Thanks
I found the problem. The constraint between the left view and right edge of the window was fixed at 233 instead of >= 233. I had this at some point in the past, as I was adjusting the constraints to achieve the desired behavior and just overlooked this one through the troubleshooting process.
I have a window I'm setting up with auto layout. There is a view in the middle of the window that contains three controls, and I would like the window to refuse to resize horizontally smaller than the intrinsic size of those three controls.
The outer buttons both have horizontal space constraints to "stick" them to the outside of their superview, and the checkbox in the middle has a horizontal space constraint sticking it to the left side of the "Sync text" button. There is also a >= constraint between the "Sync outline" button and the checkbox, to make sure they don't overlap, but the checkbox prefers to hang to the right. All these constraints have a priority of 1000. The window itself has no minimum size specified.
When I use the "Simulate Document" command in Xcode, everything works as I'd expect, and the window won't let you size it smaller than in the screenshot above. However, when I run my application, the window does allow resizing smaller than that width, so that the buttons start to shrink and eventually the controls overlap each other. I'm not implementing any of the size related window delegate methods, so I don't see any place in the app's code where it might be influencing the resizing.
Any ideas on what could be causing this difference in behavior?
OK, I finally figured out what the heck was going on here. It turns out the problem was that I was implementing the -splitView:constraintMinCoordinate:ofSubviewAt: delegate method (as well as the maxCoordinate one) to restrict the size of the split subviews in the vertical direction. Yes, restricting the vertical resizing of the split view affected the horizontal layout of the buttons.
It appears that what happens is that, if you implement those delegate methods, NSSplitView reverts back to using autoresizing masks to layout the subviews rather than auto layout constraints. Since the view containing those buttons is no longer participating in auto layout, the buttons smush together when you resize the window small. In the simulator, the split view doesn't have a delegate set, so all the auto layout stuff works fine in that environment. Note that merely having the methods implemented is enough to trigger this, even if they just return the proposed coordinates unchanged.
The solution ended up being quite easy, which was to delete the delegate methods and replace it with a vertical constraint on the subview to restrict its size instead.
Ok. I've been at this over and over. I've seen blogs and cocoa dev threads.
I've seen Kyle Sluder's proposed solution, but have yet to find a solution that really works.
How can you position subviews of an NSScrollView with auto layout?
Is it just silently broken ?
Nothing seems to work.
Ok, old question, but this particular issue is a personal bugbear of mine so I'll answer it anyway!
The first thing to note is that an NSScrollView contains an NSClipView, which itself has a view outlet called documentView. These are all added for you when you drag a new scroll view into your storyboard or nib file. By default, the document view is an NSView called simply "View". If you're using a custom view, you can just select this and set its type in the inspector on the right to whatever you want. Otherwise, you'll be adding subviews to it.
The big thing that is easy to miss here is that, by default, the document view has its layout set to 'Translates Mask Into Constraints'. This is fine if the content size will never, ever change, and if that's the case you can simply set the frame of the document view to whatever you want and leave it at that. If you want it to automatically resize itself to fit its content however, there's a few things you'll need to do.
First off, that document view needs to have a completely unambiguous size. If you're using a custom view, I'd recommend giving it an intrinsicContentSize. You should also set 'Intrinsic Size' in IB's inspector to 'Placeholder' and give it a suitable value, or you'll get a bunch of autolayout warnings. If your document view gets its size from its content, all of the subviews must be linked in an unbroken chain from top to bottom, and from left to right, such that the content knows exactly how big it ought to be. This is quite an art in itself, so I won't go into it. A simple example where you have only one subview would be to pin its top, bottom, leading and trailing constraints to its parent, but as noted above if you're doing this, you might as well just set the type of the document view.
Now the fun bit. Select your document view and set its layout to 'Automatic'. Next, add top, bottom, leading and trailing constraints to its superview with a suitable value. I'm using zero, but you might want a small border. Finally, select the TRAILING and BOTTOM constraints you just made and set them to '>=' (greater than or equal) and a priority of 500 or less. The priority is very important, as it has to be less than the priority that the clip view uses to determine its own minimum size. Too high and the clip view will be forced to remain larger than its content, making it impossible in turn for the scroll view to be smaller than its content, rendering it useless.
The technical details aren't important. Just remember to set the document view to layout: automatic, pin all edges, and make the trailing and bottom constraints >= and priority 500.
Note that this will cause your content to hug the top-left corner.
Have you tried setting the document view's setTranslatesAutoresizingMaskIntoConstraints to TRUE?
[_scrollView.documentView setTranslatesAutoresizingMaskIntoConstraints:YES];
I'm trying to create a timeline control in Cocoa. This is what I am trying to achieve. It's basically a standard timeline design.
However, I don't know which approach to take. The problem lies with the top ruler, the left track list and the bottom audio waveform display. These three parts need to always be visible and 'stick' to the edges. The ruler and audio waveform should only scroll horizontally, while the track list on the left should only scroll vertically.
For the top ruler, NSRulerView seems appropriate since it's just a ruler.
For the left view and the bottom view I don't know which route to take. I've played with using a wide vertical NSRulerView for the track list. This works but creates additional problems. For example: the top ruler appears above the track list.
I've composed four options so far:
Forget NSRulerView and draw everything custom in the document view. This seems feasible but sidesteps built in NSRulerView functions. Also, I need to find a way to shorten the scrollbars so they don't overlap the side and top views.
Use NSRulerViews for the top and left side. The bottom side will then probably be drawn manually in the document view.
Place the left view outside the scrollview and manually scroll it up and down by linking it to the main scroll view. Use NSRulerView for the top, manually draw audio waveform in document view.
An NSScrollView embedded in another NSScrollView. The outer handles horizontal scrolling, the inner scroll view handles vertical scrolling. Possible I think, but it seems hacky.
So my question boils down to: Which route to take?. Can anyone shed some light on this issue and point me in the right direction?
What I understand:
You want a view to the left of an NSScrollView which scrolls vertically with the NSScrollView while ignoring horizontal scrolling.
You want a view below an NSScrollView which scrolls horizontally with the NSScrollView while ignoring vertical scrolling.
You want rulers.
To achieve this task:
Use 3 separate scroll views which do not overlap and donot inherit one another.
Activate rulers in whichever view(s) you would like them to appear.
Synchronize the scroll views (so that when one scrolls, the other scrolls accordingly).
How to synchronize scroll views is in the help. See User Experience > Controls > Scroll View Programming Guide for Mac > Synchronizing Scroll Views. This is also indirectly linked in the header of the help guide for NSScrollView.
If you want the three scroll views to be contained within an NSSplitView for resizing simplicity, then a fourth view must be added to consume the unused corner (good place to put controls). Since an NSSplitView can only be split vertically or horizontally, you will have to create an NSSplitView containing 2 split views with each of those split views containing 2 views that you actually see (splitting in one direction and then the other). The resizing of the split views will have to be synchronized in a manner much like the scrolling is synchronized to retain a straight cross of all four views.