Conversation
stackotter
left a comment
There was a problem hiding this comment.
Thanks for looking into this. When testing out your changes locally I managed to make the app freeze in a resize handling update loop indefinitely by resizing the app a bunch and getting unlucky. I reproduced that behaviour a few times and couldn't on main so I think there may be some sort of feedback loop in your current layoutSubviews-based approach. I'm not exactly sure what the solution is to that.
I also noticed that the splits get allocated rather strange sizes (especially when you switch to the three column example), but I get the same behaviour on main so that doesn't necessarily need to be fixed in this PR.
Prevent resizeHandler() from being called twice in one pass
bcee7e0 to
28efb86
Compare
|
Interesting, I’ll try reproducing it myself as well (once I’m at my laptop). |
|
Huh yeah this is really weird. It looks ok now but I can't click the sidebar buttons or the bottom button. And when I resize the split to the right, the trailing split's content moves to the left and overlaps the sidebar 😅 I don't think that that was introduced by your PR though |
|
Feels like maybe a missing translatesAutoresizingMaskIntoConstraints somewhere given that the trailing content isn't centered? And maybe an inverted coordinate? The button going off the bottom of the screen leads me to believe that UIKitBackend is including the title bar when giving us the size of the window. |
|
I have rebased this locally, but I'm hesitant to push up the changes because SplitExample on Catalyst now crashes with this error: |
|
It sounds like you might have to move some code from computeLayout to commit? Hard to tell without seeing the changes, but it sounds like an intermediate 'maximum size' proposal is being used to update a constraint. |
|
I've converted this to a draft for now so that it doesn't keep showing up |





Draft until I can test that I didn't break it on iPad