Main pane count may exceed number of windows in "Wide" mode

[jivanpal]

Describe the bug In "Wide" mode, if the number of windows in the main (top) pane exceeds the number of windows that exist, empty window areas are created. Instead, the behaviour should be like in the "Tall" mode, where the effective number of window areas is capped to the number of windows that exist.

Applications: All apps.

To Reproduce

1. Open 3 windows
2. Switch to "Wide" mode
3. Do the "Increase main pane count" shortcut until all 3 windows are in the top pane, producing a 3-column style layout. Do the shortcut once more, producing a 4-column layout where the first 3 columns contain windows, but the 4th column is empty. You may continue to do this to increase the number of empty columns as high as you like.

Expected behavior the behaviour should be like in the "Tall" mode, where the effective number of window areas is capped to the number of windows that exist. If you do the above to reproduce the issue, then switch to "Tall" mode and try to increase the main pane count above 3, you will see that the 3-row layout cannot become e.g.a 4-row layout

Screenshots

"Wide" mode with main pane count set to 1

"Wide" mode with main pane count set to 3

"Wide" mode with main pane count set to 4

"Wide" mode with main pane count set to 5

Versions:

• macOS: "Catalina" 10.15.7 (19H1615)
• Amethyst: 0.15.5 (92)

Debug Info

$ /Applications/Amethyst.app/Contents/MacOS/Amethyst --debug-info
Version: 0.15.5 (92)

OS version: Version 10.15.7 (Build 19H1615)

Screens:
	(0.0, 0.0, 1920.0, 1080.0) [(0.0, 0.0, 1920.0, 1080.0)]

Configuration:
ignore-menu-bar: 0
window-resize-step: 1
window-minimum-height: 0
window-margins: 1
screen-padding-top: 0
floating-is-blacklist: 1
mouse-follows-focus: 0
mouse-swaps-windows: 1
float-small-windows: 1
use-canary-build: 0
follow-space-thrown-windows: 0
screen-padding-right: 0
enables-layout-hud-on-space-change: 1
restore-layouts-on-launch: 0
debug-layout-info: 0
screen-padding-bottom: 5
mod1: (
    option,
    shift
)
floating: (
        {
        id = "com.apple.systempreferences";
        "window-titles" =         (
        );
    },
        {
        id = "com.skype.skype";
        "window-titles" =         (
        );
    }
)
mouse-resizes-windows: 1
mod2: (
    option,
    shift,
    control
)
new-windows-to-main: 0
focus-follows-mouse: 0
window-margin-size: 5
screen-padding-left: 0
layouts: (
    tall,
    wide,
    fullscreen
)
enables-layout-hud: 1
window-minimum-width: 0

Additional context Add any other context about the problem here.

[alexgenaud]

Well described @jivanpal . This issue remains on 0.20.0b3 and only in WIDE layout. The issue does not bother me (because it's visible and avoidable).

Interesting that WIDE demonstrates a different perspective of bug #1413 . I believe these are the same issue. In TALL mode, we cannot see the stack overflow (more windows in view than windows in stack model), whereas in WIDE mode we see the stack overflow as "transparent windows" in the view that do not correspond to windows in the model stack.

If we may pick and choose our issues: I prefer this visible WIDE issue over all other layouts' invisible overflow issue. :)

[alexgenaud]

Expected WIDE layout behaviour with respect to focus/move rotation and increasing/decreasing main window count.

Currently (0 main, all blue non-main) is prevented, but (All main teal and beyond) is allowed.

Increasing the main count should move the bottom-right window of the non-main row into the top-right row of the main stack. Decreasing the main count should move the top-right window into the right side of the bottom row.