This commit introduces a new configuration option,
cross_boundary_behaviour, which allows the user to decide if they want
Focus and Move operations to operate across Workspace or Monitor
boundaries.
The default behaviour in komorebi has always been Monitor. Setting this
to Workspace will make komorebi act a little like PaperWM, where
"komorebic focus left" and "komorebic focus right" will switch to the
next or previous workspace respectively if the currently focused window
as at either the left or right monitor boundary.
resolve#959
This commit ensures that Shutdown signals will be sent to subscriber
sockets and that "komorebi.sock" will be cleaned up on exit.
Alongside these changes, komorebi_client::send_message no longer retries
so that integrators can receive feedback via io::Result errors when
komorebi is not running.
This commit ensures that a WindowManagerEvent::Show will not be
triggered when a WinEvent::ObjectNameChange is received for an
application in the object_name_change_on_launch whitelist.
This notably impacts Firefox when the window title changes while the
application is minimized (for example, on a page with YouTube autoplay
enabled).
fix#941
Addresses a regression introduced somewhere along the way in changing
how borders and rects sizes are calculated. Need to come back and see if
the constant calculated with the mix of BORDER_WIDTH and BORDER_OFFSET
is still relevant anymore.
fix#942
This commit adds a new command, focus-stack-window, which allows users
to focus windows in the focused container stack by their index
(zero-indexed) within the stack.
If the user tries to focus an index which does not correspond to a
window within the container stack, an error will be logged.
This commit ensures that the "Komorebi" border implementation is set as
the default as it has the maximum range of compat across different
Windows versions, whereas the "Windows" implementation requires Win 11.
Because "Windows" implementation methods will error on Windows 10,
restore_all_windows has been updated to only attempt to remove accents
if BorderImplementation::Windows is selected (this is gated behind the
WINDOWS_11 check).
re #925
This commit ensures that when a window_based_work_area_offset is set,
and the window limit is greater than 0, the offset will be applied to
monocle containers on a workspace (unless an override is specified for
that workspace).
This commit demotes the komorebi-core crate to a module (core) inside of
the komorebi lib, resulting in the komorebi-client crate lib becoming
the single public interface for programming in Rust against komorebi.
komorebic and komorebi-gui now consume komorebi-client exclusively as
the means for sending and receiving messages to and from komorebi, so
that anyone wishing to integrate with komorebi will have all of the same
functionality to them as I do.
This commit builds on these changes in win32-display-data:
https://github.com/LGUG2Z/win32-display-data/commit/32a45cebf132c3d651ee22c0c40033a6b7edc945p
With the addition of lenient fallbacks when looking up display device
information for "RDPUDD Chained DD" virtual display adapters, komorebi
will now set Monitor.device and Monitor.device_id to "UNKNOWN" as this
virtual mirror display driver will never have a reported DeviceID.
This limitation for "RDPUDD Chained DD" devices is also noted in a
Chromium issue: https://codereview.chromium.org/2557513005/fix#883
There are quite a lot of janky animation bugs when moving window
containers across monitor and workspace boundaries.
This commit disables animation on all of the main cross-border window
container operations, meaning that animations should now only happen
within the context of a single workspace.
fix#912
This commit adds a new focus manager module to be used to trigger async
focus changes with mouse follows focus updates. Currently this should
only need to be used with animations as all other focus calls are
synchronous.
fix#910
Work on this feature was first started by @thearturca in November 2023
before komorebi v0.1.21 in #597 and has undergone numerous revisions
to reach the point of this commit.
Although this is a single squashed commit, almost all of the heavy
lifting for this feature was done by @thearturca, which is where all of
the kudos and gratitude should be directed.
This commit adds a new static configuration block for animations, where
they can be enabled, and have their style, fps and duration set.
Corresponding SocketMessages and komorebic cli commands have also been
exposed.
There are some caveats to the use of this feature, which revolve around
the quality of the Windows compositor (it is not very good):
* There will be visual artifacts with various apps when animations are
taking place - komorebi can't do anything about this as it is a
limitation of the Windows compositor
* Since komorebi's borders are implemented as independent windows are
are not a part of the windows they are drawn around, these borders
will be hidden while animations are in progress
* If you wish to use borders with this feature, you'll probably better
off using BorderImplementation::Windows, which uses the native thin
"accent" borders, which are part of the windows they are drawn around,
and can be moved with those windows during animations
As a result of these and other caveats, this feature will be marked as
"experimental" for the foreseeable future and will be off-by-default.
Below, a number of now-squashed commits that contributed to the
stabilization of this feature are referenced to help with code
archeology in the future.
fix(animation): Fixed cancelling logic
(57e9b2f4bcaedb4fdfa71adf785d661690d81dfc)
Added static animation state manager for tracking "in_progress" and
"is_cancelled" states. The idea is not to have states in Animation
struct but to keep them in HashMap<hwnd, AnimationState> behind
reference (Arc<Mutex<>>). So we each animation frame we have access to
state and can cancel animation if we have to.
Need review and testings
refactor(animation): avoid unwrap
(fa6d5bbc77c1882f85ee1ce73733ff7e53b39eaa)
fix(animation): Move cancel call to Animation struct
(306513f5dbe5f6bd6ce817f3edca0bfda13d9442)
Only focused window was cancelling its animation because we call cancel
in window::set_position and waiting for its cancelling. And because we
waiting for cancelling second window is still moving. Second window will stop
moving only after the first window. So I moved `cancel` call to
Animation struct so its happening in its own thread and doesn't block
others animation moves and cancels.
refactor(animation): renamed args parameters and variables names
(8abb4b9618bbb3823b868fc37551f0a70b98281e)
refactor(animation): inverse if-statement in `window::animate_position`
(3de2c6e932614651892da4a8c626946e427375dd)
There is was a bug when ease function generates `t` greater the
`SetWindowPos` function will be called instead of `move_window`.
`SetWindowPos` is only for last frame of animation.
fix(wm): add shadow rect to `move_window` calls
(b58620fb4de36d8e422a80541bedf9c1c1579a31)
This fixes a bug when windows get shunk during the animation
This commit ensures that one-off workspace rules added at runtime via
komorebic or generally via SocketMessages will be added to the output of
the generate-static-config command.
This commit adds three new commands, clear-workspace-rules,
clear-named-workspace-rules and clear-all-workspace-rules, to allow
users to remove workspace rules at runtime.
These commands do not distinguish between initial or persistent
workspace rules. If there is a clear use case for this distinction, this
decision can be revisited at a later date.
resolve#908
This commit adds two new fields, minimum_window_height and
minimum_window_width, to the static configuration file.
These options should be considered quite broad and heavy-handed for now
and avoided if at all possible.
These options are an escape hatch for buggy applications such as Windows
Teams which do not give application windows and child windows unique
names or classes.
Ultimately users should push for buggy applications to be fixed upstream
and respect the usual Microsoft Windows application development
guidelines.
Further support will most likely not be provided for these two
configuration options because it's not my job or my responsibility to
compensate for multi million, billion and trillion dollar companies who
can't follow basic application development guidelines.
resolve#896
This commit adds an override option
"apply_window_based_work_area_offset" to the Workspace configuration
object in the static config.
This option defaults to true to preserve existing behaviour, and can be
set to false for workspaces where the monitor-level offset changes are
undesirable.
This commit adds a soft-deprecation message for the Hide and Minimize
variants of WindowHidingBehaviour to start bringing all users towards
using the Cloak variant.
resolve#897
This commit adds a dynamic lookup method for the
window_container_behaviour configuration option. Previously if the
behaviour was set to Append, and the workspace did not have any
containers, an error would be logged.
Now, in the same situation, the behaviour will be dynamically switched
to Create when there are no containers on a workspace, and subsequent
windows will be handled with the Append behaviour if set.
This commit also makes some tweaks to ensure that when a windows in a
container stack are closed, the container itself will remain focused if
it has at least one remaining window.
resolve#889
This commit ensures that every non-focused index in a Ring<Window> will
be hidden when a new window is added and focused via
Container::add_window, which typically happens when
WindowContainerBehaviour::Append is enabled and a new window is opened.
re #889
This commit adds the ability for users to select between komorebi's
implementation of borders with variable widths and the native Windows 11
implementation of thin "accent" borders.
The new border_implementation configuration option defaults to
BorderImplementation::Komorebi in order to preserve compat with existing
user configurations.
This option will be most useful for people who prefer ultra-thin
borders, and people who want borders to be animated along with
application windows if they are using the animation feature being worked
on in PR #685.
This commit ensures that message handling threads for windows that are
created by komorebi are exited properly when the windows are destroyed.
For some reason, passing the HWND returned by CreateWindowExW to
GetMessageW continues returning TRUE even after the window has been
destroyed.
If HWND::NULL (via the Default trait) is passed to GetMessageW, which
retrieves messages for any window belonging to the current thread (our
threads here only own a single window), GetMessageW returns FALSE as
expected after the window is destroyed.
re #862
This commit is the result of a long investigation with @berknam on
Discord which uncovered that when the channels used by the *_manager
modules are full, the window manager can enter a completely locked state
which will require a hard restart of komorebi.exe.
In order to avoid entering this locked state, *_manager modules now no
longer publicly expose event_tx for sending notifications.
Instead, a new public fn send_notification is exposed which will use
try_send to attempt to send notifications in a non-blocking manner and
log warnings if the channel is full and the notification is dropped.
This commit increases various channel bounds from 5 to 20 since it was
discovered that this reduction had no impact on #862, and some
crashes/freezes have been noted due to the channel bounds of 5 being too
low.
This commit ensures that we only invalidate a border rect to send a
WM_PAINT message either when the position of the focus state of the
border has changed.
re #862
This commit pushes up the calls to BeginPaint and EndPaint in the border
callback function to ensure that the client area of the border rect is
always validated after calls to InvalidateRect from the update fn.
The callback now also logs errors whenever it is not possible to get the
border rect to operate on for any reason.
There was a call at the end of this logic to ValidateRect which has been
removed as the validation is already handled by the call to BeginPaint.
re #862
This commit handles three subtle edge cases which surfaced after adding
state snapshot comparisons to the border manager module.
1) Update borders when windows are dragged
2) Update borders on pause and unpause
3) Redraw borders on retile
These two edge cases do not change the snapshot state but still require
updates to be made to the borders.
This commit introduce state snapshot checks in the border manager, which
will ensure that we don't even attempt to acquire any mutex locks if the
state hasn't changed.
This commit ensures that in the event of a panic (we still have quite a
few that occur sporadically that are still being tracked down), the
listen_for_commands thread in process_command is restarted, similarly to
the recently added border, stackbar and transparency manager threads.
In order to do this without blocking the process startup sequence,
listen_for_commands spawns an outer thread which begins a loop in which
the actual command listener thread is started.
We call .join() on the handle of this inner thread, and log an error
whenever that inner thread terminates, as it should never terminate
unless there is a panic.
If the inner thread is terminated due to a panic, the outer loop will
start another thread to ensure that user commands continue being
processed.
One thing to note is that panics may lead to an inconsistent wm state
and undefined behaviour which will seem "new", as previously these
panics required a total restart of komorebi and any inconsistent states
would be masked.
This commit ensures that windows moved to a floating workspace on a
different monitor will have their positions updated accordingly for the
target monitor. Since floating layouts have no layout algorithm applied,
the moved window will be centered in the work_area of the target monitor
in the target workspace.
fix#865
This commit ensures that stackbar clicks will be handled properly by the
transparency manager by creating an override to process events for
windows which may not be at the top of the stack and may have previously
been made transparent before they were hidden.
fix#864
This commit makes the quickstart command aware of the
KOMOREBI_CONFIG_HOME environment variable. If this is set by the user,
references to Env:USERPROFILE will be replaced with
Env:KOMOREBI_CONFIG_HOME.
fix#861
This commit introduces a small refactor to the transparency manager
module to log instead of propagating errors which may cause infinite
thread restarts and memory ballooning in KNOWN_HWNDS if applications
such as Visual Studio do not conform to the Win32 guidelines for setting
and removing Extended Window Styles.
re #863
This commit adds a new monitor-information command to make it easier for
people to find the values they need to use the display_index_preferences
configuration option.
re #860
This commit adds the transparency manager module, which, when enabled,
will make unfocused windows transparent using a user-configurable alpha
value between 0-255.
The corresponding komorebic commands (transparency, transparency-alpha)
have been added, as well as the corresponding static configuration
values (transparency, transparency_alpha).
This feature is off-by-default and must be explicitly enabled by the user.
If the process is not shut down cleanly via the 'komorebic stop'
command, it is possible that the user will be left with transparent
windows which will not be managed by komorebi the next time it launches.
This is because the WS_EX_LAYERED style is required for transparency,
but is ignored by default in komorebi's window eligibility heuristics.
For this reason, a separate state tracker of windows that have had this
style added by the window manager is kept in the transparency manager
module.
For this edge case of shutdowns where the cleanup logic cannot be run,
the 'komorebic restore-windows' command has been updated to remove
transparency from all windows that were known to the window manager
during the last session before it was killed.
This must be run _before_ restarting komorebi, so that the previous
session's known window data is not overwritten.
In the worst case scenario that the previous session's data is
overwritten, the user will have to either kill and restart the
applications, or compile komorebi from source and explicitly set
"allow_layered" to "true" in the window_is_eligible function, before
setting the transparency alpha to 255 (fully opaque), and then resetting
to the desired value.
This is a mixture of refactoring and a fix, updating the
Direction::is_valid_direction trait impl for Default layout to return
early with false if the count is < 2.
fix#851
This commit ensures that HPEN, HBRUSH and HFONT objects which are used
to draw stackbar tabs are explicitly destroyed with calls to
DeleteObject after ReleaseDC has been called.
re #855
This commit ensures that HPEN and HBRUSH objects created to draw window
borders are explicitly destroyed with calls to DeleteObject after
EndPaint has been called.
re #855
This commit switches to using the bitflags from_bits_truncate fn to
handle applications like Foxit Reader which use garbage bits that aren't
part of the Window Styles or Extended Window Styles Win32 specs.
Any unknown bits that are not in the Win32 specs will be unset when this
function is run.
This commit allows for the user to expand container stacks while focused
on an an existing (len > 1) container stack by using the stack command
with a desired direction.
resolve#847
This commit adds two new commands, stack-all, which puts all windows in
the focused workspace into a single stack, and unstack-all, which
unstacks all windows in the currently focused container.
This commit finally sunsets the derive-ahk proc macro and the
ahk-library cli command.
There is now a dedicated, stripped down komorebi.ahk example on the docs
website which mirrors the contents and style of the sample whkdrc:
https://lgug2z.github.io/komorebi/common-workflows/autohotkey.html
This commit makes a small change to dynamically keep reserving space in
the VecDeque that backs Ring<Monitor> until an index preference can be
contained within the current length.
This commit also fixes some clippy lints and adds some allow
annotations.
This commit changes the handlers for the Close and Minimize
SocketMessages to operate on the output of
WindowsApi::foreground_window, without checking the window manager state
as it was doing previously.
This will allow the commands to operate on any kind of managed or
unmanaged window, and the appropriate WinEvent will be emitted by the
closed window for the window manager state to be updated when the
WinEvent goes through process_event.
fix#839
This commit ensures that EVENT_OBJECT_NAMECHANGE is handled for all
windows.
Previously this was mapped to WindowManagerEvent::Show, as this is the
event that apps like Firefox and JetBrains IDEs sent on launch instead
of EVENT_OBJECT_SHOW like normal apps.
Now that we are using EVENT_OBJECT_NAMECHANGE to update titles on
stackbar tabs, when a window which is not in the whitelist of
object_name_change_applications sends this event, it will be handled by
the new WindowManagerEvent::TitleUpdate variant.
This ensures that a stackbar_manager::Notification is sent at the end of
process_event to update stackbar tabs when application titles are
changing.
resolve#842
Until now the orphan window/container reaper has always run on every
WinEvent. Unfortunately Windows Terminal does not sent a WinEvent when
it is closed.
This is a problem for the new border_manager module which draws and
destroys borders based on notifications sent to it after WinEvents and
SocketMessages have been processed.
Since Windows Terminal is not sending a WinEvent on close, this means
that user interaction is required to remove the ghost border that gets
left behind.
This commit starts a separate thread for the reaper where it runs once
every second in a loop.
This is quite wasteful and definitely not something I wanted to
implement, but a temporary solution is needed given the popularity of
the buggy application in question.
An issue on the Windows Terminal tracker has been opened here:
https://github.com/microsoft/terminal/issues/17298
This commit ensures that whenever we receive a
stackbar_manager::Notification any stackbars not associated with the
current workspace on each monitor are destroyed.
fix#838
This commit fixes a regression introduced by hiding other containers
when monocle is enabled. When the monocle container is closed, other
containers on the workspace will now be restored.
re #834
This commit adds the komorebi-gui debug tool build with egui and eframe.
This tool was built from scratch in a YouTube mini-series which can be
found here: https://www.youtube.com/watch?v=zZKjBMt4kZ4
The most interesting part of this tool right now is the ability to view
debug information about each window as it goes through the rules engine.
While it's possible to change runtime configuration options with this
tool, it is not yet possible to write those changes out to the
configuration file.
This commit ensures that horizontal focus moves onto other monitors from
a monocle container are respected (ie. we don't try moving left/right
within the workspace on the focused monitor).
Additionally, if the user tries to alt-tab a window to the foreground on
a workspace where a monocle container exists, the window will flash
before being hidden behind the monocle container as a visual cue that
monocle mode needs to be disabled to access that window.
This is in contrast to the current behaviour where that window floats on
top of the monocle container in a somewhat broken state.
re #834
This commit removes all stackbar-related code from Container, Workspace,
process_command, process_event etc. and centralizes it in the new
stackbar_manager module.
Instead of trying to figure out where in process_event and
process_command we should make stackbar-related changes, a notification
gets sent to a channel that stackbar_manager listens to whenever an
event or command has finished processing.
The stackbar_manager listener, upon receiving a notification, acquires a
lock on the WindowManager instance and updates stackbars for the focused
workspace on every monitor; this allows us to centralize all edge case
handling within the stackbar_manager listener's loop.
Global state related to stackbars has also been moved into the
stackbar_manager module, which also tracks the state of stackbar objects
(STACKBAR_STATE), mappings between stackbars and containers
(STACKBARS_CONTAINERS) and the mappings between stackbars and monitors
(STACKBARS_MONITORS).
A number of edge cases around stackbar behaviour have been addressed in
this commit (re #832), and stackbars now respect the "border_style"
configuration option.
This commit adds the monitor_reconciliator module which uses a tightly
bounded channel (cap: 1) to handle monitor connection and disconnection
events, as well as resolution and work area change events.
Before, all this logic lived in a the WindowManager.reconcile_monitors
function, which ran on pretty much every process_event iteration, and
sometimes led to undesirable behaviour, but now the logic is split up to
only run when the appropriate notifications are dispatched from the
hidden window which listens for monitor and display-related events.
The monitor cache has been moved out of WindowManager and into the
monitor_reconciliator module, and in addition to the previous behaviour
of attempting to cache monitors which had been identified as
disconnected, now when the static configuration file is loaded, if the
user has set display_index_preferences, the device IDs will be used to
pre-populate the cache for the event where a known monitor is connected
later in a session.
The monitor cache itself now uses the unique device ID as a key rather
than the hmonitor which is known to be inconsistent.
This commit also delegates all display monitor-related Win32 calls to
the "win32-display-data" crate, which was extracted from the larger
"brightness" crate for its use in komorebi.
As a result of these changes, "device" and "device_id" on Monitor have
been changed from Option<String> to String types, as failures in
retrieving these values with directly attached monitors has not been
possible to reproduce. However, it remains to be seen if this will
adversely impact users who use display docks which may prevent display
monitor device IDs from being read and stored by the operating system.
WindowManagerEvent::DisplayChange has been removed in favour of
the monitor_reconciliator::Notification enum, as these events are no
longer being handled in process_events.
Attempts are now made to eagerly update hmonitors both within the
monitor_reconciliator loop on DisplayConnectionChange notifications and
when failing to find a matching hmonitor in functions like
monitor_idx_from_current_pos and monitor_idx_from_window.
LGUG2Z