core/fullscreen: layout_handled: Allow layout managed fullscreens to not block seeking window in direction. default_handled: fix bug - on_focus_under_fullscreen = 2 still cycles FS with focus({direction}) if movefocus_cycles_fullscreen = true

[erstarr]

Describe your PR, what does it fix/add?

Allow moving the viewport with focus({direction}) when focused on a fullscreen window when follow_focus = true on scrolling layout (and other layouts that may implement their own FS behaviours in the future)

Fixes movefocus_cycles_fullscreen and on_focus_under_fullscreen to behave consistently:

• On default handled

  • window.focus({direction}) is beholden to on_focus_under_fullscreen and movefocus_cycles_fullscreen.

    • For window.focus({direction}) to change focus when you have a covering FS window, movefocus_cycles_fullscreen must NOT be false and on_focus_under_fullscreen must NOT be 0. If movefocus_cycles_fullscreen false, focus move is disallowed regardless of on_focus_under_fullscreen.

  • window.focus({window}) is beholden to on_focus_under_fullscreen

• On layout handled:

  • Same rules as above apply, but on_focus_under_fullscreen's different config options have no effect - it just allows you to move focus to another window. This is because scrolling is, well, scrolling; you can scroll away from an FS window

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

No

Is it ready for merging, or does it need work?

• Test

[erstarr]

@qgates (#14387 (comment))

[erstarr]

concern: if follow_focus = false, the focus moves left/right but it doesn't move back to the FS window again when right/left.

This is because the window you're currently focused on - i.e. a window that's currently invisible by alpha is not visibleByAlpha(). This is not a bug: the window is indeed invisible since you're currently focused on a fullscreen and the fade animation made all other tiling windows invisible by alpha.

Adding exceptions to this isn't very practical since the function is critical for a lot more things than scrolling.

Adding an exception to this with follow_focus config option check outside scrolling algo source files is also a subpar solution.

Realistically there is no reason to use window.focus({direction}) when you're in FS when you have a covering FS window in scrolling. You would use layout("") commands to move the viewport.

If people complain about this in the future, It's easy enough to slap a "is workspace scroll and is follow_focus false - if so, don't move focus from the covering FS window to begin with" condition there - though the reason i'm not doing this here myself is that I foresee great trouble if an exception is added to "if currently focused on an !aliveAndVisible() window, don't abort the focus move" logic.

I don't really have a good solution to this atm other than rewriting the focus move in direction logic significantly.

Other than this, it's gtg

[github-actions]

Codeowners approval required for this PR:

• @vaxerski

[vaxerski]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b385a001e8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".