On 03/07/2012, at 2:46 PM, Motti Shneor wrote: > have the feeling I "almost got it", and I even think I understand why and > when delegate methods are being called. Rolling out my own SplitView doesn't > seem to be easier than finding the answer to my question, because to inherit > from NSSplitView I'd still need to understand how "super" works won't I?. > Also I'll have to re-implement lots of behavior (animation, dynamics, > efficient drawing etc.) that might prove a big job.
True in part. But you could subclass NSView instead. After all, NSSplitView doesn't really bring that much to the table - it relies on inheriting NSView to store its subviews, the only thing it draws is the actual splitter itself, which is just a line (or narrow bar if you are using that style). In fact NSSplitView doesn't animate - if you want to make it do so, you have to add all the animation yourself (for example a panel sliding in and out of view). By the time you've got it bent to your will, you'll have written so much code in the delegate that you may as well have written a custom view class in the first place. It doesn't even give you a particularly easy way of setting the split position programatically. > I could re-state my question again even simpler --- I want to know what makes > NSSplitView respond with "YES" to the following: > > [mySplitView isSubviewCollapsed:panelSubview]; I think it's that the subview is hidden. > Is it just the subview being hidden? being zero-framed? being > vertically/horizontally transformed to zero? Does the NSSplitView maintain a > "collapsed" state member for each of its subviews? How can I set this state? > > and if anyone from Apple is on this list --- for god sake, why isn't there a > [mySplitView setSubview:panelSubview collapsedStateTo:YES/NO] ???? The subview isn't zero framed. Once upon a time it was, but that makes it an even bigger pain than usual to get it back into a sensible state if it contains further views that are autoresized. At some point, it was changed so that the view is maintained at its (minimum?) size and simply hidden. That's my current understanding anyway. Seems to me a sensible design for a split view would have simple properties like a min and max width for each subview and a sizing priority, and simple methods to show and hide each pane with or without animation. Maybe the newer constraints stuff helps but given that NSSplitView as it stands has to be backward-compatible with all the gnarly code that has gone before to make it work, it's always going to be awkward. It's surprising Apple persist with this class - they should implement a complete replacement which is not a subclass and then new code can adopt it without breaking old code. Just my 2ยข worth. --Graham _______________________________________________ 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
