Is there a "conventional way" to implement parallel divider bar motion in
an NSSplitView?

While resizing a window, I get the general behavior I want by setting the
holding properties of 3 view split view to 200, 250, 100 respectfully.
While randomly resizing the view, the 3rd view collapses first, the first
view follows leaving the 2nd view intact for the most part.

But how to do this while dragging dividers around? Holding priorities don't
work there and as soon as I start implementing split view delegate methods,
the holding priorities start to not hold true.

That said, I've tried doing this via delegate methods and gotten pretty far
until the parallel movement thing (If you make the 1st view bigger, I want
the 2nd view to move over and shrink the 3rd view) but when I try to use
something like setPosition:maxXOfView0+300 ofDividerAtIndex:1 from within
the splitView:constraintSplitView:ofSubviewAt - I get some sort of loopback
effect and the first view jumps way up in size and things start flickering.

- (CGFloat)splitView:(NSSplitView *)splitView

constrainSplitPosition:(CGFloat)proposedPosition

         ofSubviewAt:(NSInteger)dividerIndex {

    if (dividerIndex == 0) {

        NSRect rect = _sourceContainerView.frame;

        CGFloat maxX = NSMaxX(rect);

        CGFloat position = maxX + 300;

        [splitView setPosition:position ofDividerAtIndex:1];

    }

    return proposedPosition;

}

Do I need to wait for something like splitViewDidResizeSubviews: and then
manually move the divider bar or change the view's frame size?

Also, I'm having pretty good luck simulating a "collapse" by simply setting
the divider to 0 for something like the first view - but most of the online
tutorials actually animate the view's frame to a size of 0. Which way is
more "correct"? I don't know if I can animate the approach that directly
sets the position of the divider bar.

Finally then, Mail has an altogether different, neat effect when you
collapse the first or Source view. If you notice, the second and third
views appear to simply slide over the Source view. Maybe the Source view is
getting smaller and auto layout is setup such that the labels don't shrink
but it looks more like the 2nd and 3rd view are simply sliding over-on top
of the Source view. And yes, the 2nd view isn't getting bigger, it is the
3rd view that is getting the extra space.

So, manual window resizing, dragging dividers around ... and programmatic
buttons - all acting generally the same. In general, all resizing is done
in the 3rd view ... and collapsing the 1st view has a special effect to it.

Thanks in advance for any suggestions,
-Luther
_______________________________________________

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

Reply via email to