Fix checking if sibling is locked when removing Views
#526
Conversation
We only checked if sibling was locked in the `x` direction.
Provide an fix like: #526 but use instead the is_primary_node property and the context property. We align the logic to the one used in the close_all_views method. The approach using get_locked_size was the old approach using by rxi's lite but it should no longer be used to determine if a node if part of the application UI or part of the document's view.
|
Thank you @Guldoman your PR is correct but there is something you couldn't know. The Please review the PR: where I use instead If the new PR looks fine to you we will merge it and close this one. |
|
I take the opportunity to share a problem I observed with the "console" plugin. It is the insert point where it gets attached in the Nodes hierarchy. Sometimes it appears below the TreeView covering all the application horizontal width and something is beside the TreeView occupying only the documents' horizontal space. I think we should fix this insertion point. |
I think this happens because of the order of |
|
I thought we may move the treeview and toolbarview from being plugins to being core elements. These should remove most ambiguity because they are UI elements we want at some specific place while plugins can be loaded in any order. |
If the sibling is not locked in the direction of the split, it should fill the space.
|
With the last two commits the check is done only in the correct "direction" (for example, if a |
Previously if the split type was "hsplit", but `locked_size_x` was falsy, `locked_size_y` was wrongly used.
|
Good, you are right about the locked size thing. I will close my other PR, I think the logic I tried to implement is not the right one as you was pointing out. |
We only checked if sibling was locked in the
xdirection. This fixes the broken layout found in lite-xl/console#4.