Incorrect pane resizing after pane split followed by close

Help
,
1

Steps to reproduce

Open obsidian
Split pane (splits: 1/2, 1/2)
Adjust the split separation (splits: 1/2, 1/2
Split within one of the splits (e.g. left) This will cause a division of the left split only, as expected (splits 1/4, /1/4, 1/2)
Close one of the left 1/4 side splits

Did you follow the troubleshooting guide? [Y]

Expected result

splits: 1/2, 1/2

Actual result

1/4, 3/4

Environment

SYSTEM INFO:
Obsidian version: v1.7.0
Installer version: v1.6.7
Operating system: Darwin Kernel Version 23.5.0: Wed May 1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 23.5.0
Login status: logged in
Catalyst license: supporter
Insider build toggle: on
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none

Additional information

Basically what happens is that.
If the split size separator is not touched, it works as expected and splits are always equally divided.
When the separator is adjusted the behavior is buggy - not consistent with the separator.
The solution should be trivial:
When split separators are adjusted, treat the local configuration as you do for bot split and unspilt (closing splits). So the readjustment post a split pane close should snap back to the local “split boundary”.

Note that this needs to be recursive - in the sense that every time a split is manually adjusted it should form two sides that are now independently managed.

If the above is not clear, please ask and I can try to clarify.

Related bugs incorrectly closed

Here’s how it behaves without adjusting splits. This is how it should also behave after adjusting it - only that the behaviors should be “local” within the inner most
2024-08-23 09.48.55

  • here’s how it behaves incorrectly, post resize
  • 2024-08-23 09.50.11
2

Ok this is not a bug and is intentional.
It is a consequence of the fact that if you resize a pane, the split is created by dividing that pane (second screen recording) and not the whole workspace (first screen recording).

You can open a FR to ask for these two actions (split a pane, add a column) to be separated into two different commands. You can also open a plugin idea to propose a new way of recomputing the pane sizes when one pane is removed.

3

I’m not sure I follow. The behavior I’m describing seems inconsistent with your description.

  • the actual pane resizing (constraint) is violated after closing the tab
  • more generally it violates UI consistency / reversibility principles- if I perform an action on the UI (open a tab) and then undo the action (close the tab) it should leave the UI in the original state

Moreover, I don’t think there should be two commands. It’s the same command within (arguably) different context, rather than two different actions. These two should be independent.

4

I understand.
The current behavior is intentional and not a bug.
If you are only concerned with the behavior after close, open a FR to propose a new way of recomputing the pane sizes when one pane is removed.

5

Thanks for clarifying. Created Adaptive pane resizing within fixed (resized) splits

6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.