Version (which release did you use?)
Most recent development version (custom-language 35d66d5)
Describe the bug
If the user creates a layout and then removes a window that orphans a node whose parent is the same type, Nog doesn't automatically merge them.
For example:
AABBCC
AABBCC
AADDDD
AADDDD
The above would be a layout represented in the following way:
C1 (Column Node)
/ \
A R (Row Node)
/ \
C2 D
/ \
B C
If the user quits or unmanages the window D, the node C2 (a column node) would take the place of its parent as it was left sibling-less. However, this creates a column whose parent is a column:
C1 (1st Column Node)
/ \
A C2 (2nd Column Node)
/ \
B C
Instead, Nog should automatically merge these nodes to the following:
C1 (1st Column Node)
/ | \
A B C
The above doesn't break Nog's tiling necessarily, but it makes some of the keybindings respond un-intuitively as it treats the columns/rows in groups rather than siblings until the user manually reconstructs the grid.
To Reproduce
Steps to reproduce the behavior:
Manage a window
Manage another window
Change split direction to horizontal
Manage another window
Change focus to the top window
Change split direction to vertical
Manage another window
Change focus to the bottom right window
Unmanage or quit the focused window's application
Expected behavior
Remaining tiles should merge into one column collection
Actual behavior
Remaining tiles merge into a column collection where the first entry is a tile and the second entry is another column collection holding the remaining two tiles.
Additional Notes
This is something I noticed occasionally and finally realized what was happening and may be a little technical. From a user's perspective it would appear as if Nog was moving groups of tiles instead of single tiles when using the focus/move tile bindings.
The easiest way to resolve this is to just walk the tree after any modification and merge columns/rows that have a sole child of the same type, but a more optimal approach would be to detect and resolve the situation when it occurs. I've written unit tests to detect the scenario and am working through to see if this can be fixed in an optimal way that works in multiple, nested scenarios. I'm just writing up this issue in case anyone happens to come across it in the mean time.
Version (which release did you use?) Most recent development version (custom-language 35d66d5)
Describe the bug
If the user creates a layout and then removes a window that orphans a node whose parent is the same type, Nog doesn't automatically merge them.
For example:
AABBCC AABBCC
AADDDD AADDDD
The above would be a layout represented in the following way:
If the user quits or unmanages the window D, the node C2 (a column node) would take the place of its parent as it was left sibling-less. However, this creates a column whose parent is a column:
Instead, Nog should automatically merge these nodes to the following:
The above doesn't break Nog's tiling necessarily, but it makes some of the keybindings respond un-intuitively as it treats the columns/rows in groups rather than siblings until the user manually reconstructs the grid.
To Reproduce
Steps to reproduce the behavior:
Expected behavior Remaining tiles should merge into one column collection
Actual behavior
Remaining tiles merge into a column collection where the first entry is a tile and the second entry is another column collection holding the remaining two tiles.
Additional Notes
This is something I noticed occasionally and finally realized what was happening and may be a little technical. From a user's perspective it would appear as if Nog was moving groups of tiles instead of single tiles when using the focus/move tile bindings.
The easiest way to resolve this is to just walk the tree after any modification and merge columns/rows that have a sole child of the same type, but a more optimal approach would be to detect and resolve the situation when it occurs. I've written unit tests to detect the scenario and am working through to see if this can be fixed in an optimal way that works in multiple, nested scenarios. I'm just writing up this issue in case anyone happens to come across it in the mean time.