> On Apr 3, 2017, at 1:52 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On Apr 3, 2017, at 08:57 , Daryle Walker <dary...@mac.com > <mailto:dary...@mac.com>> wrote: >> >> When I select the window in the window controller’s scene in the storyboard, >> its content size is 800x450. It doesn’t show that way on app run. The view >> that’s connected to it, a split-view (top & bottom), is still set to the >> default 450x300. The two splits are also at the default 450x300. The bottom >> split is a tab-view, whose two tabbed views are also at the default 450x300. > > Set the size of the split view to 800 x 450, and change nothing else, then > run the app. What size window do you get? What are the relative sizes of the > two splits? (Make sure you turn off window restoration, or the results will > be meaningless.) > >> I haven’t added any constraints yet. > > Your content almost certainly won’t lay out correctly when the window is > resized by the user at run time.
Since my previous post, I have added constraints. Split-view: none, since it doesn’t have any direct views. Table-view (top split): set the table’s surrounding scroll view to match its container view. Set its minimum width to 200, and minimum height to 150. Tab-view (bottom split): none, since it doesn’t have any direct views. First tab view: originally was going to be just a button, now it’s a button in front of a visual-effect view (using the (Inherited) Aqua colors). The view matches its container view and has its minimum width set to 200. It doesn’t specify anything for vertical, but the button has a fixed height and fixes its top and bottom margins to the standard value. (The button has a fixed width and centered horizontal positioning.) This indirectly locks the effect view to 61 points high. Text view (i.e. second tab view): same setup as the table view. All these views are still set to the default 450x300, except the first tab view’s height is 61. Now stretching out the split-view’s content rectangle…. And the run-time window is still short. Now stretching the table- and tab-views to 800 in width, but staying 300 in height…. And the window does have the expanded width. But I still don’t like how the header section takes over half of the height, even when the text view is active. (The header is always oversized when the effect-view is active, since its height is fixed at 61 points.) I’ll change the table-view height to 200, and the tab-view height to 250…. And the run-time proportions are still table-view-is-bigger when the text view is active. Maybe I need to tweak the text view’s scene too…. Nope, no further change. I want the header to be around a third of the height when the text view is active, while the text view takes the other two-thirds. I have a toolbar and have the window’s top matter (title bar and toolbar) go into the content area (like modern apps should). It’s weird seeing the table view’s data partially translucent behind the title- and tool-bars. When adjusting views’ heights for a top/bottom split-view, how should I account the splitters’ heights? Right now, I have the thin splitter. How high is that? >> It seems that I do have do design from the inside-out and guess the shrunken >> sizes of my components, instead of having my sizes from the outside-in and >> having auto-layout shrink the interiors. > > In IB you’re designing for *all* window sizes simultaneously, not for a > particular size. Auto-layout constraints *are* the design, not the rules for > adjusting the design. However, you have two complications: > > 1. By not having any constraints, you’re leaving it up to IB (or perhaps the > run-time constraints system, or perhaps some combination of both) to add > constraints (or constraint-like behavior) that attempts to preserve your > unconstrained design. You can’t really complain if if doesn’t do what you > want, since it doesn’t really know what you want. > > 2. The size of the outer container (the content view) is unconstrained, > because auto-layout is designed to work in both directions (the content view > can resize the window; the window can resize the content view). Something has > to resolve that ambiguity in each case. Sometimes explicit constraints within > the view will do it (and there are specific NSLayoutPriority values which you > can use to control the “direction” of the resolution), and sometimes the > window size is forced on the content (window restoration, or window > drag-to-resize), but if not, the NIB size of the content view sets the size > of the window. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
