Re: NSSplitView question - how to implement my own "adjustViews" style method
Re: NSSplitView question - how to implement my own "adjustViews" style method
- Subject: Re: NSSplitView question - how to implement my own "adjustViews" style method
- From: Motti Shneor <email@hidden>
- Date: Tue, 03 Jul 2012 11:03:01 +0300
Thanks again Graham and all the rest --- We're going somewhere now.
On 3 ביול 2012, at 08:22, Graham Cox wrote:
>
> 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.
NSSplitView also implements
1. Live resizing, with extra logic (when to collapse etc.)
2. Many small UI intricacies (e.g. when dividers fall off)
3. It implements Apple's standard visual appearance (which I want preserved, but also compatible with future changes).
4. It DOES animate (sometimes... e.g. when the NSSplitView is resized, its internal sub-views adjustment are animated. To experience that, just click the zoom button of any window of a sample program with a split-view).
5. It handles mouse and key events! (clickable areas, dragging, overlapping divider areas etc. For me, event-handling always seems to be the hardest thing to do. I don't want to do synchronous event-loops.)
6. It handles generic drawing of dividers.
7. It supports accessibility.
Isn't this a big job to re-implement? and how would I be "compatible with the future" ?
>
>> 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.
That's a BIG answer, if it is true. Can we get anyone from Apple to confirm that? In my current code I RELY on this assumption, but it has no confirmation in the docs.
>
>> 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.
NSSplitView header docs say that frame hight/width might be zeroed upon collapsing, but that Bounds should remain as they are. Maybe the docs are outdated? how can we confirm that now NSSplitView works with "isHidden" instead?
>
> 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.
>
Yay. I'd sure LIKE this kind of split-view! However, I think Apple already has it all in the new layout mechanism. Pity I can't use it in this project.
> Just my 2¢ worth.
Oh no... It's worth much more!
--Motti
_______________________________________________
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