In Tall and Tall Right, Increase main pane count goes silently to arbitrary numbers

[evakkuri]

Describe the bug
The following behavior is in at least in Tall and Tall Right layouts.

Let's say I have 2 application windows side by side as normal in Tall layouts. If I press Shift-Option-comma to increase main pane count, I get what looks like Wide layout. If I then press Shift-Option-period, I go back to 2 windows side by side.

However, if I continue pressing Shift-Option-comma, the visual remains the same, but I will need to press Shift-Option-period an equal number of times to go back to side-by-side windows.

Applications:
Tested with:

• Visual Studio Code and Firefox
• Edge and Microsoft Teams

To Reproduce
Steps to reproduce the behavior:

• Have 2 windows open side by side in Tall or Tall Right layout
• Press Shift-Option-comma let's say 5 times. With the first press you should go to what looks like Wide layout. With subsequent presses you should not see any further changes to the layout.
• Confirm that you need to press Shift-Option-period 5 times to go back to having 2 windows side by side

Expected behavior
Once pressing Shift-Option-comma no longer produces visible changes to the layout, I expect to only have to press Shift-Option-period once to go back to the original layout.

Screenshots
If applicable, add screenshots to help explain your problem.

Versions:

• macOS: Ventura 13.1
• Amethyst: 0.17.0

Debug Info

$ /Applications/Amethyst.app/Contents/MacOS/Amethyst --debug-info [--include-apps]

Version: 0.17.0 (97)

OS version: Version 13.1 (Build 22C65)

Screens:
	(0.0, 0.0, 1440.0, 900.0) [(0.0, 0.0, 1440.0, 900.0)]

Configuration:
window-minimum-height: 0
window-minimum-width: 0
use-canary-build: 0
follow-space-thrown-windows: 1
ignore-menu-bar: 0
enables-layout-hud-on-space-change: 1
screen-padding-bottom: 0
screen-padding-right: 0
new-windows-to-main: 0
window-resize-step: 5
enables-layout-hud: 1
window-margin-size: 4
window-margins: 0
mouse-follows-focus: 0
screen-padding-left: 0
smart-window-margins: 1
layouts: (
    "tall-right",
    tall,
    wide,
    fullscreen,
    column,
    bsp,
    "two-pane",
    "3column-left",
    "middle-wide",
    "3column-right"
)
window-max-count: 0
mod1: (
    option,
    shift
)
screen-padding-top: 0
float-small-windows: 1
restore-layouts-on-launch: 1
floating: (
        {
        id = "com.apple.AppStore";
        "window-titles" =         (
        );
    },
        {
        id = "com.apple.finder";
        "window-titles" =         (
        );
    },
        {
        id = "com.apple.systempreferences";
        "window-titles" =         (
        );
    },
        {
        id = "com.getharvest.harvestxapp";
        "window-titles" =         (
        );
    },
        {
        id = "com.apple.calculator";
        "window-titles" =         (
        );
    },
        {
        id = "com.apple.iCal";
        "window-titles" =         (
        );
    },
        {
        id = "com.apple.ActivityMonitor";
        "window-titles" =         (
        );
    },
        {
        id = "com.bitwarden.desktop";
        "window-titles" =         (
        );
    },
        {
        id = "com.spotify.client";
        "window-titles" =         (
        );
    },
        {
        id = "com.apple.TextEdit";
        "window-titles" =         (
        );
    },
        {
        id = "com.apple.mail";
        "window-titles" =         (
        );
    }
)
focus-follows-mouse: 0
mod2: (
    option,
    shift,
    control
)
floating-is-blacklist: 1
debug-layout-info: 1

Manageable applications:
	Calendar (com.apple.iCal)
	Microsoft Teams (com.microsoft.teams)
	Microsoft Edge (com.microsoft.edgemac)
	Spotify (com.spotify.client)
	Mail (com.apple.mail)
	Preview (com.apple.Preview)
	TextEdit (com.apple.TextEdit)
	Postman (com.postmanlabs.mac)
	Day One (com.bloombuilt.dayone-mac)
	Activity Monitor (com.apple.ActivityMonitor)
	Finder (com.apple.finder)
	Bitwarden (com.bitwarden.desktop)
	Harvest (com.getharvest.harvestxapp)
	Firefox (org.mozilla.firefox)
	Notes (com.apple.Notes)
	Microsoft PowerPoint (com.microsoft.Powerpoint)
	Code (com.microsoft.VSCode)
	Single Sign-On (com.apple.AppSSOAgent)
	coreautha (com.apple.LocalAuthentication.UIAgent)

Note: --include-apps will list your manageable applications, but is optional if you don't want to list that.

Additional context
Add any other context about the problem here.

[ianyh]

There is a problem with this which is non-stateful layouts are intentionally oblivious to things like the count of windows on the screen. The layout logic could be changed to just calculate frames based on the number of windows rather than the layout parameters, I think, but I would like to avoid changing the native layouts and it's a common problem people encounter.

I have been considering some ways to visually represent the count so that there is at least feedback when it becomes unreasonable. Do you think that would be sufficient for solving the issue?

[evakkuri]

Thanks for the reply!

Some indication of the count will be helpful if that's the fastest to implement. 👍 My issue was that I thought Amethyst was broken and there was no way of resetting the Tall Right layout. A visual counter won't really fix the issue in my opinion, but at least you get feedback that what you're doing has an effect.

Another idea - based on my experience, this issue is only one-way, meaning you can increase the main pane count to arbitrary numbers but decrease the count only to a specific number. If this lower limit is a known number, there could be an option in the settings to reset the count maybe? Because at least for me settings was the first place I looked and couldn't find help there.

[evakkuri]

Hmm apparently I could have also unchecked "Restore layouts on launch", without it Amethyst resets to a normal Tall Right after relaunching.

[alexgenaud]

It looks like this may be a different perspective of issue #1180 . Both seem to be overflow cases, where the main stack count exceeds the total window count of a single Desktop/Space. Issue #1413 hides the overflow from the view (confusing human view and control). Issue #1180 displays the overflow in the view (ghost overflow displayed as transparent windows, odd but not confusing).

non-stateful layouts are intentionally oblivious to things like the count of windows on the screen.

Each Desktop has a stack model. The "main count" should be owned by a Layout Model of each Desktop. It sounds like currently, the Layout View contains model data (Layout View holds the "main count"). In classic MVC, they would be strictly separate.

I am not sure how Amethyst represents state, but dwm and Xmonad have a strict MVC design, and it seems that Amethyst is similar. I imagine Amethyst's model has a SET of Desktops/Spaces/Screens and each Desktop contains a single STACK of windows. Every element of the STACK points to a GUI window (or something points back to a specific element on the STACK). In any case, the STACK knows its own size and that size corresponds to the number of windows.

A single "main count" int could be universal to all Layouts of each Desktops, but it's probably uniquely owned by each Layout in each Desktop (each Layout has its own int copy, if a Layout implements it at all).

If those details (STACK and Layout's main count) are in the model, then incrementing the main count should never exceed the STACK size (nor the Desktop's total window count), just as decrementing the main count must never be less than zero.

If the Layout composes the View based on the Model's "main count" and STACK, there will never be overflow nor underflow (assert "main count" <= STACK.size && "main count" >= 0).

I have been considering some ways to visually represent the count so that there is at least feedback when it becomes unreasonable.

It's better to make the bug visible rather than hidden and confusing. If I can choose my poison: #1180 "transparent overflow windows" is visible, easier to understand, avoidable, (and probably easier to fix).

[jivanpal]

It's better to make the bug visible rather than hidden and confusing. If I can choose my poison: #1180 "transparent overflow windows" is visible, easier to understand, avoidable, (and probably easier to fix).

I agree in principle that this issue is probably more frustrating to users than #1180, since this issue is not necessarily obvious to the user when it occurs.

[alexgenaud]

I meant to rate the better bug with tongue in cheek. :)

make the bug visible rather than hidden and confusing...

... probably more frustrating to users than #1180, ...

I'm sure Mac OS complicates everything (fx, the user and Mission Control do their things without consulting Amethyst's model). None the less, whatever keeps track of the abstract window stack should also keep track of the main count and keep them both sane.

Set of:
 - Desktop model(s)
   - Stack of:
     - Window model(s)
       - int total window count
   - List of:
     - Layout model(s)
       - int main count

[alexgenaud]

@ianyh , @evakkuri , @ianyh

As I recall Xmonad and/or suckless dwm have "all and nothing" tolerances for the main and non-main stack. They allow (total window count >= main count >= 0).

Whereas Amethyst today seems to allow (infinity >= main count >= 1). The upper un/bound is probably the ultimate cause of both bugs #1180 and #1413 .

But the lower bound (minimum 0 or 1 main window) is also interesting.

Requiring at least 1 main window (if any windows in the Desktop) is probably easiest to understand and best demonstrates the ideal presentation of each layout (for example one wide window on top of the WIDE layout and one tall window on the left of the TALL layout).

However, while (total window count >= main count >= 0) may be initially confusing, it makes additional layouts redundant. For example, both "0 windows in main" and "all windows in main" in WIDE mode are visually equivalent to COLUMN layout (although "rotations" through non-main or through main-only will appear to be reversed). Likewise "all and nothing" (all windows or 0 windows) in main in the TALL layout will look like a stacked ROW-only or WIDE-only layout.