> On Jan 19, 2017, at 1:25 PM, Quincey Morris > <[email protected]> wrote: > > On Jan 19, 2017, at 06:39 , Daryle Walker <[email protected] > <mailto:[email protected]>> wrote: >> >> The inner views should be as tall as they need to be. > > I don’t understand this part. How tall is that? > > I assume you mean that you want the text and table views to be tall enough to > show all of their contents, then stacked together and wrapped in a single > scroller. Conceptually that makes sense, but: > > 1. The stack view is going to size itself, in the absence of explicit > constraints, based on the *intrinsic* sizes of the stacked views, and neither > text nor table view is going to report its full height as its intrinsic > height. Re-working them to provide that information is going to be very, very > painful. > > 2. Neither text nor table view is *intended* to be full height. Instead, they > are intended to show a “window” of a fixed height onto a much taller virtual > height. That’s why they come pre-wrapped in individual scroll views. A table > view in particular is intended to prepare only the (relatively few) cells > that are actually visible at any one time. By forcing it to its “full” > height, you’re forcing it to keep every row in existence permanently. The > performance might be acceptable if the table is not very large, but it’s > still something of an abuse. Ditto the text view, although less so. > > In such a situation, I think I would do one of the following: > > — Rethink my UI so that I don’t have to stack the text and table views in > this way.
I think I’ll just do a NSSplitView and be done with it (for now). > — Use only a table view, and place the text view as the first row of the > table. (With view-based table views, it’s easy to have more than one > prototype cell view.) It would still be a bit messy, since it would be a > variable-row-height table, but it’s likely less work than trying to achieve > the same effect using stack view constraints. I just perused the Table View Programming Guide, and it wasn’t obvious what I would override. And I would want the text view as the last row. I’m guessing it would involve a complicated table delegate, and wouldn’t be able to use bindings (as much). > — Use a (new-style) NSCollectionView, using two sections and custom flow > layouts for the sections. Sounds interesting, but still has the same problem of table and text views weren’t designed to be fully expanded. Also, this surprise view layout would take away time from the interesting Core Data stuff I want to try. (I haven’t done basic load/save yet.) If I get to the point of publishing, you could add a pull request…. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
