So I’ve been working on a layout engine based on StretchableLayoutManager and StretchableLayoutResizerBar. But I now realise that the ‘stretchy’ behaviour is not what we want in this case: we are going for an IDE-like resizing between components, where moving a resizer should only affect the components either side of it.
I’ve been looking at how to achieve this with the existing classes. I’ve made a rather hacky attempt to “fix” the surrounding itemLayouts in an overridden hasBeenMoved implementation. But this does not (currently) work very well and does not feel like a proper solution.
I’m tempted to rewrite the whole thing using modern C++ (potential rabbit hole?) but would be good to get some opinions/experiences before I head down that route!
It sounds to me like you could make use of the FlexBox (tutorial here) and parameterise its attributes, updating them when dragging things around.
Yes, I had thought of that initially. Chose StretchableLayoutManager and ResizerBar as it looked like we could make use of existing functionality, and the column/row restriction informs our design quite nicely. Might have to reconsider though.
I remember writing a split pane UI component years ago for raw flat layout and I used a binary tree like structure for the panes and used some math to calculate the flexible areas through the binary tree.
Eclipses SWT and UI was setup like this and worked well since it wasn’t nested.
… This was just a random thought, nothing to do with JUCE or C++.
Yeah I’ve already got a tree structure going on, generating the layout from a ValueTree. Each branch of the tree alternately represents a row or column layout.
1 Like
