Option to offset views instead of changing frame size about splitview HOT 5 CLOSED

Indeed, this does sound like a good option for people. It was a little hard to find what was actually done amidst all the formatting changes in #23 😜.

FWIW, I made one change to your PR before I did anything, in Split.swift, line 98, adding .height: pHeight:

.frame(width: pWidth, height: pHeight)

If I run the "Sidebars" SplitDemo with the option enabled:

Split(
    isResizing: false,
    primary: {
        List(leftItems, id: \.self) { item in
            Text(item)
                .lineLimit(1)
                .truncationMode(.tail)
        }
        .listStyle(.plain)
        .padding([.top], 8)
    },
    secondary: {
        Split(
            isResizing: false,
            primary: {
                VStack {
                    Text(middleText)
                        .frame(maxWidth: .infinity, alignment: .leading)
                    Spacer()
                }
                .padding(8)
            },
            secondary: {
                VStack {
                    Text(rightText)
                        .frame(maxWidth: .infinity, alignment: .leading)
                    Spacer()
                }
                .padding(8)
            }
        )
        .splitter { Splitter.line() }
        .constraints(minPFraction: 0.3, minSFraction: 0.2, priority: .secondary, dragToHideS: true)
        .layout(demo.holders[0].layout)
        .fraction(0.75)
        .hide(demo.holders[0].hide)
    }
)

the changes cause the primary sides to not show properly:

I don't really have a good way to test things, frankly, since it's all visual, so I use the DemoApp. The Sidebars demo is sometimes less forgiving than the ones using Colors, but the "Nested adjustable" also has the same problem.

My preference for folding this kind of thing in would be to add it to the .constraints modifier at the end of the existing options. This way the public initializers for Split, HSplit, and VSplit don't change and it's more consistent with the approach I've taken overall.

from splitview.

Hmm, I'll verify my changes again using provided demo app, before pushing new commits.
I did however change the way this setting is applied — now it's done using .disableResizing() modifier on the view itself.

from splitview.

FWIW, I made one change to your PR before I did anything, in Split.swift, line 98, adding .height: pHeight:

.frame(width: pWidth, height: pHeight)

I skipped the height parameter intentionally. I'm using VSplit in my app and I needed the top View to keep its original height no matter what. That's why isResizing flag is used here, with the .offset modifier to act like in its original behaviour.

I believe in HSplit, analogically the width should be omitted.

from splitview.

After some testing with DemoApp, I came to conclusion that this behaviour is kinda expected.

If we disable resizing by setting isResizing flag to false, the view won't be resized to fit it's parent container.
That was the goal for me, because I wanted to have a Map in split view. Resizing it while dragging was causing poor performance.

.disableResizing(true) therefore works as expected, it just disables the width adjusting in horizontal mode, height in vertical.

However I do see the issue with this modifier, as it produces results that may be not entirely obvious and seem like a bug.

from splitview.

I'm not going to be able to merge a PR that causes such unexpected behavior when applied to something as simple as a space-filling Color.

The Map view seems to scale and resize perfectly fine for me:

struct DemoApp: View {
    @State private var demoID: DemoID = .simpleDefaults
    @State private var pRegion = MKCoordinateRegion(center: CLLocationCoordinate2D(latitude: 51.507222, longitude: -0.1275), span: MKCoordinateSpan(latitudeDelta: 0.5, longitudeDelta: 0.5))
    @State private var sRegion = MKCoordinateRegion(center: CLLocationCoordinate2D(latitude: 37.779379, longitude: -122.418433), span: MKCoordinateSpan(latitudeDelta: 0.5, longitudeDelta: 0.5))
    
    var body: some View {
        let demo = demos[demoID]!
        VStack {
            DemoToolbar(demoID: $demoID)
            switch demoID {
            case .simpleDefaults:
                HSplit(
                    left: { Map(coordinateRegion: $pRegion) },
                    right: { Map(coordinateRegion: $sRegion) }
                )
...

If you have an expensive overlay that needs to be recalculated as sizing changes, then perhaps an alternative approach would be to use onDrag to disable it when dragging starts and then recalculate it when dragging ends (or position a button overlay to optionally recalculate it like the Yelp app does). If needed, you could do an onDragEnd view modifier that is invoked like onDrag, but in the .onEnded closure of Split.drag(in:):

.onEnded { gesture in
    previousPosition = nil
    styling.previewHide = false     // We are never previewing the hidden state when drag ends
    hide.side = sideToHide()
    // The fullFraction is used to determine the sideToHide, so we need to reset when done dragging,
    // but *after* setting the hide.side.
    fullFraction = constrainedFraction
    fraction.value = constrainedFraction
    onDragEnd?()
}

from splitview.