docs/dev/COMPARE.md says what komorebi for KDE shares with komorebi for Windows and komorebi for Mac, what differs, what KDE does by itself and what is not supported, for a reader who knows komorebi on one of them. Its tables are generated by scripts/compare-gen.py from this checkout and from checkouts of the other two, because a count or a name typed by hand is wrong after the next change to a command, a key or an event. The script also checks the notes that say why a command has no counterpart, and the sentences of the document that depend on a table, and stops when one of them is no longer true. CI has neither checkout and cannot run it; CONTRIBUTING says when to run it. The tables have no column for the commit that added a row: the plan that numbered the commits is not in the repository, and a number the script cannot derive for the next commit would stop it. The other documents had places that said something the repository does not carry or does not do: - DESIGN cited docs/kde.md, which no commit carries, said spike 8 "asked whether" one komorebi.json could be shared, and described the default of the key binding mode as a plan. Each entry now states the rule and the evidence. The first entry no longer says that the Windows implementation is the reference: both it and the macOS one were read, and the native thing is preferred where the other two need a workaround. - "The spikes" was used in PLATFORM, DESIGN and COMPARE and defined nowhere. PLATFORM's vocabulary defines it, and PLATFORM has a list of what was not measured, which COMPARE links to. - ARCHITECTURE said a maximized window is hidden with its workspace and shown with it, and that the code has a TODO for cycling the focus. A workspace switch hides nothing, since KWin shows and hides the desktop's windows, and the cycle leaves a maximized window as it is; the TODO and the commented-out code under it in window_manager.rs are replaced by a comment that says so. The Key bindings section no longer repeats the headings of the sections before it. - README listed the subcommands that work without the daemon, and the list was short. It gives the rule and one example of each kind. - The page on changing monitors opened with "nothing to configure" and then named display_index_preferences. - COMPARE said KWin waits 300 ms for the pointer to settle before it moves the focus. That is KWin's default (DelayFocusInterval, in KWin 6.8.1), and komorebi sets it to 0 while focus follows mouse is on; the page now says so. - ARCHITECTURE's opening list of what the page describes stopped at the borders and had no word of animation, themes, wallpapers, transparency, focus follows mouse or key bindings. Two link definitions that it had twice are there once. - PLATFORM's list of what was not measured has the progress of the stock animation effect against the clock: one capture showed none four seconds into a 30 s animation, where the curve gives about 60 %. - README, docs/index.md and ARCHITECTURE link COMPARE.md. - COMPARE's list of the methods of Backend has drag_end, which the end of a resize is read through, and compare-gen.py has the row and the counts.
4.8 KiB
Monitors that change
komorebi follows the outputs KWin has, and a change of them needs no command: this page says
what komorebi does when a monitor changes. The one thing to set is where a monitor goes in
komorebi's order, display_index_preferences.
A monitor changes size
A monitor changes size when its resolution or its scale changes (in System Settings, under
Display & Monitor, or with kscreen-doctor output.<name>.scale.1.5), and when a panel changes
the room the windows have on it: a panel that starts, grows, moves or is hidden. komorebi reads
the size and the work area of every monitor again, and tiles the workspace in front on the
focused monitor in the area it now has.
The windows of the other monitors keep their tiles until something tiles them again.
komorebic retile does it for every monitor.
KWin has no signal for the room a panel leaves, so komorebi looks at it when a panel opens, closes or moves, and once a second. A panel that is laid out a moment after komorebi starts is found within a second.
A window is moved to another monitor
A window moves to another monitor when something other than komorebi moves it: a KWin shortcut that sends the window to the next screen, the window menu, a drag with the pointer, or an application. KWin tells komorebi, which finds every container and floating window that is on another monitor than the one it has it on, and moves it to the workspace with the same number on the monitor it is on. The monitors that windows moved between are tiled again.
A window is on the monitor whose area has the middle of its frame. A container is on the monitor
of the window that has the focus in it. A move komorebi made itself, with
komorebic move-to-monitor for one, is in komorebi's state already,
and finds nothing to do.
While the user drags a window with the pointer, komorebi moves nothing: where the window goes is decided when they let go of it (moving windows by dragging).
A monitor is unplugged
KWin takes the windows of an output that goes (it is unplugged, or disabled with
kscreen-doctor output.<name>.disable) to the outputs that are left, and puts them where it
likes. komorebi takes the monitor's workspaces over there: every container, and every floating
window, goes to the workspace with the same number on the monitor KWin put its window on, and
the workspaces that changed are tiled again. A stack goes as a stack. A
monocle window comes as a tile of its own, and the windows the monocle hid are shown again. A
maximized window stays maximized, on the workspace it goes to; if that
workspace has a maximized window already, it goes back to its tile.
A moment after an output goes or comes back (1.5 seconds), komorebi looks at where every window is once more, because KWin moves windows about for a while after the outputs change: the windows it took to the monitor that is left may go back to the output that is plugged in again, and a change of resolution or scale changes where the middle of a window is.
komorebi keeps the monitor that went, with its workspaces, layouts, paddings and offsets, for when it comes back, and forgets the workspace rules of its workspaces until then. When no output is left at all, komorebi does nothing.
A monitor is plugged in
komorebi knows a monitor by the manufacturer, the model and the serial number KWin reports for the output, or by the output's name when it has no serial number. A monitor komorebi has kept comes back with what was kept: its workspaces and their settings, and the wallpaper of the monitor, less the windows that have closed or that are somewhere else now. Its windows were tiled on other monitors when it went, so it comes back with none of them. The monitor that had the focus keeps it, and every monitor shows its workspace in front.
A monitor that komorebi has not seen gets workspaces of its own, and the windows that open on it
are tiled there. When komorebi.json has an entry for the monitor in
display_index_preferences and the monitor was not
connected when the file was read, it takes the entry when it is plugged in. The monitors are put
at the index the user gave them with
komorebic display-index-preference, and after the other
monitors otherwise.
Following it from a program
A subscriber is sent a notification each time komorebi has
dealt with a change of the monitors, whether or not anything changed in the state. Its event is
{"Resize":0} for a change of size, where the number is the id of the monitor that changed, or 0
when KWin does not say which, and {"DisplayConnectionChange":0} for a monitor that was
unplugged or plugged in.