This commit adds an icon cache which is indexed by executable name to
avoid unnecessary calls to windows_icons::get_icon_by_process_id, which
is known to start failing after the komorebi-bar process has been
running for a certain (unknown) period of time.
This commit makes it so a floating window only has the floating border
when it is focused, if not it has the `Unfocused` border. It also makes
the 'focused_container' have the `Unfocused` border when it is not the
foreground window, for example when we have a floating window focused
instead.
This commit also changes the border's `window_kind` so that the stored
borders actually have that value so we can check it later (This value
wasn't being updated).
This commit also makes it so we properly invalidate the borders in the
situations discussed above (for example when changing focus to/from a
floating window we need the floating window border to update its ZOrder
as well as the previously focused window).
Lastly this commit, changes the `WM_PAINT` code part of the border so
that it now sets the position of border so that the border's ZOrder
updates to it's tracking window ZOrder.
This commit introduces a number of changes to the border manager module
to enable borders to track the movements of windows as they are being
animated.
As part of these changes, the code paths for borders to track user
movement of windows have also been overhauled.
The biggest conceptual change introduced here is borrowed from
@lukeyou05's work on tacky-borders, where the primary event listener of
the komorebi process now forwards EVENT_OBJECT_LOCATIONCHANGE and
EVENT_OBJECT_DESTROY messages from application windows directly on to
their borders.
These events are handled directly in the border window callbacks,
outside of the main border manager module event processing loop.
In order to handle these events more performantly in the border window
callbacks, a number of state trackers have been added to the Border
struct.
When handling EVENT_OBJECT_NAMECHANGE, these values are read directly
from the struct, whereas when handling WM_PAINT, which is sent by the
system whenever we invalidate a border window, we update the state
values on the Border structs from the various atomic configuration
variables in the mod.rs file.
Another trick I borrowed from tacky-borders is to store a pointer to the
Border object alongside a border window whenever it is created with
CreateWindowExW, which can be accessed within the callback as
GWLP_USERDATA.
There is some unfortunate introduction of unsafe code to make this
happen, but the callback uses null checks to exit the callback early to
ensure (to the best of my ability) that there are no pointer
dereferencing issues once we start making border changes in the context
of the callback.
There are a few other Direct2D related optimizations throughout this
commit, mainly avoiding the recreation of objects like brush properties
and brushes.
Finally, the border_z_order option is now deprecated as the border
window is now tracking the z-ordering of the application window it is
associated with by default - this should resolve a whole host of subtle
border z-ordering issues, especially when dragging windows around using
the mouse.
This work would not have been possible without the guidance of
@lukeyou05, so if you like this feature, please make sure you thank him
too!
This commit adds a new komorebic command, "kill", to kill background
processes that may be started by "komorebic start", without terminating
the main komorebi process.
This is useful when iterating on changes to external components like the
bar which may require restarts.
This is a small change to the start command which moves the check for
the komorebi processes to come a little bit earlier.
This small change will make running commands like "komorebic start
--bar" around 3s faster when komorebi is already running.
The visual changes include:
* the focused_window section is now indicating the active window in a stack and has hover effect.
* custom icons for all the layouts, including `paused`, `floating`, `monocle` states.
* custom layout/state picker with configurable options.
* display format configuration for the layouts (Icon/Text/IconAndText)
* display format configuration for the focused_window section (Icon/Text/IconAndText)
* display format configuration for the workspaces section (Icon/Text/IconAndText)
This commit fixes an issue where when trying to move floating windows or
windows on a floating workspace across boundaries to another monitor
using the `move_container_in_direction` it wouldn't move the floating
windows physically, although it moved them internally on komorebi,
resulting in weird and wrong behavior.
This commit creates a new method on `Monitor` to
`add_container_with_direction` which takes a move direction and then
uses the same logic that was previously on the
`move_container_in_direction` function.
It changes the `move_container_to_monitor` function to take an optional
move direction which if it is some will have this function call the new
method `add_container_with_direction` instead of just `add_container`.
Lastly the `move_container_in_direction` function now when it realizes
the move will be across monitors simply calls the
`move_container_to_monitor` with the direction that was initially given
to it.
These changes require that all callers of `move_container_to_monitor`
add an direction option, instead of passing `None` on all of them, a new
helper function was created, named `direction_from_monitor_idx` which
calculates the direction a move will have from the currently focused
monitor and the target monitor return `None` if they are the same or
returning `Some(direction)` if not. This way now all commands that call
a move across monitor will use the logic to check from the direction if
it should add the container on front or end.
With these changes now all the code related to moving a window across
monitors using a command should be on one place only making sure that in
the future any change required only needs to be done on one place,
instead of having to do it on `move_container_to_monitor` and
`move_container_in_direction` as before!
This commit is an interactive squashed rebase of the following commits
from PR #1154:
8f4bc101bc
fix(wm): move floats in direction across monitors
This commit fixes an issue where when trying to move floating windows or
windows on a floating workspace across boundaries to another monitor
using the `move_container_in_direction` it wouldn't move the floating
windows physically, although it moved them internally on komorebi,
resulting in weird and wrong behavior.
This commit creates a new method on `Monitor` to
`add_container_with_direction` which takes a move direction and then
uses the same logic that was previously on the
`move_container_in_direction` function.
It changes the `move_container_to_monitor` function to take an optional
move direction which if it is some will have this function call the new
method `add_container_with_direction` instead of just `add_container`.
Lastly the `move_container_in_direction` function now when it realizes
the move will be across monitors simply calls the
`move_container_to_monitor` with the direction that was initially given
to it.
These changes require that all callers of `move_container_to_monitor`
add an direction option, instead of passing `None` on all of them, a new
helper function was created, named `direction_from_monitor_idx` which
calculates the direction a move will have from the currently focused
monitor and the target monitor return `None` if they are the same or
returning `Some(direction)` if not. This way now all commands that call
a move across monitor will use the logic to check from the direction if
it should add the container on front or end.
3b20e4b2fe
refactor(wm): use helper function on move to workspace
Use the same `add_container_with_direction` function on
`move_container_to_workspace` as it is being used on
`move_container_to_monitor` or `move_container_in_direction`.
This way we bring parity between all methods and make it easier to
change the way a container is added on a monitor workspace when taking
the move direction into consideration.
83f222fe84
* fix(wm): correctly define moves across monitors
Moves within the same workspace were being considered as moves across
monitors when the workspace was floating (not tiled).
This commit fixes this by changing the way we first define if a move was
across monitor or not.
We now search for the moved window on all workspaces and check if its
monitor index is different from the target monitor index (the monitor
where the move ended).
a02694348e
* fix(wm): ignore moves/resizes on floating workspaces
This commit makes sure that moves or resizes within a floating workspace
(i.e. not tiled) will be ignored, unless the move is across monitors.
We don't care about the positions or sizes of windows within a floating
workspace!
4bf24f81e0
* fix(wm): avoid workspace load on cross monitor moves
This commit replaces the `window_manager.focus_workspace` call with a
`monitor.focus_workspace` which doesn't load the workspace. There is no
need to load the workspace when moving windows across monitors since
those workspaces will already be loaded, we simply need to update them.
Loading the workspace would cause some issues as well, like when moving
a window to a floating workspace which already contained a window that
matched some `floating_windows` rules was always putting the
"floating_window" on top of the window we just moved with a bunch of
focus flickering. This is fixed with this commit.
cb53f463ae
* fix(wm): avoid workspace load on command move across monitor
If the move happens between the already focused workspaces of two
monitors we shouldn't load the workspace, since it is already loaded and
it will cause changes on focused windows, which might result on the
window we just moved not being focused.
* Added a new floating area at the center of the bar
* Optional center widgets config, fixed spacing on the center widget
* Turning transparency on by default
When moving maximized floating windows across monitors they were
magically disappearing!
The window would be on the correct place, with the correct coordinates
and size, its styles wouldn't change it would still have the `VISIBLE`
style, however the window was invisible.
If we used the system move to try to move it sometimes we would be able
to see a bar on the top of the monitor and if we moved the window with
the keyboard on the direction of another monitor then the window would
start showing up on that monitor... So it was visible on that monitor
but not on the one we just moved it into.
After some investigation I decided to atribute that behavior to magic,
since I couldn't find any other plausible explanation, if someone knows
about this please tell me, I too would like to learn the ways of this
dark mysteries from the deep of the Windows OS.
On a serious note, this commit creates a workaround for this by simply
unmaximazing the window first (it's not restore, it doesn't change the
size) then it moves the window (if animations are enabled it proceeds to
wait for the animation to finish...), then it maximizes the window
again.
Previously when moving floating windows across monitors we would keep
the size of the window as it was. For most cases this would be ok.
However for users with monitors with completely different sizes this
could result on a window that would fill across monitors when moving
from the bigger monitor to the smaller monitor.
This commit, attempts to resize the windows proportionally to the
monitors' sizes.
There is currently a slight issue with some apps (so far I've only
noticed it on 'Wezterm'...) where if the DPIs across monitors are
different they don't seem to fully get the OS DPI change completely, but
it seems that setting the `Wezterm` compatibility high DPI scaling
override to "System" on the app's executable properties, fixes the
issue.
Since this is only 1 app (so far...) and only when the scales between
monitors are different I decided to commit this anyway.
This will do more good than harm, since in the cases it was misbehaving
with 'Wezterm' the result would be a wrongly resized window that is
still completely visible on the target monitor anyway and the override
fix seems to be good so far.
This commit is comprised of the following interactively rebased commits
from PR #1002 by @thearturca.
1a184a4442
refactor(animation): move animations to its own mod
First step for more rusty version animations. The goal is to make
animations more generic so its easier to add new animations to komorebi!
d3ac6b72c2
refactor(animation): reduce mutex calls on `ANIMATION_STYLE`
8a42b738fe
refactor(animation): introduce `Lerp` trait
e449861c10
refactor(animation): generalized ANIMATION_MANAGER
Instead of a isize key for the ANIMATION_MANAGER HashMap, now we use a
String key. For window move animation, the key would be
`window_move:{hwnd}`.
This allows us to use single manager for more types of animations.
67b2a7a284
feat(animation): introduce `AnimationPrefix` enum
8290f143a6
feat(animation): introduce `RenderDispatcher` trait
2400d757fe
feat(animation): implement window transparency animation
This commit also fixes graceful shutdown of animations by disabling them
before exit and wait for all remaining animations for 20 seconds.
44189d8382
refactor(animation): move generation of `animation key` to `RenderDispatcher`
e502cb3ffb
refactor(animation): rename `animation` mod to `engine`
Linter was upset about this:
> error: module has the same name as its containing module
369107f5e0
feat(config): adds per animation configuration options
Originally static config only allowed global config for animations.
Since this refactor introduces the abilty to add more type of
animations, this change allows us to configure `enabled`, `duration` and
`style` state per animation type.
Now each of them take either the raw value or a JSON object where keys
are the animation types and values are desired config value. Also adds
support for per animation configuration for komorebic commands.
There was an issue where if you changed focus across monitors and the
target monitor had a maximized window it would focus one of the
containers beneath it instead. And if there were no containers it
wouldn't focus anything, but instead keep focus on the previous monitor.
This commit fixes that issue.
This commit follows up on a point made by @notTamion in #1128 - since we
have the monitor index, we can use it in the bar's workspace widget to
more accurately target workspaces via
SocketMessage::FocusMonitorWorkspaceNumber.
This commit adds the "CtByte" and "CtByteWithShadow" aliases for the
"Default" and "DefaultWithShadow" GroupingStyle variants respectively as
an easter egg to recognize @CtByte's work in implementing the grouping
feature.
This commit is a small fix which ensures that the latest value of
transparency_alpha will be read and applied from config rather than
self.config in the apply_config fn.
This commit ensures that when switching to a workspace which contains a
floating window or a maximized window, either the maximized window or
the first floating window index will be focused.
This is to prevent windows which have been hidden on the previous
workspace from retaining keyboard focus.
fix#1130
This commit adds various widget grouping and transparency options to
komorebi-bar, and is comprised of the individual commits listed below,
worked on in PR #1108, squashed into one.
e8f5952abb
* adding RenderConfig, and some test frames on widgets
0a5e0a4c0a
* no clone
a5a7d6906c
* comment
6a91dd46cd
* ignore unused
80f0214e47
* Group enum, Copy RenderConfig
fbe5e2c1f7
* Group -> Grouping
ce49b433f9
* GroupingConfig
f446a6a45f
* "fmt --check" fix (thanks VS)
d188222be7
* added widget grouping and group module
1008ec2031
* rounding from settings, and apply_on_side
7fff6d29a9
* dereferencing
655e8ce4c1
* AlphaColour, transparency, bar background, more grouping config options
cba0fcd882
* added RoundingConfig
ec5f7dc82d
* handling grouping edge case for komorebi focus window
12117b832b
* changed default values
645c46beb8
* background color using theme color, AlphaColour.to_color32_or, updating json format for Grouping and RoundingConfig
10d2ab21c7
* hot-reload on grouping
d88774328a
* grouping correction on init
2cd237fd0d
* added shadow to grouping, optional width on grouping stroke
4f4b617f26
* grouping on bar, converting AlphaColour from_rgba_unmultiplied, simplified grouping
3808fcec8f
* widget rounding based on grouping, atomic background color, simplified config, style on grouping
be45d14f6d
* renamed Side to Alignment, group spacing
be45d14f6d
* proper widget spacing based on alignment
b43a5bda69
* added widget_spacing to config
c18e5f4dbe
* test commit
cba2b2f7ac
* refactoring of render and grouping, widget spacing WIP
9311cb00ec
* simplify no_spacing
36c267246b
* correct spacing on komorebi and network widgets (WIP)
85a41bf5b2
* correct widget spacing on all widgets
50b49ccf69
* refactoring widget spacing
9ec67ad988
* account for ui item_spacing when setting the widget_spacing
e88a2fd9c0
* format
This commit overhauls the "Komorebi" borders implementation to use
Direct2D, which enables anti-aliasing for rounded borders.
A lot of the heavy lifting was done by @lukeyou05 in the tacky-borders
project, which this commit largely adapts to komorebi. @lukeyou05
provided an incredible amount of guidance and feedback on the
implementation of this feature on the komorebi Discord.
This commit is a squashed interactive rebase of the following commits:
238271a71e
feat(borders): initial impl of direct2d border drawing
5525a382b9
feat(borders): avoid multiple render target creation calls
431970d7b6
feat(borders): reduce redraws to improve perf
47cb19e54a
feat(borders): remove black pixels around direct2d corners
3857d1a46c
feat(borders): clean up render targets on destroy
