Allow resizing of elements beyond adjacement elements in editor

[apedroferreira]

Duplicates

• [X] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Summary 💡

In the editor, make it possible to extend/resize an element horizontally beyond the element next to it, and adjust the size of every element under the resized area accordingly once the resizing is complete. Resizing elements has been constrained to the element next to the resized element in https://github.com/mui/mui-toolpad/pull/732 to prevent bugs, but that's not the ideal behavior.

See discussion in this PR for context and implementation ideas: https://github.com/mui/mui-toolpad/pull/732

Fixing this issue might also involve:

• changing the way resize previews look so that this type of resizing is always visually intuitive, and does not reflect changes in just one element but all the affected elements
• Extra (possibly related to resize preview visual changes): the resizing behavior should be started not by dragging an element's left or right edge, but by dragging from the horizontal space between two elements.

Examples 🌈

Taken from https://github.com/mui/mui-toolpad/pull/732#issuecomment-1205369977

https://user-images.githubusercontent.com/2109932/182878581-e0b7b5ad-caa3-4148-af8d-adc530d1886e.mov

Motivation 🔦

• Giving users more freedom to resize elements as they wish
• Getting rid of the possibly strange resizing behavior where dragging the right edge of an element is practically the same as dragging the left edge of the element to the right of it
• Allowing more drag-handle space for future possible features such as changing internal spacing or size for a specific component.

[apedroferreira]

Actually this might be doable without changing the visual look of the preview, and by always highlighting the element to the right of the border... If I take this I will try that first to see how it feels before trying any bigger changes.

[Janpot]

https://grid.layoutit.com/ has yet another behavior, it just clamps the fr of a column at 0.1, and keeps increasing the fr of the resizing column. This method is probably easier to implement as you don't need to store and restore the initial widths. Drawback is that dragging the column doesn't precisely follow the cursor anymore once it goes beyond available size of the first sibling (as can also be seen in the video below). The vscode resizing UX is much better IMO.

https://user-images.githubusercontent.com/2109932/183024030-ecbbada8-67b0-43ba-9a20-1b21b1efea83.mov

[oliviertassinari]

@apedroferreira I have removed the "status: needs triage" from this issue and others that you have created. The label is configured to be added by default, so that we can identify issues created by the community (an external contributor can't change labels).

[apedroferreira]

@apedroferreira I have removed the "status: needs triage" from this issue and others that you have created. The label is configured to be added by default, so that we can identify issues created by the community (an external contributor can't change labels).

got it, thanks, i didnt know that