Files
komorebi/docs/linux/dev/scrolling-next.md
T
LGUG2Z a7b78cc7e4 docs(linux): paths and links name the consolidated layout
The KDE docs were moved from komorebi-for-kde/ to docs/linux/ and the sources, nix files,
scripts and schemas to komorebi-linux/, nix/linux/, scripts/linux/ and schemas/linux/, so
every relative link that left docs/ (to sources, nix files, scripts, schemas, .envrc,
rust-toolchain.toml, the old CI file) was broken, and the text named the old paths.

Links were rewritten mechanically by resolving each broken target against the old
location and mapping it to the new one; link texts and code-span paths were updated to
the new paths (komorebi/src -> komorebi-linux/src, nix/ -> nix/linux/, scripts/ ->
scripts/linux/, docs/ -> docs/linux/, schema.json -> schemas/linux/schema.json). The
crate list of the README names komorebi-linux, komorebi-daemon and komorebi-version;
`cargo install --path komorebi` becomes komorebi-daemon; the comparison paragraph of
CONTRIBUTING.md says compare-gen.py is stale (it looks for the old sibling trees).

URLs of the old GitHub repositories are left as they are (a release decision).
COMPARE.md is left as it is (already marked stale).

Verified: a link checker over every markdown file (outside cli/, nix/, tools/, old-ci)
reports no broken link in docs/linux. Nothing was built.
2026-11-05 15:03:27 -08:00

64 lines
8.0 KiB
Markdown

# The rework of the Scrolling layout on upstream's `next`
Upstream (LGUG2Z/komorebi) reworked the Scrolling layout on its `next` branch: a platform-free
model of a strip of columns (`komorebi-scrolling`), the glue that every komorebi shares
(`komorebi_layouts::scrolling`), and, on top of them, columns that hold several windows and the
commands that go with them. This page says, for each of the commits of `master...next` that touch
the layout, what it changes, whether komorebi for KDE (kfde) takes it, and how. The review is of
`next` at `6d862a114` (the revision kfde's `Cargo.toml` pins now).
Two things shape what applies. The model and the platform-free glue live in crates that kfde takes
from upstream by git revision, as it already took `komorebi-layouts`, so a commit that only
touches them arrives with the bump of the revision. And what the glue needs of a window (where it
is, whether it is hidden, how wide it really is) is a call to the backend in kfde, not to Win32.
## Commits of the layout
| Commit | What it changes | kfde |
|---|---|---|
| `9ccf2efce` model of a scrollable strip | New crate `komorebi-scrolling`: columns of tiles, widths (proportion or fixed, limits), heights, view offset, centring (`Never`, `Always`, `OnOverflow`), pan, swipe tracker. No Windows code. Tests in the crate. | **Ported by dependency.** `komorebi-scrolling` is a git dependency at the same revision as the layouts. Its tests are upstream's; kfde tests the glue. |
| `abd4fde3e` lay out with the model | The workspace keeps a `ScrollingSpace` keyed by container id; `update()` places containers from it instead of recomputing equal columns from the last layout. | **Ported** (`komorebi-linux/src/scrolling.rs`, `Workspace::update`). |
| `cb127204c` platform-free glue | `komorebi_layouts::scrolling` (options, `place`, `resize`, hand-over between workspaces), `ScrollingCentering` replaces the `bool` of `center_focused_column`; Workspace methods for focus, order, consume, expel, stack. | **Ported:** the layouts half by the bump, the Workspace half in `komorebi-linux/src/scrolling.rs`. |
| `249709e60` commands and config | Socket messages and `komorebic` commands `consume`, `expel`, `toggle-column-stack`, `scrolling-layout-full-width`, `center-focus`, `expand`; focus, move, resize, retile and close go through the strip. The message says a top level `scrolling` section too. | **Ported**, except the `scrolling` section: neither kfw nor kfde has one (only komorebi for Mac has; COMPARE.md says so). |
| `9ff278eb5` schemas | `center_focused_column` is a boolean or a name; docs for the new commands; `schema.bar.json`. | **Ported:** `schema.json`, `nix/linux/komorebi-options.nix`, `docs/linux/cli/`. `schema.bar.json` is kfw's (kfde has no bar). |
| `2dff53095` room for windows that will not get narrow | After windows are placed, a window wider than its column widens the column (never narrower again, never wider than the screen), for an overhang of 16 px or more. | **Ported, with a different trigger.** kfde cannot ask a window how wide it is right after moving it: the frame comes back from KWin a moment later. The widths are read at the first layout after the frames have settled (`WIDTH_SETTLE`), as upstream does with animations on. Covered by unit tests in `scrolling.rs`; no VM check, because it needs a client that will not get narrower and foot has no minimum width. |
| `e75f3db47` rest windows at the edge | A window out of view rests at the edge it left by with 5 px on screen and keeps its size. | **Ported** (`parked`). On KDE this also keeps the window from being resized while it moves out of view, which is what KWin pulls back (PLATFORM.md). |
| `ab1896330` docs | `docs/linux/usage/scrolling-layout.md`, `mkdocs.yml`. | **Ported**, rewritten for KDE (no animation, no borders at the edges, no touchpad). |
| `1531a892a` more than one monitor | Removes the single-monitor restriction; a window out of view past an edge with a monitor next to it is hidden, not parked; a partly visible one is cut to its work area; a window that comes back is shown first, only the one at the front of a stack. | **Ported** (`rest`, `other_monitors`, `should_restore_when_placed`, from `backend().monitors()` and `Window::hide`). kfde never had the restriction. This answers the open question in PLATFORM.md about a strip that spills onto the next monitor. |
| `abb230b45` spread a stack out | The window that stays in the container is restored; focus stays on the column while the containers are inserted. | **Ported.** |
| `ca22b0f81` refocus after Hide | The `Hide` event arm refocuses like `Destroy`. | **Not applicable.** kfde has no `Hide` event: KWin reports a closed window as a destroyed one, which already refocuses. |
| `f2b72a029`, `f22560464` left edge | Resizing a column by its left edge moves that edge, however far. | **By the bump** (`komorebi_layouts::scrolling::resize`). kfde's drag of an edge goes through the same function, and `LiveResize` keeps the strip (below). |
| `1f658fd90` `pan` | `komorebic pan left\|right` moves the view a column. | **Ported.** |
| `09b99700f` touchpad | `pan --stream` reads whkd's gesture stream; `PanGesture`, swipe tracking, pictures over the windows. | **Not applicable.** whkd and the raw touchpad input are Windows only. The swipe tracker is in the model crate if a KDE input path wants it later. |
| `674ae7937`, `5098ff7b7` resize follows the drag | The neighbours follow a dragged edge; the strip is kept with the rest of what the drag started from. | **The strip part ported:** `LiveResize` keeps and restores `Workspace::scrolling`, or every step of a drag would compound on the widths of the one before. The pictures over windows are DWM. |
| `ce13267e1`, `62628f381`, `2a447208f`, `58693ecd3`, `52ad6be78` | Where a drag is measured from; pictures and ghosts for windows being resized or animated. | **Not applicable.** Ghost windows and DWM. kfde measures a drag from `Backend::drag_origin` already. |
| `e5512ca5d` and the other `animation` and `border` commits | Ghosts, workspace slide, border in ghosts, batches of animations. | **Not applicable** (DWM, ghost windows, borders). The Windows session's. |
| `3b424dd70`, `837ca257d`, `5c8e4770d`, `9b9cad997` | Fixes in config, monitors, rules. | **Not scrolling.** Already in kfde or in the hands of the other sessions. |
## What I could not judge
- Whether the 5 px of a parked window pass KWin's rule of keeping 100 px of a resized window on an
output. The bridge's `settle` asks again for a position up to three times, and a parked window
is not resized to be parked, but only the VM says.
- Whether `Window::hide` of a column that scrolls out of view next to another monitor is fast
enough to follow a scroll without a flash. It is what stacks do.
- The 16 px tolerance of `2dff53095` against the clients of `client-geometry` (`foot` rounds to
cells, which is below it).
## What is tested, and where
- `komorebi-linux/src/scrolling.rs`: the glue against a workspace with no desktop (widths, consume, expel,
moving a column, stacking and spreading out with the windows that are hidden, expanding, panning,
where a window rests, which monitors are the others, what a window that will not get narrow
says). The model itself has its tests in upstream's `komorebi-scrolling`.
- `komorebi-linux/tests/scrolling.rs` and `layout_options.rs`: the commands through
`WindowManager::process_command` against the fake desktop, a strip next to another monitor, and a
drag of the left edge of a column.
- `komorebic/tests/linux_cli.rs`: each new subcommand sends its message.
- `nix/linux/tests/vm/lib/komorebi_vm/core/scenarios/scrolling.py` (`columns`, shared with komorebi for
Windows), run by `vm-scrolling` and `core-e2e`: where the daemon keeps a window at the edge and the
commands of the columns, in a real session. Run on KDE: the `scrolling` suite passes
(32 checks, with `two_monitors`). KWin leaves a window resting at the left edge with its right edge a few pixels inside the
work area, or a cell short of them, because foot rounds its frame to whole cells. The shared
`scrolling` scenario passes in `core-e2e` too.