Re: Problem with 'collapsed' property in NSSplitViewItem
Re: Problem with 'collapsed' property in NSSplitViewItem
- Subject: Re: Problem with 'collapsed' property in NSSplitViewItem
- From: Bill Cheeseman <email@hidden>
- Date: Sun, 09 Aug 2015 14:59:45 -0400
Email to cocoa-dev:
I found a simple solution to uncollapsing split view items no matter how they were collapsed.
After I click a toggle button in my application to toggle the 'collapsed' property of the bottom split view item to true and it collapses, its 'collapsed' property is true because I set it to true explicitly in the toggle button's action method (or binding), and the 'hidden' property of its view controller's view is automatically set to true to hide it, presumably by internal NSSplitViewItem code. The view's origin.y and size.height values remain unchanged (both are positive numbers preserving the original origin and size of the bottom view before the collapse). As a result, the toggle button's action method does not have to bother remembering what the pre-collapse values were.
However, if I instead collapse the bottom split view item by double-clicking the divider or dragging the divider to the bottom of the split view, the 'collapsed' and 'hidden' properties remain unchanged at false. Instead, the view's origin.y and size.height values are automatically changed to reflect the fact that the bottom split view has been dragged down to nothing. In the case of dragging the divider to the bottom, the dragging operation has the expected effect of setting origin.y to the height of the split view (effectively placing the spit view item's origin at the bottom of the split view) and size.height is set to 0.0. In the case of double-clicking the divider, origin.y and size.height are set to their collapsed values automatically. This means that, after collapsing the bottom split view item by double-clicking or dragging the divider, it cannot be uncollapsed by setting the 'collapsed' property to false; it is already false, as is the 'hidden' property. Instead, the dimensions of the constituent parts of the split view must be reset to their former values, or to some default value like half way.
The result of this is that a toggle button easily collapses and uncollapses the bottom split view item simply by toggling the 'collapsed' property's value between true and false, without paying any attention to the pre-collapse origin and size. But after collapsing it by double-clicking or dragging the divider, it is necessary to reset the origin.y and size.height values to positive values that will provide something to see. I've incorporated this additional code into my application, and it is now working correctly.
I suppose the engineers may have come at this issue first from the perspective of collapsing a split view item by dragging it to the bottom, which of course changes the origin.y and size.height values. When they then realized that it would be convenient to have a double-click do the same thing, it must have seemed obvious to them that the origin.y and size.height values should still be changed, but by a simple programmatic operation, since double-clicking the divider is just a shortcut for dragging it to the bottom.
But I came at it from the other direction, reading the NSSplitViewController and NSSplitViewItem header comments and documentation, such as it is. I was focused first on implementing a toggle button, which is quite easy to do simply by toggling the 'collapsed' property. The idea of changing the origin.y and size.height values to collapse the subviews never even occurred to me. Why would anybody want to do that when 'collapsed' and 'hidden' are sufficient? Then I read about the double-click capability somewhere. I assumed that it, too, worked by setting 'collapsed' and therefore 'hidden' to true. But no matter how hard I tried I could not make the uncollapse case work; setting 'collapsed' to false accomplished nothing because, unknown to me, the metrics had been changed by the double-click so that the bottom view was 0.0 pixels tall.
It took me way too long to think of testing the origin.y and size.height values, and to discover that there is a complete disconnect between these two different ways in which NSSplitViewItem handles collapsing a split view item. I have found several years' worth of developer mailing list posts, none of which appear to have put the whole puzzle together for a comprehensive solution. The documentation and header comments offer no help whatsoever, containing not even a hint of these issues.
In my application, with very little code, a user can now collapse a split view item by double-clicking the divider, dragging the divider to the bottom, or clicking the toggle button, and they can uncollapse it by dragging the divider back up or clicking the toggle button again. It would be easy to make a double-click on the collapsed divider uncollapse it, too, and I probably will, but as far as I can tell that is not an expected design feature. (The divider is kept visible when collapsed using one of the NSSplitViewDelegate methods.)
--
Bill Cheeseman - email@hidden
_______________________________________________
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