We had a mut requirement on some of the Window functions which may have
been vestigial or in preparation for more state on Window objects, but
presently unused. I removed that, as the Window struct is currently just
carrying an HWND value that's essentially always immutable - there's no
advantage to ever reusing a Window struct vs. making a new one for
another HWND.
In doing so we then no longer needed to be passing in mutable events, so
I applied a little simplification of the event receiver / dispatcher to
process_event. After that it became obvious that we could just pass the
owned event directly into process_event instead, which substantially
simplifies the ownership model and lifetime for those objects.
This is small, and shouldn't create any meaningful behavioral change.
This commit fixes a small regression and ensures that the active window
border, when enabled, will be drawn as expected when a container stack
has a stackbar active.
Previously we were dropping events that don't pertain to managed
windows, with one exception in should_manage that could probably do with
further cleanup (DisplayChange).
This first step fixes the latent border window problem, where we would
retain a border window when the last managed window was closed and focus
transitioned to an unmanaged window.
This commit ensures that the focused container index on a workspace is
updated appropriately if the user calls toggle-float on the last
Container in a Ring. Previously, doing this would leave a ghost tile.
Now that we check if the focused_idx is still valid after removing an
empty Container from the workspace, users will no longer be left with a
ghost tile.
This commit ensures that the MoveResizeEnd handler will only proceed if
the window triggering the event is a managed window on the focused
workspace.
fix#733
This commit ensures that if an applications.yaml revision is passed
which includes the now-deprecated border_overflow option, komorebi will
gracefully handle it instead of crashing on an unknown enum variant
error.
A user reported in an issue that their komorebi data dir did not persist
across reboots. While there have not been any other reports of this type
of system behaviour, it's worth just doing a mkdir -p equivalent call
whenever komorebi.exe is starting to ensure that the socket files can
always be created no matter what.
re #731
This commit adds a new active window border style configuration option
to komorebi.json, allowing users to explicitly opt in to square or
rounded active window borders to match whatever patches they may have
made at the system / dwm.exe level.
This commit introduces the stackbar feature through careful extracting
and refactoring of code from the Komorebi-UI hard-fork.
Unfortunately on the fork, this feature was not implemented using atomic
commits, which resulted in the implementation here being more of a
"reinterpretation" than a lift-and-shit of the referenced code.
Nevertheless, this commit represents a working version of the stackbar
feature.
resolve#681
This commit adds support for composite rules in the static configuration
file, and for float_identifiers in the applications.yaml file.
A new enum, MatchingRule provides two variants, Simple and Composite,
and is now used in place of IdWithIdentifier throughout komorebi.
In order to keep this new enum lean, a variant for
IdWithIdentifierAndComment has not been added, and references to it in
the old config generation code have been replaced with MatchingRule.
resolve#462, resolve#715, resolve#237
This commit adds a 10 millisecond thread sleep specifically for Firefox
as an interim solution for the race condition which results in new
windows often not being tiled correctly until interacted with.
The idea to add a sleep instead of spamming the output with dbg! calls
comes from @kornel@mastodon.social:
https://mastodon.social/@kornel/112125851048707993
This commit ensures that ApplicationFrameHost.exe applications developed
by Microsoft are raised correctly when a user has the custom komorebi
ffm implementation enabled.
The Win32 API calls EnumWindows and WindowFromPoint return different
HWNDs for the same windows because of some jank in how the
ApplicationFrameHost apps are developed.
To avoid this inconsistency on the Win32 API level, komorebi now queries
its own state when looking up HWNDs for windows at any given cursor
position.
This commit swaps out the old "raise" fn for the more up-to-date and
tested "focus" fn when raising a window for focus when the "komorebi"
implementation of focus follows mouse is enabled.
It seems like when we use the bottom flag, Rainmeter widgets will be
drawn on top of windows that are managed by komorebi. After looking at
the GlazeWM codebase, where this issue does not occur, it seems like the
difference is made by the use of the notopmost flag.
resolve#679
