A window that opens goes after the focused container. A workspace can now say
another place for its windows: the primary or the secondary tile, before or
after the focused container, the end of the list, or a place by number, counting
from 1. The place is for every window, or for the windows that match a rule on
their program, app id, title or path; the rules are the conditions the ignore
and manage rules are made of, and the first that matches in key order decides. A
place that does not exist, such as the secondary tile of a workspace with one
container, is the default place.
A place is read from a name, a number or text that is a number. The
documentation of the setting shows a number and a map's keys can only be text,
and komorebi for Windows (83c4e11d) reads only text, so the form its own page
shows is refused there.
A place that was reserved with preselect-direction is used before the rules are
asked, and a locked container keeps its index. A workspace whose
window_container_behaviour is Append puts a window in the focused container, and
the rules are not used.
A workspace takes the rules from the key initial_window_placement_rules of its
entry in komorebi.json. The key is in schema.json and so in the typed config
option of the module, and the page docs/initial-window-placement-rules.md says
how to write it. vm-placement opens windows in a headless KWin and checks where
they go, by program, app id and title.
The schema that schemars derives for a place is an object with a Placement or an
Index key, which is not what is read or written, so a check against it refuses a
file that the daemon reads. The schema of PlacementTarget is written by hand
instead: a name, a number, or text that is a number. A file with a place of each
form is checked against schema.json, and the module's config option takes them.
KWin maximizes a window for the user as well as for komorebi: the title bar, a
double click and a shortcut do it, and nobody asks the window manager. A window
that stayed a tile would be asked to move at the next retile, so komorebi has to
know.
The bridge reports KWin's maximizedChanged as a maximized event, true only when
the window is maximized both ways. The table turns it into a MaximizeChange, and
adopt_maximize_change takes the window out of the layout as toggle-maximize
does, or, when the user restores it, puts it back in a container of its own at
the index it came from. A window that is already maximized when komorebi starts,
or that opens maximized, is the workspace's maximized window from the start.
komorebi's own maximize is reported too and finds the workspace as it left it,
so it changes nothing.
While a window is maximized, what is asked of the layout does nothing, by the
same rule as for toggle-maximize.
A maximized window of a monitor that is unplugged goes to the monitor that is
left and stays maximized: evacuate_monitor makes it the maximized window of the
workspace it goes to, and the maximized window that workspace had goes back to
its tile. Until now it came back as a tile.
vm-user-maximize maximizes windows with kdotool in a headless KWin, and checks
the daemon's state, the frames, that the layout commands do nothing, and that
toggle-maximize and the user's restore both put the window back in its tile.
A window could be given the work area only as a tile of the layout, which has
padding around it. `komorebic toggle-maximize` has KWin maximize the focused
window instead: it gets the work area of its monitor with the panels left alone,
and it leaves the layout, so that it is in no container. Toggled again, the
window is restored, put in a container of its own at the index it was taken
from, and the workspace is tiled again.
The window is kept in the workspace as its maximized window, with the index it
goes back to, and the state shows both. While it is maximized the workspace asks
KWin to maximize it again on every tiling, and does not move the containers
behind it. The messages that are about the tiles (move, stack, resize, promote,
preselect, lock, float, monocle, and the ones that send a container to another
monitor or workspace) are dropped before they are handled, since there is no
tile to act on. Focusing in a direction finds no container on any side of it, so
the focus goes to the monitor on that side, where a maximized window or a
monocle is given the focus whole. Showing the workspace again restores the
maximized window and focuses it ahead of the containers' windows. A window in
monocle that is maximized leaves the monocle, and one that closes takes the
maximize with it. Backend gets a maximize command, which does nothing unless a
backend implements it; the fake desktop and the KWin backend do, and the bridge
carries it out with KWin's own `setMaximize`. A maximize also makes the bridge
forget the position it was last asked to put the window at, which it would
otherwise set again on the work area's size when the window's frame changed
within a second of a tiling.
komorebi/tests/maximize.rs and maximize_commands.rs drive it against the fake
desktop, with one monitor and with two. The bridge's tests and the backend's
tests read the maximize command from the same fixture, so that what one sends is
what the other carries out. vm-features is a new session suite that reads
screenshots: the first thing it checks is that the maximized window fills the
work area, is the one on top, and goes back to its tile; the vm-commands sweep
runs the new command.
LGUG2Z