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:
32a45cebf1p
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.
