Cocoa: rearrange subviews when parent view resizes - objective-c

I have an NSView with a number of subviews (e.g. NSLabel). I want these subviews to be aligned in a row, but if the parent view doesn't have enough width, I want the subviews to be wrapped to the lower leftmost space - just like words in English text when the line cannot fit them all.
I thought it can be done with Auto Layout, but I can't make it work. When my simple window with two labels and simple horizontal constraints resizes, the labels just overlap each other. Instead, I need the rightmost label to "jump" to the lower leftmost position.
How can it be done? Should I keep researching the Auto Layout feature?

Related

Use Page Width when printing NSTableView instead of the view width

This seems like it should be simple...
I have a basic NSTableView in a window. The window is arbitrarily resizable (width + height). The tableview is pinned to the edges of the window and it has a single column that contains view-based table rows. The table rows have content pinned to the left and right edges of the cells, so as you resize the width of the window, you are effectively adjusting how much white space is in the middle of the cell.
I'm now trying to implement printing for this tableview. When I set up the NSPrintOperation, I'm passing my tableview subclass as the view to print. My desired result is this: I want the width of the tableview to be resized to the width of the page (regardless of how wide the window is right now on screen). I don't want to adjust the scaling factor (because that affects width + height) - I simply want the result to be as if I manually resized my window to exactly match the width of a printed page and then hit "print".
I've tried setting horizontalPagination to .fitPagination - but the problem there is that seems to apply a scaling factor to the width + height (which means if the window is currently "very wide", it makes the row height really small as it compensates for the width).
I've tried overriding adjustPageWidthNew:left:right:limit: in my tableview subclass - but that never gets called.
I suppose I could create a duplicate tableview and re-set it up exactly like the one I have on screen, but that feels like overkill when the view I want is already good to go - I just need to temporarily resize the width while I'm printing.
Any ideas?

NSStackView / NSScrollView - bisected NSStackview subview?

this is going to be hard to explain.
I am modifying the InfoBarStackView sample code from Apple.
The problem that I am encountering, is that it looks as if one of the subviews is being divided in two, by NSStackview and rendered separately.
In my sample, I am adding 4 subviews to my stack view, each exactly the same size (and same code). This is then placed into an NSScrollView. (The layout is vertical.)
When the application is run, I see the very first two subviews. When I scroll downward, the weirdness begins. The subsequent view is rendered, where the bottom portion is rendered, then the top is rendered. If the vertical size is 272 pixels, the bottom is rendered as 256 pixels and the top is the remainder (16). Scrolling down to the last view causes the same problem.
Attached are some screen grabs to illustrate:
I have a sample project for Xcode 8. I have posted the Xcode 8 project here, if someone would like to take a look. I can't seem to figure this one out.
Are you referring to the extra bounding boxes that intersect the "Label" and "Show" buttons?
If you use Xcode's View Debugger to look at the decomposition of the view hierarchy and the drawn contents of each view, you'll see that the extra bounding boxes are drawn by the GT_BorderedViews — that is, the bottom GT_BorderedViews are each drawing two bounding boxes.
GT_BorderedView's implementation of -drawRect: calculates and draws the bounding boxes based on the dirtyRect that is passed in. However, as the documentation states, the dirty rect is «a rectangle defining the portion of the view that requires redrawing», not necessarily the entire bounds of the view. Changing the implementation to calculate and draw the border based on [self bounds] instead of the dirty rect results in the expected appearance.
Taylor nailed it. I didn't realize that drawRect didn't render the whole view. Using [self bounds] rather than dirtyRect ensures the draw happens properly.

OS X chat app with resizable bubbles

I'm building chat application for Mac OS, similar to iMessage. I wonder, how can I implement resizable text views in bubbles. I mean, when I resize chat window bubbles with text will resize to. Any ideas, links will be very useful. Thank you for help)
For text resizing, you use auto layout. If you have an NSScrollView containing MYBubbleViews containing NSTextViews, you can add NSLayoutConstraints using the leftAnchor and rightAnchor properties of the scroll view's content view and those of the bubble view, and add constraints between all edges of the text view and bubble view. Then pin the bubble views to the top/prev view.
Also make sure you set the NSTextView to wrap. The width of the intrinsic size of the text view will be set so that it fills the width and the intrinsic height will be set to fit the whole text.
I previously thought it was about drawing the bubbles, so I first gave this answer:
If you look at Messages.app, you'll see that they're not circular bubbles. They are basically composed of several shapes overlaid on each other. A rectangle with rounded corners, plus a bezier path of the tip.
So you should be able to take a NSTextView for the text, make it a subview of a custom view that draws a rounded rectangle and the tip in its drawRect method, and then use auto layout constraints to make your bubble view resize with the text view and the text view to the window width.
You could probably also have the bubble view host a CALayer with fill and rounded corners, plus one with an image for the tip (or aCAShapeLayer for the tip), but drawRect is the easier approach.

custom view-based nstableview resizing

I have an NSView class, which draws it's contents on a CALayer. These NSView classes are held in an NSTableView which has a single column. I need to make it so the NSTableView adjusts it's size to fit the contents of the NSViews it contains, which can have variable widths, i.e. the NSTableView needs to have the same width as the widest cell. This in turn will allow the user to scroll if the cells' widths are larger than the available area.
Think of it like a multitrack audio editor, where each view is a track, but the tracks can have different lengths.
At the moment, the NSView cells seem to adjust width automatically to the size of the table column, so I can see two possibilities: One is to make it so the cell NSViews set their width, and somehow have this promulgate everywhere else. The other is to have the tableview or nstablecolumn set its width based on the maximum width. I have tried setting the NSTableColumn width and minWidth, but this doesn't seem to work (it doesn't always adjust to the correct size, if the size is big).
Any suggestions or help to make this work?
If you're using CALayer (lets call it root layer) to draw the view contents, try to create another CALayer which will be a child of the root layer (this would be the audio track). You can set the size of the child layer independently and also you will know which one is biggest.
Root layer will always be as big as the table view, as you said:"NSView cells seem to adjust width automatically to the size of the table column" - don't try to change root layer size, but child layer size.
Once you determine the widest child just change table view frame to be the same width.

Springs in Auto Layout: Distribute views evenly, with constraints, in Xcode 5

I understand the old Struts and Springs method of aligning, sizing and distributing views in Interface Builder. However, I cannot seem to figure out how to evenly distribute views using auto layout with Xcode 5. There was a way to do it using Xcode 4, but that option is gone.
I have 7 buttons arranged in a vertical stack. On a 3.5" layout, it looks great. When I preview the screen in the 4" layout, all of the buttons remain tightly packed and there is a large amount of space below the last button.
I want them to stay the same height, but I want the space between them to be able flex so they can spread out across the screen.
I've been able to get the height of the buttons to flex and fill the space, but that is not my desired behavior. I would like to learn how to use Auto Layout to replace my old Springs behavior, but I can't seem to find any way to do it through Interface Builder.
I'm ok with the top button either being a fixed space from the top edge or a proportional space from the top edge, likewise for the bottom button and the bottom edge. Those are less important to me, I'm good with either.
But I really need to figure out how to evenly distribute the extra space between each of the items in the view.
EDIT Note that in iOS 9 this technique will become unnecessary, because a UIStackView will perform distribution automatically. I'll add another answer explaining how that works.
How to Perform Even Distribution Using Autolayout
The simplest way to do this in Interface Builder alone (rather than constructing constraints in code) is to use "spacer" views:
Position the top and bottom buttons absolutely.
Place spacer views between all the buttons. Use constraints to position them horizontally (centering them horizontally is simplest) and to set their widths.
Make constraints between each button and the spacer view above and below it, with a Constant of 0.
Now select all the spacer views and set their heights to be equal.
The first screen shot shows me setting this up in IB:
I have deliberately not corrected for the "misplaced views" because I want you to see what it looks like while I'm designing the constraints. Here's the result on both a 4 inch and a 3.5 inch screen:
I have left the spacer views black, just to show you how this technique works, but of course in real life you would make them transparent and hence invisible! So the user sees just your buttons, evenly distributed on either height of screen.
The reason for the use of this technique is that although the notion of equality performs the distribution of values you are asking for, constraints can apply equality only between aspects of views; thus we need the extra views (the spacer views) so that we have things we can make equal to other things (here, the heights of the spacer views).
Other Approaches
Obviously, a more flexible approach is to assign the constraints in code. This may sound daunting, but there's a lot of third-party code out there to help you, such as this sort of thing.
For example, if we have a (possibly invisible) superview whose height acts as a boundary to dictate maximum vertical distribution of our four buttons, we can pin their tops to the vertical center of that superview with a constant of 0 but a multiplier of 0.000001, 0.666667, 1.33333, and 2.0 respectively (if we have four buttons); now the buttons will stay vertically distributed even as the superview changes size in response to screen height or whatever. [In Xcode 5.1, it will be possible to set that up in Interface Builder, but in earlier versions of Xcode it is not possible.]
In iOS 9 / Xcode 7 this problem will be trivially solved in IB. Simply select the buttons (or whatever it is you want to distribute vertically) and choose Editor > Embed In > Stack View. Then you simply configure the stack view:
Provide constraints that position and size the stack view itself. For example, pin the four edges of the stack view to the four edges of its superview.
Set the stack view's attributes. In this case we want Vertical axis, Fill alignment, Equal Spacing distribution.
That's all! However, you may be curious about how this works, because it is still possible to do the same thing manually in code. A stack view performs distribution, not by inserting spacer views, but by inserting spacer guides. A guide (a UILayoutGuide) is a lightweight object that behaves like a view for purposes of layout constraints, but is not a view and therefore doesn't have to be made invisible and doesn't carry any of the overhead of a view.
To illustrate, I'll do in code what the stack view is doing. Presume we have four views to distribute vertically. We assign them constraints for everything but their distribution:
They all have absolute height constraints
Their left is pinned to the superview's left, and their right is pinned to the superview's right
The top view's top is pinned to the superview's top, and the bottom view's bottom is pinned to the superview's bottom
Now, presume we have references to the four views as views, an array. Then:
let guides = [UILayoutGuide(), UILayoutGuide(), UILayoutGuide()]
for guide in guides {
self.view.addLayoutGuide(guide)
}
NSLayoutConstraint.activateConstraints([
// guide heights are equal
guides[1].heightAnchor.constraintEqualToAnchor(guides[0].heightAnchor),
guides[2].heightAnchor.constraintEqualToAnchor(guides[0].heightAnchor),
// guide widths are arbitrary, let's say 10
guides[0].widthAnchor.constraintEqualToConstant(10),
guides[1].widthAnchor.constraintEqualToConstant(10),
guides[2].widthAnchor.constraintEqualToConstant(10),
// guide left is arbitrary, let's say superview margin
guides[0].leftAnchor.constraintEqualToAnchor(self.view.leftAnchor),
guides[1].leftAnchor.constraintEqualToAnchor(self.view.leftAnchor),
guides[2].leftAnchor.constraintEqualToAnchor(self.view.leftAnchor),
// bottom of each view is top of following guide
views[0].bottomAnchor.constraintEqualToAnchor(guides[0].topAnchor),
views[1].bottomAnchor.constraintEqualToAnchor(guides[1].topAnchor),
views[2].bottomAnchor.constraintEqualToAnchor(guides[2].topAnchor),
// top of each view is bottom of preceding guide
views[1].topAnchor.constraintEqualToAnchor(guides[0].bottomAnchor),
views[2].topAnchor.constraintEqualToAnchor(guides[1].bottomAnchor),
views[3].topAnchor.constraintEqualToAnchor(guides[2].bottomAnchor)
])
(Obviously I could make that code cuter and shorter using loops, but I have deliberately unrolled the loops for clarity, so that you can see the pattern and the technique.)