Re: Merging scrolling/clipping with NSStackView
Re: Merging scrolling/clipping with NSStackView
- Subject: Re: Merging scrolling/clipping with NSStackView
- From: Daryle Walker <email@hidden>
- Date: Sat, 21 Jan 2017 06:06:30 -0500
> On Jan 19, 2017, at 1:25 PM, Quincey Morris <email@hidden> wrote:
>
> On Jan 19, 2017, at 06:39 , Daryle Walker <email@hidden <mailto:email@hidden>> 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@hidden)
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:
This email sent to email@hidden