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.
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.
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
This commit adds a new komorebi command "cycle-stack-index" which allows
the user to manipulate the index position of the focused window in the
focused stack by swapping it with either the previous or the next window
until the desired index position has been found.
After investigating further the issue where commands would randomly stop
working, we've noticed that the issue seems to be that somehow the
listening thread gets stuck reading the unix socket, as in it
continuously tries to read a socket on a connection that is not sending
anything anymore. The result would be that komorebi would no longer be
able to receive commands until it was restarted.
This fix adds a read timeout of 1s and it spawns a new thread to handle
the stream reading and process of cmds. So in case this happens again,
that specific processing thread will only be stuck for 1s but the rest
of komorebi will never get stuck and should keep working normally.
This change prevents the move animation from playing again for each
window in the stack. Tested with all hiding behaviors. Looks good so
far.
resolve#1029
This commit ensures that when attempting to reload the static
configuration file after the user has imperatively created new
workspaces, the configuration reload logic will not attempt to load a
workspace config for those imperatively created workspaces.
This commit ensures that the exact workspace indices are tracked in the
komorebi widget state.
This fixes a bug where an incorrect workspace index could be sent with
SocketMessage::FocusWorkspaceNumber if a user had hide_empty_workspaces
set to true.
fix#1102
This commit introduces a new komorebic command, close-workspace. This
command will remove the focused workspace from the window manager state
if the following conditions are met:
1. The number of workspaces on the focused monitor are >1
2. The workspace is empty
3. The workspace is unnamed
The third condition is to ensure that we are not removing workspaces
which have been declared in the static configuration file.
This commit ensures that if an IdWithIdentifer without an explicitly set
matching strategy makes it through to should_act_individual, it will be
treated the same as MatchingStrategy::Legacy instead of causing a
runtime panic.
This commit switches all relevant commands to treat the v2
applications.json asc format as the default format in all commands.
The v1 applications.yaml file will still be processed correctly if
passed.
This commit fixes the issue related to moving windows to/from a floating
workspace to a tiled workspace.
Previously the start of the move would be ignored however when moving
back from a tiled workspace since it didn't know about the existance of
that window it would also "move" that workspace focused tiled window
without physically moving it, leaving it in a weird state that seemed
like it was unmanaged.
This commit changes the way this mouse moves are handled and now also
handles moving `floating_windows` and even monocle or maximized windows.
This commit allows calls to Border::destroy to fail when called in the
context of border_manager::destroy_all_borders. This is important in the
context of the retile command, which calls this function, to not leave
the retile in an inconsistent state.
This commit ensures that when both the origin and target containers are
stacks during a stack operation, the "slurping" stack extension
behaviour introduced in cfb0c7f2ce will
not be applied.
fix#1085
