Resizing the tiles next to the edge of a window that is dragged lays out every window
that is not the one dragged again at every frame. A window that has to lay itself out
at a new size has nothing to show for a frame, a terminal that renders through a swap
chain is not there at all and the wallpaper shows through where it was, and one that is
slow to take a move, which File Explorer is, is seen at every size that it is on the
way through. A recording of a drag shows whole terminals gone for a frame, and
Explorer windows drawn twice, each of them at two sizes.
With ghost movement, the first time a step has to resize a window a picture of it is
taken before it is touched and put over it, the window is cloaked and its border is left
to the picture. Every step moves the picture, and the border with it, to where the window
is to be, with one call to DWM, and sends the window nowhere: the window is where it
was, hidden. When the end of the drag has laid the workspace out, each of the windows
that were covered is put, on a thread of its own, where the last step put its picture, made
to paint itself, given the size change that a swap chain needs to be built again, and
shown, and its picture fades out over it, as for a move that is animated.
A new drag, before that, puts them where they were to go and shows them at once. The look
at the windows after a drag leaves covered ones to this, and a window that is hidden by its
workspace is not shown by it. Every step traces where the picture is to go and what part
of it is shown there, and a picture that could not be moved says so at debug level.
The start of a drag is handled after the drag has begun, so the rect read
then is already some way into it, and a mouse resize came out short by
that much: dragging an edge by 60px moved it 53px, and the longer the
drag the more was lost.
An edge that has moved since the start was read was taken from the edge
of the window's tile, so measure from that. An edge that has not moved
is not being dragged, and an edge a long way from its tile is a window
that could not be as small as it, so both stay as they were read.
A column was made wider, or narrower, from its left edge whichever edge was
resized: dragging the left edge of the last window of a strip to the left made it
wider to the right, which is where its right edge went, and its left edge stayed
where it was. In the recording of the drag, it was the same window, 1651 wide
before and 1982 wide after, still at the same left edge, to the right of where the
user had put it.
The strip is panned by what the column was made wider by, so that the left edge is
where it was moved to and the right edge stays, and the columns to the left of the
column follow it. The right edge is the one that moves for any other direction, as
it was.
A window that is moved sends a location change for each of the windows in it, and
File Explorer sends about eighteen for every move. Each one had the hook look up the
exe, the title and the class of the window, a call into it for each, to write a trace
line that says that nothing is done with it: about a millisecond and a half each,
holding up the events behind it, which include those of the window being dragged.
They are no longer logged.
After a drag Explorer was left 48 pixels short of where the layout puts it, for as
long as nothing laid the workspace out again: a window that is busy with what an
earlier move made it do is left where that put it, by what was sent while it was.
Which of the moves it is that a window does not make is not something that is known,
but that it is not where it is to be is, and is something that is cheap to look at.
A quarter of a second after the end of a drag that was followed, when the windows
have done what they were going to, the windows of the workspace are looked at, and
any that are not where the layout puts them, give or take a couple of pixels, are
sent there again, and looked at once more after that. It stops when none are, when
another drag begins, or when the workspace is not the one on show. What it found is
logged at debug level each time, so that a check that found nothing is not the same
in the log as one that was never made.
The tiles next to the edge of a window that the user drags to resize it follow the
edge while it is dragged, and not only once it is let go.
Windows tells komorebi of every step of the drag with a location change of the
window, far faster than anything can be laid out. They are only a signal that the
window has moved: at most one waits, and what is laid out is where the window is
when it is looked at, which is the newest. Steps are laid out from a thread of
their own, so that the handling of events is not held up, straight into place and
not animated, as an animation of each step would only trail behind the pointer.
When the user takes hold of a window the resize dimensions, the layout and the
scrolling space of the workspace are kept. Every step, and the end of the drag, is
worked out from those, so a drag ends the same with its steps as without them, and
one that goes back to where it began puts the neighbours back. The window being
dragged is the user's until they let go, so a layout leaves it where it is. The
neighbours are where the last step put them, a few pixels from where the end of the
drag does, so the end is laid out at once as well, and a layout in which windows are
moved with animations does not take the width of a neighbour that has yet to catch
up for the least that its column is to be.
What a window is made to do is not always as quick as the steps: moving File
Explorer does the layout of eighteen windows, and a move sent for every step waits
in its queue, which is busy for as long as there are any, so it falls behind and
goes on catching up after the drag. A window that has yet to get to where it was
last sent is left alone by a step, for no more than a tenth of a second, and looked
at again six milliseconds after the step when a window was left, which is sooner
than the next step for the windows that are quick to move.
A window that opens or closes in the middle of a drag changes what the layout is
made of, so the neighbours stop following until the drag ends. Monocle and maximized
windows, and windows that are not tiled, are not followed. Every window that a layout
for a drag moves is logged, at debug level, with where it was sent from and to, or
why it was left alone.
A border is a window of its own, which cannot be cut off at the edge of the
monitor as a ghost is, so the borders of the windows that slide in and out
were left out of it: they were gone before the windows left and did not come
back until they were shown.
The picture a ghost shows is now given the border its window has, drawn in
room that is made for it around the window and over its edge, in the colour of
the kind of border the window has (single, stack, monocle, unfocused...). The
ghost is bigger than the window by that room, and is clipped to the monitor as
it was, so the window and its border slide and are cut off as one.
The pictures that are kept of the windows that leave are of the windows alone,
as the kind of border a window has when it comes back is not the one it had when
it left.
When the workspace of a monitor is switched, the windows of the workspace that
is left slide out of the monitor and those of the one that is switched to slide
in from the other side, as ghosts, together: from the right when going to a
higher workspace (or right across the edge of a workspace with the Workspace
cross boundary behaviour) and from the left when going to a lower one (or
left). It is one of the animation kinds, so it is on with animations for
everything and can be turned off with the workspace entry of
animation.enabled, and it needs ghost movement.
It is not done when either workspace has a maximized window or windows are not
hidden by cloaking them, and a window that cannot be pictured is hidden or
shown at once.
None of a ghost is drawn outside of its monitor, so nothing is shown on a
monitor next to it. The border of a window that slides in is held until the
window is shown, as it cannot be cut off at the edge of the monitor.
Windows of Chromium and Electron apps, and other apps that render through a
swap chain, are left with a stale render target by being laid out, or asked to
render, while they are hidden, so a window that slides in:
- shows the picture that was kept of it when it left, and is not asked for a
new one while hidden (one with no picture, if it is such an app, is shown at
once);
- is not laid out at all if it is where it is to be, and is laid out once it is
shown, and not before, if it is such an app;
- is not focused until it is shown, as focusing a hidden window shows it;
- is shown before it is laid out when it has to be shown at once, and is held
hidden against the layouts that follow the switch until then.
The container that is to be focused on a workspace that is crossed into is
focused before it is laid out, and not after, which would place its windows
twice.
Let a workspace that is being switched say which of its windows are going to
slide out of the monitor and which are going to slide in, so that hiding and
showing them is left to the animations that do that.
A window with a pending exit is not hidden, and one that is to slide in is not
shown, by the usual paths. It is the animation that takes it over, and it
stays held from then on until the animation shows it, however many times the
layout of its workspace is done meanwhile: taking what is pending only takes
what was asked for. Whatever is still pending when the switch is over, and has
no animation, is hidden or shown at once, so nothing can be left behind, and
what is pending expires after a couple of seconds as well.
The border of a window that is sliding in cannot be cut off at the edge of the
monitor as its picture is, so it can be held: hidden, and not moved or shown by
anything that happens to the window, until it is let go of.
Keep the picture that is taken of a window as its ghost is made, for the ghost
of the window to show when it is back, so that a window that is hidden is
not asked to render itself to get one. Asking a hidden Chromium or Electron
window to has been seen to leave it blank, or drawn off its place, until its
process is restarted.
At most 12 pictures, 256 MiB and ten minutes of them are kept, and a picture
is only given back for a window that is within a few pixels of the size it
was. Nothing uses them yet.
Workspaces are going to slide in and out of the monitor when they are
switched, and that is its own kind of animation (workspace) next to moving
and transparency: it is turned on, and given a duration and an easing, the
same way (animation.enabled, duration and style take a workspace entry, as do
komorebic animation, animation-duration and animation-style with
--animation-type workspace), with the duration and the easing of the other
animations when it has none of its own.
Animations being enabled for everything enables it too, and it can be turned
off in particular (animation.enabled with workspace set to false), so that
enabled: true keeps meaning everything. It needs ghost movement, as the
windows slide as ghosts. Nothing uses it yet.
A ghost can now be given a rect that none of it is drawn outside of: the part
of it that is outside is cut off, with the part of its picture that goes
there, and it is not shown at all when all of it is. A host that covers every
monitor would otherwise draw a ghost that slides out of a monitor on the one
next to it.
What a ghost is made to show now includes which part of its picture goes
where, so that a ghost that is already showing what it is asked to is still
left alone. Checked against DWM with real pixels (on a host that is not
layered, whose thumbnails the screen can be read back from): inside the clip
the window, outside it the host, and nothing at all when it is all outside.
Pure arithmetic on rects, in virtual screen coordinates, for workspaces that
slide in and out of a monitor: which side the workspace that is entered comes
from (from the indices of the two workspaces, or from the direction of moving
across the edge of one), how far each of the two sets of windows slides, and
what to draw of a ghost so that none of it is outside a rect: the part of
where the ghost is that is inside it, and the part of the picture that goes
there. A ghost is drawn on a host that covers every monitor, and one that
slides out of a monitor would otherwise be drawn on the one next to it.
The animation of a window by a ghost is not about windows in general, and the
workspace transitions that follow need to use it for more than moving a window
from one place in a layout to another. No change in behaviour.
Asking DWM to put a thumbnail where it already is, as opaque as it already
is, still has it compose the frame again, and an eased animation spends its
first and last frames where it is. Remember where a ghost was last put and
how opaque it was made, and leave it alone when that is asked of it again.
The thread that owns the ghost host window looked for messages every 8ms for
as long as komorebi ran once ghost movement was on, about 125 wakeups a second
doing nothing, which keeps a processor from sleeping. Poll at that rate only
while there are ghosts, and every 250ms while there are none: it is woken at
once by a command either way.
An animation sent the border of each window it moves a rect for every frame:
it took the global border state lock, which the border manager holds while it
handles a notification, cloned the id of the border, boxed the rect and posted
it, and the border drew every one of them in turn, resizing its render target
and drawing again for each, even when it had fallen behind, so that it lagged
and then caught up in a burst.
Look up the border once, when the ghost is made, and keep the newest rect for
each border where the animation and the border can both get at it: the border
is only told when it has none waiting, and draws the newest when it gets
there. No lock the border manager holds is taken in the middle of an animation
any more, and no box is allocated for each frame.
Windows that render through a swap chain get a one pixel size change when
they are shown again, which takes as long as the window takes to answer twice
(over a hundred milliseconds for a slow one), and it was done by the
animation thread in the middle of the animation, as a hitch in every move:
drawing a frame took up to 154ms, 45ms for the worst frame of an animation on
average. Do it on the thread that resizes the window, after the window has
been resized and made to paint itself, and while it is hidden; showing the
window is then only uncloaking it. It has to come after rendering the window:
rendering leaves the compositor of a swap chain window as stale as it was, and
the window took over a hundred milliseconds after being shown to show
anything, as a gap of wallpaper where it was meant to be.
Making a window paint itself (a render of it is synchronous) went through
Snapshot::capture, which also allocated and filled a second picture of the
visible frame, copied it out of the first and cut its corners, to throw it all
away: about a quarter of what taking a picture costs, on the thread that
gates showing the window again.
Split rendering a window out of taking a picture of it and make paint_now only
render. And when taking a picture, do not run over millions of pixels to make
them opaque when a window has rendered them that way, as it does: look at a
grid of them across the picture, and only fall back to making every pixel
opaque if one of those is not.
Time the picture a ghost takes of its window (allocating, PrintWindow and
turning it into a picture), the render a window is asked for to lay itself
out (paint_now), how long a ghost takes to make, and what the frames of a
group of animations cost: how long drawing them takes, how far apart they
come and how many are late. All at trace level, the frame statistics at
debug.
While a ghost stands in for a window the window is hidden and not where the
ghost is, and an animation moves its border along with the ghost. But the
border also follows the real window: every event komorebi handles ends with
a border update that reads the rect of the real window, and so does every
location change of it, and komorebi's own cloak, uncloak and resize of the
window produce both. Each of them put the border where the window is going to
be, or was, for a frame, until the next frame of the animation moved it back:
the border jumped ahead of the window, by as much as the whole width of the
screen when moves overlapped.
Say which windows a ghost stands in for, from when the ghost is made until it
is gone (or the animation is cancelled), and leave the borders of those to the
animation.
Recorded over 16 moves of mixed pace, a border was moved by something other
than its animation 21 times before; on a swap in the right column, 6 times
before (up to 127px off) and none after.
A ghost was a live thumbnail of its window, so it showed whatever the window
painted: the stretched old frame, then the blank frame a window paints while
it lays itself out again (Explorer shows its toolbar and nothing else for a
few hundred milliseconds), then the new layout, replacing the picture all at
once after the animation was over, and it stayed on screen about 300ms past
the end of the move while it waited for that. Every ghost also had a host
window of its own that was moved with SetWindowPos on every frame through a
channel to a thread that polls for commands every 8ms.
Take a picture of the window with PrintWindow before anything is done to it
(cropped to the visible frame, with the corners rounded) and show it through
a cloaked window of our own that DWM can take a thumbnail of and scale on the
GPU. All ghosts are composed onto one layered, click-through host window that
covers the virtual screen, and is only above other windows while a ghost is
alive so that it does not get in the way of the taskbar's auto-hide:
animating a ghost is one DwmUpdateThumbnailProperties call on the animating
thread, which has no thread affinity. The number of registered thumbnails is
counted and traced so that a leak of compositor handles can be seen.
The real window is cloaked and resized at the start of the animation, on a
thread of its own, and asked to paint itself at its new size straight away
(taking a picture of it makes it render synchronously) while the ghost is on
screen, so that it has the whole animation to lay itself out unseen. At 55%
of the way through, the window is shown again under the ghost (with the one
pixel size change that windows which render through a swap chain need for
their compositor to rebuild its render target) and the ghost fades out over it
while still moving, so the picture dissolves into the window instead of being
replaced after. A window that is slow to take its new size is not waited for:
it is shown once it is ready, or, if the animation ends first, waited for with
the ghost over it and then faded out over a few frames. Windows that are
minimized or gone are not ghosted.
Each window that moved in a layout pass was animated on a thread of its own,
each preparing itself, drawing its frames and finishing by itself, so the
windows of a swap could be a little ahead of or behind one another, and a
ghost could appear over its window noticeably later than the ghost of the
window it was swapped with.
Collect the animations started while a workspace is being updated in an
AnimationBatch and run them on a single thread: they are prepared at once, so
that starting takes as long as the slowest of them (a ghost takes a picture of
its window) and not as long as all of them, every one is prepared before the
first frame, every frame of all of them is drawn before the compositor is
asked to present it (waiting for it with DwmFlush when a ghost is being
animated), and they finish and fade out together. Animations cancelled by a
newer one still drop out one at a time, and the wait for a cancelled one to
stop is checked every 4ms instead of every 125ms: it notices once per frame,
so the longer wait only delayed the animation replacing it.
Closing a window sends Hide and not Destroy to many applications. The Hide
arm re-tiled without asking Windows to focus the surviving window, so no
window had the foreground and the border did not follow focus. Use the
same refocus rule as the Destroy arm.
Spreading a stack out into a column left two things wrong, both seen in a
recording of toggle-column-stack:
- The window that stays in the original container was never restored. When it
was the tab at the back it stayed cloaked, and its column was empty until
focus reached it. Only the windows that moved to new containers were
restored.
- Each new container took focus when it was inserted, so the strip scrolled a
column to bring it into view, and did not scroll back once the containers
were put in the one column again. The strip was left a column to the left,
with an empty third of the screen. Focus now stays on the column that they
are put in.
Test both, with windows that are hidden as stacking hides them.
Remove the single-monitor restrictions on the Scrolling layout. Each
workspace keeps a strip of its own, and a window is seen on whichever monitor
it overlaps, so placement now looks at the other monitors: a window that
scrolled out of view past an edge that another monitor is next to is hidden
instead of parked, and a partly visible one is cut down to its own work area.
A window that comes back into view is shown again first, but only the one at
the front of its container: the others are the tabs at the back of a stack,
which are hidden because they are at the back.
A window that scrolls out of view comes to rest at the edge of the work area
that it left by, with 5 pixels of it still on screen, keeping its size so that
nothing is resized to bring it back and an animation back into view is short.
Reuses the existing movement animations.
Also test the Workspace glue: widths, consume, expel, moving a column, and
that retile forgets the widths that windows were found to refuse.
After windows are placed, ask each how wide it really is. A window that is
wider than its column was made to be widens the column to fit, and the columns
after it move along. A column never gets narrower again because of this, and
never wider than the screen.
What a window says about its size is only used once it can be trusted: with
synchronous window handling and no animation in flight, and for an overhang
of more than 16px, so that rounding, a terminal's cell grid, or a window that
is still moving does not widen a column for good. Adopting a width is logged
at info level.
schema.json gets the center_focused_column layout option as a boolean or one
of Never, Always and OnOverflow, and schema.bar.json, which embeds the socket
messages, gets the new scrolling commands.
Focus, move, resize, retile and closing a window now go through the strip of
columns in the Scrolling layout. New commands: consume, expel,
toggle-column-stack, scrolling-layout-full-width and center-focus. A top
level scrolling section configures centering, centring a lone column, and
the minimum height of a window in a column of several.
komorebi-layouts now carries what a host needs of the Scrolling layout
without touching an operating system: the scrolling config section and its
checked settings, the layout options for the model, placement of containers
in a work area, resizing a column or tile, and the hand-over of column
records between workspaces. It re-exports the model as
komorebi_layouts::scrolling::model, so komorebi-for-mac can pick all of it up
through its existing komorebi-layouts git dependency.
Also add the Workspace methods for columns, consume/expel/stack, focus and
ordering, which sit on top of it.
The Scrolling layout now keeps a ScrollingSpace per workspace, keyed by
container id, instead of recomputing equal-width columns from the previous
layout on every update. Column widths follow layout_options.scrolling.columns
and persist as windows come and go.
Dragging the edge two stacked tiles share moves it by the same amount from
either tile, in the layout and in the window manager. A drag of the top edge
of the lower tile that moves nothing is not for want of this.
A daemon that is killed does not get to uncloak the windows it hid, and the
next one skips them as cloaked, so they stay out of sight and unmanaged.
A cloak by komorebi reads the same as one for another virtual desktop or a
suspended app, so keep a record of the windows that are cloaked and uncloak
those that the last daemon left behind, before looking for windows.
libz-sys before 1.1.31 logs the compiler command of its zlib probe, which
with cc 1.6.0 or later includes every environment variable of the build,
and cargo stores that output under target/. It is a build dependency of
shadow-rs via git2 and libgit2-sys; bump it in the lockfile.
Displays were matched on serial_number_id.eq(..) || device_id.eq(..), so
two displays with no serial number matched each other through None == None,
and two with no device path through the shared "UNKNOWN" device id. When
a display without either was unplugged, the one that stayed attached
"matched" it, nothing was removed, and every display change started the
3s verification again; state kept listing the display for good.
A serial number now identifies a display only when both have one and it is
not empty, and a display without a device path is told apart by its name.
The removal takes the monitors out by index instead of by id, so that two
displays sharing the id UNKNOWN are not removed together, and adding a
connected monitor no longer skips a display for sharing that id.
PlacementTarget deserialized through String, so the integer the docs
promise ("initial_window_placement_rules": 2) made the daemon exit at
start with an untagged enum error while "2" worked. Accept integers as
well as strings.
The derived schema described an externally tagged object that neither
form matches, so describe the type by hand and regenerate both schemas.
move_container_to_monitor and move_workspace_to_monitor took the container
or workspace out of its place and only then looked the target monitor up,
so a monitor index that does not exist left the window on screen but in no
workspace. Check the index first so the command fails and nothing moves.
The socket handlers for manage, ignore, object-name-change, tray, layered
and title bar rules skipped a new rule when any simple rule had the same
id, whatever its kind, so ignore-rule exe foo after ignore-rule class foo
was dropped. Share one helper that compares the kind as well.
Everything but dependencies.json is stored with LF, which nothing said, so
a CRLF file could get in unnoticed (it did, for two files, in a round trip
that shows as a rewrite of every line of both).
* .gitattributes: normalize every text file to LF in the repository and
check it out with LF, whatever core.autocrlf is (the Windows runner
defaults it to true)
* rustfmt.toml: newline_style = "Unix", so cargo fmt --check fails on
a Rust file with CRLF
* CI: fail when a file is stored with CRLF
* dependencies.json: the one file that was stored with CRLF
Measure mouse resizes from the rect the window had when the drag
started, work in edges instead of guessing from rect fields, resize the
container of the dragged window, and bound resizes by the resulting tile
sizes (granting as much as fits) rather than by the size of the
container being resized.
There are a bunch of edge cases coming up with this behaviour. Setting
the default to false for now so people on the nightly can opt in as they
feel comfortable.
5f629e1f made directional focus cycle the monocle container in the
underlying ring. Useful on a single monitor, but undesired when focusing
across monitors — the focus stays trapped on the monocle workspace
instead of crossing the boundary.
This commit adds a new top-level monocle_focus_behaviour option with two
variants, Cycle (the post-5f629e1f behaviour) and NoOp (the pre-5f629e1f
behaviour, now the default), along with a ToggleMonocleFocusBehaviour
socket message and corresponding komorebic subcommands to flip between
them at runtime.
This commit tries to render move/resize animations on a DWM-thumbnail
"ghost" window instead of calling MoveWindow per-frame on the real HWND.
The source is cloaked via IApplicationView::SetCloak, the thumbnail is
animated via DwmUpdateThumbnailProperties on a layered host owned by a
single "ghost owner" thread, the border for the source follows the
lerped rect via a new WM_ANIMATE_RECT message handled on the border's
own WndProc thread (preserving today's per-frame border tracking), and
the real SetWindowPos happens once at the end of the animation.
Apps repaint exactly once per animation instead of N times, which is a
substantial win for heavy renderers (browsers, IDEs, Office). For
non-Chromium sources the source is also pre-positioned to target_rect
before the thumbnail is registered so the captured texture is target-
sized and downscales to native 1:1 at the end of the animation rather
than upscaling to a stretched/blurry final frame.
Chromium-shell sources skip the pre-paint step: their
NativeWindowOcclusionTrackerWin reads DWMWA_CLOAKED and treats any cloak
value as hidden, suspending the renderer; WM_SIZE while cloaked produces
no new frame and the post-uncloak swap chain shows stale or black
content.
For those apps we keep the source cloaked at start_rect for the whole
animation and do the SetWindowPos in post_render after uncloak, where
the visibility flip is what wakes Viz back up.
A short ease-in opacity crossfade in post_render masks the texture
transition for the Chromium path and gives slow renderers time to
present their first post-resize frame before the overlay is removed.
This commit fixes a cross-thread use-after-free crash with exception
code 0xc000041d (FATAL_USER_CALLBACK_EXCEPTION), identified via WinDbg
analysis of a minidump where rax=0xfeeefeeefeeefeee at the crash site in
d2d1!HwndPresenter::Present - the Windows heap freed-memory fill pattern
confirming Direct2D dereferenced a previously freed object.
The root cause was a data race between the border manager thread and the
border's own message loop thread. Border::create() spawns a dedicated
thread (Thread B) for the HWND message loop and sends Box<Border> back
to the border manager thread (Thread A) via a channel. After this point
both threads accessed Border::render_target concurrently without any
synchronisation:
Thread A called update_brushes() directly on the Box<Border>, replacing
render_target with a new ID2D1HwndRenderTarget and dropping the old one.
Dropping the old RenderTarget decremented the COM refcount to zero,
causing D2D to free its internal HwndPresenter.
Thread B was concurrently mid-render in a WM_PAINT or
EVENT_OBJECT_LOCATIONCHANGE handler, holding a reference to that same
old render target obtained via the GWLP_USERDATA raw pointer. Calling
EndDraw() after HwndPresenter was freed produced the crash. The process
uptime of two seconds in the dump confirmed this happened during startup
workspace initialisation, when a ForceUpdate notification triggered
update_brushes() while the newly-shown border window was processing its
first WM_PAINT.
The fix routes all brush update requests through the border's own
message loop by posting a custom WM_UPDATE_BRUSHES (WM_USER + 1) message
instead of calling update_brushes() cross-thread. The three call sites
in the border manager that previously called border.update_brushes()?
directly now call border.request_brush_update(), which posts the message
via PostMessageW. The WndProc handler for WM_UPDATE_BRUSHES calls
update_brushes() and invalidate() entirely on Thread B, eliminating the
race.
A secondary bug in destroy() was also fixed: it was clearing
GWLP_USERDATA before posting WM_CLOSE, which caused WM_DESTROY's null-
pointer guard to skip the render_target = None cleanup. This left the
ID2D1HwndRenderTarget alive past HWND destruction, and D2D freed its
HwndPresenter during WM_NCDESTROY while the COM wrapper still held a
reference - a second path to the same crash for any message queued
between WM_NCDESTROY and WM_QUIT. The premature GWLP_USERDATA clear has
been removed; WM_DESTROY already handles it correctly after releasing
the render target.
This commit implements something I've found myself wanting while working
on the Macbook.
When I have a monocle container active, I want to quickly be able to
switch back and forth with an adjacent window in the underlying layout
without having to toggle monocle mode off and back on again.
This is now accomplished by using focus left/down to promote the
previous window in the Ring to monocle, and by using focus right/down to
focus the next window in the Ring to monocle.
Borders were being funny so I just ended up nuking them whenever we
cycle.
This commit moves layout-related code into a new workspace crate
komorebi-layouts, with the intention of re-using it all in komorebi for
Mac instead of maintaining two separate implementations.
This commit attempts tofixfixes a use-after-free bug in the
border_manager that was causing crashes with exception code 0xc000041d
(FATAL_USER_CALLBACK_EXCEPTION) when borders were being destroyed during
config updates.
The root cause was a race condition between the main thread destroying a
border window and the border's window thread still processing queued
window messages (EVENT_OBJECT_LOCATIONCHANGE, WM_PAINT).
The crash occurred when these callbacks invoked render_target.EndDraw(),
which internally calls HwndPresenter::Present() to present the rendered
frame to the HWND. By this point, the HWND and its associated Direct2D
surfaces had been freed by WM_DESTROY, resulting in Direct2D attempting
to dereference freed memory (0xbaadf00dbaadf00d - debug heap poison
value).
The previous attempts at fixing this issue (bdef1448, dbde351e)
addressed symptoms but not the fundamental race condition. bdef1448
attempted to release resources on the main thread before destruction,
but this created a cross-thread race. dbde351e moved resource cleanup to
WM_DESTROY, but this still allowed EVENT_OBJECT_LOCATIONCHANGE/WM_PAINT
handlers to check `render_target.is_some()`, context-switch to
WM_DESTROY which clears it, then context-switch back and call EndDraw()
on a now-invalid reference.
This commit attempts to eliminate the race condition by introducing an
atomic destruction flag that serves as a memory barrier between the
destruction path and the rendering paths:
- Added `is_destroying: Arc<AtomicBool>` field to the Border struct
- In destroy(): Sets the flag with Release ordering, sleeps 10ms to
allow in-flight operations to complete, then proceeds with cleanup
- In EVENT_OBJECT_LOCATIONCHANGE and WM_PAINT: Checks the flag with
Acquire ordering both at handler entry and immediately before calling
BeginDraw/EndDraw, exiting early if destruction is in progress
The Acquire/Release memory ordering creates a synchronizes-with
relationship that ensures:
1. When the destruction flag is set, all subsequent handler checks will
see it (no stale cached values)
2. Handlers that pass the first check but race with destruction will be
caught by the second check before touching D2D resources
3. The 10ms sleep window allows any handler already past both checks to
complete its EndDraw() before resources are freed
This is a lock-free solution with zero overhead on the hot rendering
path (atomic loads are nearly free) and provides defense-in-depth with
multiple barriers against the use-after-free condition.
This commit ensures that we check if a window is already managed in any
workspaces even after checking known_hwnds, because windows moved as
part of the earlier ensure_workspace_rules call can slip through the
cracks.
This commit fixes a use-after-free bug in the border_manager that was
causing crashes with exception code 0xc000041d when borders were being
destroyed during workspace/monitor changes.
The root cause was a race condition between the main thread destroying a
border window and the border's window thread still processing queued
window messages (WM_PAINT, EVENT_OBJECT_LOCATIONCHANGE). The crash
occurred when these callbacks invoked render_target.EndDraw(), which
internally calls HwndPresenter::Present() to present the rendered frame
to the HWND. By this point, the HWND and its associated DirectX surfaces
had already been freed, resulting in Direct2D attempting to dereference
freed memory (0xFEEEFEEEFEEEFEEE - Windows heap poison value).
The issue stemmed from two problems in destroy_border():
1. Direct2D resources (render_target and brushes) were not being
released before closing the window. These COM objects hold internal
pointers to the HWND and its DirectX swap chain/surfaces. When
close_window() was called, Windows began tearing down these resources
while the Direct2D objects still held dangling pointers to them.
2. GWLP_USERDATA was not being cleared before closing the window. This
meant that any messages already queued in the window's message queue
could still retrieve the border_pointer and attempt to render using
the now-invalid Direct2D resources.
This commit addresses both issues:
- In destroy_border() (mod.rs): Explicitly set render_target to None and
clear the brushes HashMap before calling destroy(). This ensures that
Direct2D COM objects are properly released while the HWND is still
valid, preventing EndDraw() from accessing freed HWND resources.
- In destroy() (border.rs): Clear GWLP_USERDATA before calling
close_window(). This ensures that any pending window messages will see
a null pointer and exit early from the callbacks (which already have
null pointer checks in place).
These changes create two layers of defense against the race condition:
the callbacks won't access the border_pointer (it's null), and even if
they somehow did, the render_target would be None so no rendering
operations would occur.
I think this is the root cause of a lot of crash tickets that people are
mistakenly attributing to specific applications which lack
reproducibility across different users/machines, i.e. #1626, #1624.
The WorkspaceTenantName is populated far more consistently than MdmUrl.
This commit switches to extracting that instead and passing it on to the
MDM splash screen so that users on non-corporate devices who may have
unintentionally enrolled themselves into BYOD MDM by logging into an
account a clicking "Yes" on some dark pattern pop-up have a clear
indication of why they are seeing the splash, and can take the
appropriate steps to remove the MDM profile from their system if
desired.
I think this got broken as part of the automatic Rust version syntax
upgrades which joined two if clauses together with && which should have
been kept separate.
Now, if the user gives the --bar flag to the start command, and a static
config file is not resolved, or if the static config file does not have
a bar_configurations stanza, it will fallthrough to the default
PowerShell snippet to try and start komorebi-bar without an explicit
--config flag.
This commit fixes the stupidest of stupid bugs. Column width
calculations on the Scrolling layout should take the number of windows
into account, especially when lower than the configured column count.
I was getting really tired of having to switch between display inputs to
different platform-specific machines to be able to make and test changes
on komorebi for Windows and komorebi for Mac.
With this commit, the `flake.nix` provides a Nix devShell and crane
build for users to make and validate changes with `cargo check`, `cargo
clippy` and `cargo build` with the Windows MSVC toolchain on Linux and
macOS.
Getting tired of making little changes in both this and the komorebi for
Mac repo - I think eventually either komorebi-themes will live in its
own repo or komorebi for Mac will be integrated here.
But for now, at least everything is defined in komorebi-themes and I
don't have to redefine any theme-related stuff in komorebi for Mac.
This commit ensures that the various default values that the different
Option<T> config properties can be unwrapped to are encoded by schemars
so that they can be picked up by docgen.
LGUG2Z