This commit makes all schemars::JsonSchema derives optional. After
analyzing the output of cargo build timings and llvm-lines, it was clear
that the majority of the 2m+ incremental dev build times was taken up by
codegen, and the majority of it by schemars.
Developers can now run cargo commands with --no-default-features to
disable schemars::JsonSchema codegen, and all justfile commands have
been updated to take this flag by default, with the exception of the
jsonschema target, which will compile with all derives required to
export the various jsonschema files.
Incremental dev build times for komorebi.exe on my machine are now at
around ~18s, while clean dev build times for the entire workspace are at
around ~1m.
This commits adds the ability to set icons for the `workspace-layer` with
the `DisplayFormat` and a setting to specify if it should `show_when_tiling`
or not.
collab with @alex-ds13
This commit ensures that the resize dimensions will be reserved for
other monitors and workspaces when the
toggle-window-based-work-area-offset command is used.
This commit fixes a breaking change on the selected_frame that was
introduced by eframe version 0.31.
In this version, the stroke is drawn on the inside of a Frame instead it
being drawn on the outside like before.
This now means that a stroke needs to be added on all the states of the
Frame in order to avoid all the elements to be moving around on hover.
Previously the stacking logic would sometimes change the focused
container without actually changing focus to said container.
This resulted in the stack showing up with an unfocused border even
though we had focus on one windows belonging to the stack (just not the
right one).
Also before it wasn't possible to stack windows on some directions
when we were already on a stack.
This commit fixes both issues.
This commit fixes multiple issues with the borders which were resulting
in multiple borders being created and not completely destroyed which
meant that the amount of borders in memory kept increasing indefinitely
the more we used komorebi. To do so this commit does the following:
- Clear all the maps on `destroy_all_borders`.
- Create function `remove_border` which should always be used when we
want to remove a border since this function destroys the border window
and removes all its related data and clones from all the maps.
- Create function `remove_borders` which should always be used when we
want to remove multiple borders or filter the current existing
borders. It takes in a `condition` function that takes a ref to the
border's container id and a ref to the border and should return a
bool. This function is then applied to each existing border and if it
evaluates to true it will call `remove_border` on it.
- Apply these new functions on all the code that was previously manually
removing borders.
- When a container is a stack, we now check it's unfocused windows, in
case they had borders attached to them we remove them, otherwise these
borders would persist and be drawn below other borders.
- We now check if a container's border was previously tracking a different
window, if it was we destroy that border and remove it's hwnd from the
`FOCUS_STATE` and then we check if its `tracking_hwnd` still points to
the same border and remove it if it does (if it doesn't that means
that a new border was already attached to that window so we don't
remove it).
We don't call `remove_border` here since we don't want to actually
remove the border but instead we replace it with a new one tracking
the correct window. (I've tried updating the `tracking_hwnd` instead
of destroying the border and creating a new one but that didn't work
since it still kept tracking the previous window...).
This commit makes it so when you toggle between workspace layers it
moves all windows of that layer to the top of the z-order.
So if you move to `Floating` layer, then all floating windows are moved
to the top, and if you go back to the `Tiling` layer, all tiled
containers are moved to the top.
This commit makes sure that the accent color is used on certain bar
components, such as active workspace, selected layout and focused
window.
This will now make these components stand out even more for a better
visual indication.
fix#1288
This commit stops the `FocusChange` event from focusing a floating
window when it is the one emitting said `FocusChange` event, since it's
not needed and is the cause of some flicker bugs reported!
If that floating window was the one emitting the `FocusChange` event
then it means it is already the foreground window, and there is no
reason for us to focus the window again (since that will create an
infinite loop of events).
When the window emitting this event is not floating we don't try to
focus the window, we simply set the focus index for the container of
that window and the focused index for the window of that container.
Except in one case, which is if the workspace has a monocle container,
then it does focus a window, it focuses the monocle window to make sure
the monocle keeps showing in front of everything and doesn't let
anything come in front of it.
Previously the reaper at startup would lock it's own `HWNDS_CACHE` and
then try to lock the WM to get its `known_hwnds`.
However if there was an event in the meantime, process_event would lock
the WM first and then it would try to lock the reaper's `HWNDS_CACHE` to
update it. This would deadlock since that would be locked by the reaper
waiting for the WM lock to be released.
This commit now makes it so we pass the `known_hwnds` to the reaper as
an argument at startup and it also rearranges the order of loading the
listeners.
Now komorebi first loads all the manager-type listeners, and only
afterwards does it load the commands and events listeners.
After some testing this seems to be the best order that doesn't cause
any issues at all!
There were some other issues that I've noticed before when starting
komorebi while having other 3rd parties trying to subscribe to it (like
komorebi-bar and YASB), which would make those subscribers lock the
`process_command` thread. This doesn't seem to be happening on my tests
anymore with this new order.
This commit makes sure the bar applies the the `work_area_offset`
correctly after a monitor reconnects; if it is the first time a monitor
is connecting, the cached offset won't exist yet.
This commit fixes an issue where if you started komorebi without a
monitor connected, and then connected it later, it wasn't properly
loading the data returned from `win32-display-data`.
This commit adds an extend_enum! macro and some unit tests to provide
an ergonomic way to specialize configs for specific (sub)widgets.
The macro takes the name of the existing enum, the desired name of the
new, extended enum, and a list of variants which should be added to the
extended enum.
The macro will add new variants to a new enum definition first, before
wrapping the existing enum in an Existing variant and tagging it with
the `#[serde(untagged)]` annotation.
From is also implemented for ergonomic from/into calls between shared
variants of the existing and extended enums.
This commit adds the ability to set container and workspace padding per
monitor.
To do so (and to simplify any future need of changing some value per
monitor), and have it pass through to each workspace a new field was added
to `Workspace` called `globals` which has a new struct called
`WorkspaceGlobals`.
`WorkspaceGlobals` includes any global values that might be needed by
the workspace.
This field is updated by the monitor for all its workspaces whenever the
config is loaded or reloaded. It is also updated on `RetileAll` and on
the function `update_focused_workspace`.
This should make sure that every time a workspace needs to use it's
`update` function, it has all the `globals` up to date!
This also means that now the `update` function from workspaces doesn't
take any argument at all, reducing all the need to get all the
`work_area`, `work_area_offset`, `window_based_work_area_offset` or
`window_based_work_area_offset_limit` simplifying the callers of this
function quite a bit.
Lastly this commit has also (sort of accidentaly) fixed an existing bug
with the `move_workspace_to_monitor` function.
This was previous removing the workspace from a monitor, but wasn't
changing it's `focused_workspace_idx`, meaning that komorebi would get
all messed up after that command. For example, the `border_manager`
would get stuck and the komorebi-bar would crash.
Now, the `remove_focused_workspace` function also focuses the previous
workspace (which in turn will create a new workspace in case the removed
workspace was the last workspace).
Previously if a workspace had any floating windows it would always focus
the first one when restoring. Now it only focus the floating window if
the workspace layer is `Floating`.
This commit introduces an implementation of workspace layers to
komorebi.
Workspace layers change the kinds of windows that certain commands
operate on. This implementation features two variants,
WorkspaceLayer::Tiling and WorkspaceLayer::Floating.
The default behaviour until now has been WorkspaceLayer::Tiling.
When the user sets WorkspaceLayer::Floating, either through the
'toggle-workspace-layer' command or the new bar widget, the 'move',
'focus', 'cycle-focus' and 'resize-axis' commands will operate on
floating windows, if the currently focused window is a floating window.
As I don't have 'cycle-focus' bound to anything, 'focus up' and 'focus
down' double as incrementing and decrementing cycle focus commands,
iterating focus through the floating windows assigned to a workspace.
Floating windows in komorebi belong to specific workspaces, therefore
commands such as 'move' and 'resize-axis' will restrict movement and
resizing to the bounds of their workspace's work area (or more
accurately, the work area of the monitor that the workspace belongs to,
as floating windows are never constrained by workspace-specific work
area restrictions).
This commit changes the way the reaper works.
First this commit changed the `known_hwnds` held by the `WindowManager`
to be a HashMap of window handles (isize) to a pair of monitor_idx,
workspace_idx (usize, usize).
This commit then changes the reaper to have a cache of hwnds which is
updated by the `WindowManager` when they change. The reaper has a thread
that is continuously checking this cache to see if there is any window
handle that no longer exists. When it finds them, the thread sends a
notification to a channel which is then received by the reaper on
another thread that actually does the work on the `WindowManager` by
removing said windows.
This means that the reaper no longer tries to access and lock the
`WindowManager` every second like it used to, but instead it only does
it when it actually needs, when a window actually needs to be reaped.
This means that we can make the thread that checks for orphan windows
run much more frequently since it won't influence the rest of komorebi.
Since now the `known_hwnds` have the monitor/workspace index pair of the
window, we can simply get that info from the map and immediately access
that monitor/workspace or use that index info.
The `WorkspaceConfig` stored on `Workspace` was changed to not be
serialized, however it needs to be serialized and deserialized when
caching a monitor (after a disconnect), so that when it reconnects it is
able to read all the workspace rules, which include:
- initial_workspace_rules
- workspace_rules
- window_container_behaviour_rules
- layout_rules
- custom_layout_rules
This commit changes the serde skip to only skip if is is `None`.
This means that the `komorebic state` command will have all this
information as well and it will send it when notifying subscribers too,
which isn't good at all, so we need to find another way of excluding it
from the state.
This commit introduces a few changes to the bar so that it can handle
the monitor disconnect/reconnect properly and so that it can map the bar
config to the correct monitor.
Previously if you had 3 monitor configs setup on `komorebi.json` with
the `display_index_preferences` set like this:
```
"display_index_preferences": [
"0": "MONITOR_A",
"1": "MONITOR_B",
"2": "MONITOR_C",
]
```
But if you only had connected monitors A and C you would have to
manually change the bar configurations monitor index because now monitor
A would have index 0, but monitor C would have index 1 instead of 2.
Now with this commit this is no longer needed. Now the monitor index
setup on the bar configuration **MUST BE** the index you've used on
`display_index_preferences` for that monitor.
So in the case above you would setup the bar configurations using the
indices 0, 1 and 2 for monitors A, B and C respectively.
As for the changes introduced on this commit they are the following:
- `Komobar.monitor_index` is now an `Option`. When it is `None` it
either means that the bar is starting and has not yet received the
first `State` from komorebi or that the bar is disabled.
- `Komobar.config` is no longer an `Arc`. There was no need for that and
it was creating more issues and difficulties. It was mainly used to
pass the config as an `Arc` to `apply_config` function, but then this
function would actually clone the config itself (not just the `Arc`).
Also this function was passing a `self.config.clone()` most of the
times except once when it received a new config from a hotreload. Now,
on hotreload it first sets `self.config` to the new config and then
calls `apply_config` which now uses its own `self.config` everywhere.
- We only change the `work_area_offset` when the bar is not disabled.
- We update the global `MONITOR` size/coordinates when we receive a
`DisplayConnectionChange` from komorebi.
- We also check if the monitor size/coordinates have changed from the
currently stored ones on every komorebi notification since sometimes
the `DisplayConnectionChange` would be emitted while the state still
had the previous size/coordinates.
This makes sure we always capture a change of size/coordinates, store
the new values, and update the bar.
- The previously mentioned update of the `MONITOR` coordinates also
updates the `config.position.start` since that value is being
overriden on `main.rs` in case the user hasn't set it so we need to
override it again with the new monitor coordinates.
This might mean that users of the old config system might have their
start position changed, but if we didn't do this the bar wouldn't even
show on the screen for them when a monitor disconnected/reconnected.
This is another case for users to start moving into the new config
system, since with that system the bar will still show up with the
correct margins!
This commits adds a few more events that can trigger a
`DisplayConnectionChange` event.
Some of these events are redundant and after a display is
disconnected/reconnected it emits multiple `DisplayConnectionChange`
events.
However, when trying to remove them to have just one it stopped behaving
as it should, as if it was missing the update, while having them
duplicated it works properly.
Therefore it appears to be better to keep them for now, since the
duplicated events will exit early as soon as they see that the monitor
counts match (on the first event the counts don't match so it
adds/removes the monitor and the following events see that the counts
match).
When there is a monitor disconnect/reconnect, usually it produces
multiple monitor events along with it, like the monitor resolution
change and the work area change. With the bound set to 1 it would
sometimes result in missed events.
This commit increases the bound to 20 to prevent this from happening.
This commit makes sure that if the state on file isn't up to date with
the expected `State` struct (maybe after an update) it doesn't panic
komorebi entirely, instead it ignores the state and continues with a
clean state.
This commit changes the MONITOR_CACHE to hold an actual monitor with its
state instead of the config.
This allows us to keep the state of a disconnected monitor, so that when
the monitor reconnects we still have access to all its workspaces and
windows as they were before.
While the monitor is disconnected, all the windows from that monitor are
not considered as handled by komorebi and so they're free to be handled
at any point; if for example the user uses `alt+tab` or presses the
taskbar icon of one of these windows, that window will produce a `Show`
event and will become handled by the currently focused workspace of the
focused monitor.
When the disconnected monitor reconnects it checks all windows and once
it notices that this specific window is now being shown on another
monitor/workspace, it ignores it.
This commit allows a bar to be disabled when it's monitor is
disconnected and re-enabled when said monitor reconnects.
This commit also uses the new `monitor_usr_idx_map` to properly map the
monitor index given by the users on config to the actual monitor index
on the `WindowManager` - in case some middle monitor gets disconnected
the index of the monitors to the "right" of that one will be lowered by
1.
This should allow for the following in cases with monitor A, B and C: if
monitor B disconnects, its bar will be disabled and monitor C will
properly change its monitor index internally to 1 so it still gets the
infos from monitor C (which now will have index 1 on the
`WindowManager`).
This commit creates a new field on the `WindowManager` called
`monitor_usr_idx_map` which contains a map of user intended index for
monitors to their actual monitors' index.
It will be rebuilt on `load_monitor_information` by taking into account
the `display_index_preferences`.
This commit makes sure that any workspace_rules that tried to move a
window to a monitor that has been disconnected are removed.
If the monitor is later reconnected the workspace_rules should be added
from the cached config.
This commit makes use of both `serial_number_id` and `device_id` with
the first taking priority on all monitor reconciliator code, monitor
cache and on postload and reload.
This allows using the serial numbers on the `display_index_preferences`
config, while keeping compatibility with the use of `device_id`.
Using `device_id` should be discouraged since that value can
change on restart while serial number doesn't appear to do so.
When a monitor was disconnected the containers from the removed monitor
were being moved to the primary monitor.
However they weren't restored so containers that were on an unfocused
workspace of the removed monitor would have been cloak and were getting
added to the main monitor still cloaked creating ghost tiles. This
commit fixes that.
If we have display_index_preferences that set a specific config index
for a specific display device, but that device isn't loaded yet, now we
store that config with the corresponding `device_id` on the monitor
cache.
Now when the display is connected it can load the correct config from
the cache.
This commit reworks the way the `postload` and the `reload` functions
apply the monitor configs to the monitors.
Previously it was looping through the monitor configs and applying them
to the monitor with the index corresponding to the config's index.
However this isn't correct, since the user might set the preferred
indices for 3 monitors (like monitor A, B and C), with the preferred
index set to 0 for A, 1 for B and 2 for C, but if only monitors A and C
are connected then komorebi would apply config 0 to A and config 1 to C,
which is wrong it should be 2 for C.
This commit changes the way the configs are applied on those functions.
Now it loops through the existing monitors (already in order), then
checks if the monitor has a preferred config index, if it does it uses
that one, if it doesn't then it uses the first monitor config that isn't
a preferred index for some other monitor and that hasn't been used yet.
For the situation above it means that it would still apply config 2 to
monitor C. And in case there aren't any display_index_preferences set it
will still apply the configs in order.
Store the `WorkspaceConfig` on the `Workspace` itself so that when we
want to cache the workspace as `WorkspaceConfig` on the monitor cache it
properly saves things like the workspace rules and the custom layout and
custom layout rules.
Previously, when caching a workspace config for a monitor it would
simply store the `DefaultLayout` on `layout` even if the original
workspace config had the `layout` as `None`, which makes komorebi create
a workspace with the `layout` as default `BSP` and the `tile` set to
`false`.
This resulted in floating workspaces would becoming tiling `BSP`
workspaces after a monitor disconnect and reconnect.
This commit fixes this by turning the `layout` to `None` when `tile` is
`false`.
System::new_all() pulls all information (processes, cpu, mem, etc) but
we only need process information.
In addition currently it is being polled twice. System::new() creates an
uninitialized struct, then we poll specifically for process info.
This commit is a squashed commit containing the below commits from
PR #1266, which introduces a new "Keyboard" widget, which is used to
display information about the user's currently selected keyboard input
language. This new widget has a data refresh interval of 1 second if not
specified by the user.
721d2ef40858373cd26cce27a76b36fb9054a18b55cc2fd889461a73833e781b8d0bd0fa6bf6ff76
This commit is a squashed commit of all the individual commits that made
up PR #1267 - adding various derives and re-exports aimed at improving
the komorebi integration surface for third party applications.
This commit adds a check which will only allow the focused workspace to
have a full update if the number of managed containers is non-zero.
Previously, this would be triggered in a loop when focusing a workspace
with only focused windows.
Going back in time to the first versions of komorebi and yatta which
didn't have so many different container and window kinds, this was
intended to be called whenever the focus was changed to update the
state.
With the complexity komorebi handles in 2025, there are also many calls
to Win32 APIs when we call self.update_focused_workspace, so we need to
be a bit more careful about when and where we call it.
re #816
This commit ensures that we emit a dedicated border manager event when
WinEvent::SystemForeground is received.
The OS can actually be slower than komorebi when it comes to processing
changed focus state, and in the border manager we rely on
GetForegroundWindow when calculating which the border focus state and
color should be.
This has previously resulted in a situation where there may be no border
with the "focused" color.
This should no longer be a problem because even in the situations where
the OS is slower than komorebi and is still returning an old HWND from
GetForegroundWindow, the new event that we emit to border manager in
response to WinEvent::SystemForeground will ensure that the border focus
colors get updated.
This commit adds a new komorebic command, focus-monitor-at-cursor, which
can optionally be chained with the focus-workspace command in
keybindings to reproduce the previous default behaviour of auto-focusing
whichever monitor the cursor was on before attempting to change the
focused workspace.
This commit makes sure the `layout-rules` and
`window_container_behaviour_rules` are sorted when setting them from the
config. So that the behaviour on workspace update is correct.
This commit ensures that if a user removes an optional block from the
static config file, when reloading a workspace config, the removed
option will also be unset in the window manager workspace configuration
state.
This commit improves the handling of the situation where a user, with
mouse-follows-focus diabled, focuses a secondary monitor with an empty
workspace, either via a komorebic command or by moving the cursor and
clicking on that empty workspace, and then attempts to switch
workspaces.
Previously, if the focus was made by a komorebic command, the mouse
cursor would not move from the previous monitor, and then when trying to
switch the workspace, the previous monitor would be focused against
first. The only way to change focus would be to move the mouse to the
secondary monitor.
With these changes, the following situations all work as expected:
* MFF On + MFF Off: komorebic cmd to focus an empty workspace on a
secondary monitor allows subsequent focus-workspace cmds to execute on
the newly focused secondary monitor
* MFF On + MFF Off: Moving the cursor to an empty workspace on a
secondary monitor allows subsequent focus-workspace cmds to execute on
the newly focused secondary monitor
There is one slight change in behaviour:
* MFF On + MFF Off: When the cursor is on a populated workspace on a
secondary monitor which is not focused, focus-workspace cmds will not
execute on that secondary monitor, but on the currently focused
monitor
resolve#831resolve#1128
This commit adds a new static config option,
window_container_behaviour_rules, which similarly to layout_rules, takes
a map of window container count threshold => window container behaviour.
When the number of window containers on the screen meets a given
threshold, the new window container behaviour is applied to the
workspace.
This can be used to automatically change from creating new window
containers for new windows to appending new windows to existing window
containers when the number of window containers on the screen reaches
more than what can be comfortably laid out and viewed on a user's
screen.
resolve#953
This commit pulls in changes to win32-display-data which provide the
monitor hardware serial number id taken from WmiMonitorID where
available.
No work has yet been done to integrate this with options such as
display_index_preferences.
This commit adds a title regex-based ignore list for applications
identified in object_name_change_applications. When a title change on an
EVENT_OBJECT_NAMECHANGE matches one of these regexes, the event will
never be processed as a Show.
This is an edge case workaround specifically targeting the issue of web
apps in Gecko-based browsers which update their page titles at a fixed
regular interval, which was highlighted in #1235.
resolve#1235
This commit fixes a bug where workspace rules would not be populated
properly on file reloads, leading to issues with the
ReplaceConfiguration message handler.
This commit ensures that floating windows, monocle containers and
maximized windows will be considered when the hide_empty_workspaces
option is enabled for the komorebi widget.
re #1131
This commit introduces a new PathExt trait with a fn replace_env which
can ensure all environemnt variables are loaded for a PathBuf.
As part of the initial rollout this is used in komorebi-bar to look up
environment variables for the configuration switcher widget.
resolve#1131
Added the ability of use modifiers with custom format on the Date widget.
For example if using %U returns 04, you can add a modifier so that bar
date widget shows 05.
This commit adds a new configuration option
"floating_window_aspect_ratio", which users can manipulate to set their
desired window size when using the toggle-float command.
resolve#1230
This commit ensures that Hide events on Layered windows (usually added
when the transparency feature is enabled) will always be considered
eligible for handling.
This will avoid situations where ghost borders are left behind because
the Hide event was ignored.
fix#878
This commit ensures that if mouse-follows-focus is disabled, the cursor
will not follow a focus change to a monocle container on an adjacent
monitor.
fix#1119
This commit removes the code on the workspace `update` on `layout-rules`
where it was setting the `layout-flip` to `None` if the layout was
different from `BSP`. This appears to be some old code when the
layout-flip would only apply to the `BSP` layout. However now it appears
to apply to all layouts so this code shouldn't exist. This commit also
changes the docs from the `FlipLayout` command to remove the statement
that only applied to `BSP` since it is no longer true.
This commit changes the `rx_gui` from receiving just a notification from
komorebi to now receive a new type `KomorebiEvent` which can be either a
`KomorebiEvent::Notification(komorebi_client::Notification)` or a
`KomorebiEvent::Reconnect`.
The `Reconnect` is sent after losing connection with komorebi and then
reconnecting again.
Now on the bar `update` we check for this `rx_gui` if we get a
notification we pass that to the
`KomorebiNotificationState::handle_notification` function just like
before (except now it takes a notification directly instead of taking
the `rx_gui` and checking for some message on the channel).
If instead we get a `Reconnect` we send a `MonitorWorkAreaOffset` socket
message to komorebi to update the work area offset.
This interactively rebased commit is comprised of the subsequent
individual commits listed further below.
At a high level:
- work_area_offset is now automatically calculated by default
- monitor can now take an index in addition to the previous object
- position can largely be replaced by margin and padding for bars that
are positioned at the top of the screen
- frame can now largely be replaced by margin and padding for bars that
are positioned at the top of the screen
- height is now a more intuitive configuration option for setting the
height of the bar
Detailed explainations and examples are included in the body of PR #1224
on GitHub: https://github.com/LGUG2Z/komorebi/pull/1224
fix(bar): add simplified config for bar
This commit creates a few new config options for the bar that should
make it a lot simpler for new users to configure the bar.
- Remove the need for `position`: if a position is given the bar will
still use it with priority over the new config. Instead of position
you can now use the following:
- `height`: defines the height of the bar (50 by default)
- `horizontal_margin`: defines the left and right offset of the bar, it
is the same as setting a `position.start.x` and then remove the same
amount on `position.end.x`.
- `vertical_margin`: defines the top and bottom offset of the bar, it is
the same as setting a `position.start.y` and then add a correct amount
on the `work_area_offset`.
- Remove the need for `frame`: some new configs were added that take
priority over the old `frame`. These are:
- `horizontal_padding`: defines the left and right padding of the bar.
Similar to `frame.inner_margin.x`.
- `vertical_padding`: defines the top and bottom padding of the bar.
Similar to `frame.inner_margin.y`.
- Remove the need for `work_area_offset`: if a `work_area_offset` is
given then it will take priority, if not, then it will calculate the
necessary `work_area_offset` using the bar height, position and
horizontal and vertical margins.
feat(bar): set margin/padding as one or two values
This commit changes the `horizontal_margin`, `vertical_margin`,
`horizontal_padding` and `vertical_padding` to now take a
`SpacingAxisConfig` which can take a single value or two values.
For example, you can set the vertical margin of the bar to add some
spacing above and below like this:
```json
"vertical_margin": 10
```
Which will add a spacing of 10 above and below the bar. Or you can set
it like this:
```json
"vertical_margin": [10, 0]
```
Which will add a spacing of 10 above the bar but no spacing below. You
can even set something like this:
```json
"vertical_margin": [0, -10]
```
To make no spacing above and a negative spacing below to make it so the
tiled windows show right next to the bar. This will basically be
removing the workspace and container padding between the tiled windows
and the bar.
fix(bar): use a right_to_left layout on right side
This commit changes the right area with the right widgets to have a
different layout that is still right_to_left as previously but behaves
much better in regards to its height.
fix(bar): use default bar height
When there is no `work_area_offset` and no `height` on the config it was
using the `BAR_HEIGHT` as default, however the automatica
work_area_offset calculation wasn't being done properly. Now it is!
feat(bar): monitor can be `MonitorConfig` or index
This commit allows the `"monitor":` config to take a `MonitorConfig`
object like it used to or simply a number (index).
docs(schema): update all json schemas
fix(bar): update example bar config
fix(bar): correct work_area_offset on secondary monitors
feat(bar): add multiple options for margin/padding
This commit removes the previous `horizontal_margin`, `vertical_margin`,
`horizontal_padding` and `vertical_padding`, replacing them all with
just `margin` and `padding`.
These new options can be set either with a single value that sets that
spacing on all sides, with an object specifying each individual side or
with an object specifying some "vertical" and/or "horizontal" spacing
which can have a single value, resulting on a symmetric spacing for that
specific axis or two values to define each side of the axis individually.
This commit adds the StateQuery::FocusedWorkspaceName variant to allow
users to query the name of the focused workspace via the komorebic query
command.
re #1238
This commit handles an edge case where minimize events would not be
processed if both transparency and animations were enabled at the same
time.
fix#1231
This commit adds CJK font fallbacks to Microsoft YaHei and Malgun
Gothic. This will be looked up at runtime on the user's system, and only
loaded if the files exist in the default Windows font installation
location.
resolve#1139
This commit is a follow up to 7bf1521363,
ensuring that if a user has changed global padding options, that they
will be preserved from the initialized window manager state and applied
on top of the dumped state which is being restored.
For some reason, when calling the `window.set_position` when creating
the Komobar or even when applying the config on the first frame the
actual EGUI's window size wasn't changing. This commit adds a new field
to `Komobar` called `size_rect` so that we can store the expected size
rect of the window according to the config, so that we don't have to be
calculating it all the time. This field is updated on `apply_config`.
Now on `update` of the bar we check if the current size using the EGUI
Context is the expected `size_rect`, if it is we do nothing, if it is
not we update the bar position. This makes sure that on start the bar
will resize to the users config correctly! Now the resize of the bar
only happens here.
This commit also adds the `hwnd` field to `Komobar` so that we don't
have to be calling `process_hwnd()` all the time.
This commit introduces an if let binding to only process windows which
still exist when attempting to enforce workspace rules.
Previously, calls to functions such as Window::exe might have returned
an error if a window which had been destroyed but not yet removed from
the state was examined by the enforce_workspace_rules fn. Now, such
windows will fail the if let binding and be skipped entirely, eventually
being removed by the core event processing loop.
This commit adds a new widget, "Update", which will check for komorebi
version updates using the cargo package version of the running binary
and the latest release returned from the GitHub API.
If the latest release is newer than the current cargo package version, a
widget will be shown, which can be clicked to open the changelog of the
latest release.
This commit adds an early exit from the border manager's event
processing loop whenever a window which still exists in the state but
has been destroyed is encountered. Instead of returning an error, the
'containers loop will now skip ahead to the next iteration.
This commit also makes an adjustment to the frequency with which the
reaper sends border manager notifications - a single notification is now
sent at the end of each iteration if necessary, rather than one
notification per workspace.
If a user triggers the workspace reconciliator by clicking on an app in
the start bar or via alt-tab, a notification should be sent to
subscribers such as komorebi-bar so that the focused workspace can be
updated.
The various komorebi reconciliators and manager modules don't emit
events to subscribers themselves (yet?), so for now we can pass on the
uncloak event.
Maybe we can look into expanding the Notification enum in the future.
fix#1211
This commit adds mutex lock scoping in
WindowManager::enforce_workspace_rule to avoid a deadlock when
should_update_focused_workspace evaluates to true.
fix#1212
This commit updates various docs with information on the long-promised
individual commercial use license which will be available to purchase
from 01 Jan 2025 onwards.
This commit adds a new komorebic command "eager-focus", which takes a
full case-sensitive exe identifier as an argument. When komorebi
receives this message, it will look through each monitor and workspace
for the first matching managed window and then focus it.
This allows users who have well defined workspaces and rules to bind
semantic hotkeys to commands like "komorebic eager-focus Discord.exe" to
immediately jump to applications instead of mentally looking up their
assigned workspaces or positions within container stacks.
This commit adds a new field to the static config file, "remove_titlebar_applications", which allows
users to now use the full range of matching strategies to identify applications for which titlebars
should be removed. This is heavily discouraged for a number of reasons, and is unlikely to work with
a wide range of applications which now draw their own titlebar regions. The previous advice to use
in-application configuration settings to hide title bars if they exist is still valid.
resolve#805
This commit adds the following new socket messages and commands:
- `EnforceWorkspaceRules`: resets the `already_moved_window_handles` and
calls `enforce_workspace_rules` so that all workspace rules, including
initial workspace rules are applied again
- `enforce-workspace-rules`: cli command which sends the
EnforceWorkspaceRules socket message
Sometimes the bar would randomly stop receiving notifications from
komorebi and would stop updating the `Komorebi` widget.
This feels to me that the reason is the same one that used to happen on
the `process_commands` from `komorebi` where the socket would get stuck
reading an empty connection.
This commit adds a read timeout to the socket to prevent that from
happening and hopefully it should stop those situations where the bar
would stop receiving notifications.
Previously when changing between themes with different backgrounds the
widget's background color was not updating because they take the bg
color from the `RenderConfig` which was only being updated on
`apply_config`, now we also pass the `RenderConfig` to the `apply_theme`
function and update it's `background_color` there as well.
On some computers the context colors were being reset on the very first
frame. So now we try to apply the theme on the first frame and
afterwards we only do it again when there is a config change or a theme
socket message.
There were some cases were the bar was showing some shaking, turns out
that using `ui.with_layout` instead of `ui.horizontal_centered` removes
this shaking, so this commit makes that change and uses the
`right_to_left` layout on the right widgets again, meaning that we need
to reverse them again.
Group roundings were getting lost when applying the theme after a
`komorebi.json` change/save trigger. Now we reapply these groupings on
the `apply_theme` to make sure they are always correct.
Previously when reading the `theme` from `komorebi.json` it was also
getting the transparency_alpha from the `StaticConfig`, this is wrong,
it should use the alpha from the bar config. This commit fixes that.
Previously if we changed/set the theme on `komorebi.json` it would apply
that theme to the bar without taking into account the transparency
alpha, also after removing the `theme` from `komorebi.json` file it
wasn't applying the theme from the bar config. This commit fixes these
issues.
This commit changes the way each of the 3 parts of potential widgets
(left, center and right) is created so that they are all done on the
same way and look the same. It is using `Area` with different anchors
for each part which makes the widgets actually center vertically
properly.
This created an issue with the `Bar` grouping. To fix it we've made the
`Bar` grouping change the outer panel frame instead of creating an
actual group. This has the side effect (or maybe feature!) of losing the
background of the outer frame. Meaning this outer frame will now have
the look of the `Bar` grouping only. Currently it is using a fixed outer
margin but this can be changed in the future to a config option.
This commit creates a new `SocketMessage` called `StopIgnoreRestore`
which makes komorebi stop without calling `window.restore()` on all
windows. This way every maximized window will stay maximized once you
start komorebi again and it is able to use the previous `State`.
If it fails to restore the previous state you might have to call
`komorebic restore-windows` in case you had hidden windows, for example
when when using the `window_hiding_behaviour` as `Hide`, or you can
simply unminimize them if you were using `Cloak` or `Minimize`.
This commit adds two new `DisplayFormat` types:
- `TextAndIconOnSelected`: which displays icon and text for the selected
element and the other elements only have text.
- `IconAndTextOnSelected`: which displays icon and text for the selected
element and the other elements only have icon.
This commit makes the `workspaces` on `Komorebi` widget optional. This
way it allows adding the `workspaces` on one Alignment and the
`focused_window` on another one, for example.
This commit changes the way icons are displayed on the bar.
There was an issue with how app icons were sized using shrink_to_fit.
This has been changed to use fit_to_exact_size instead, relying on the
font size as a starting point and scaling it to 1.4 of its size, making
the icons to appear larger.
The same scaling was done to all the widget icons as well to make them
look unified.
This commit makes sure we focus the previously focused workspace on all
monitors, load it and update it and in the end focus the actual focused
monitor and workspace pair calling `update_focused_workspace` to make
sure it updates the workspace and gives focus to the focused window.
This commit adds changes to the main wm process to dump a state file to
temp_dir() when the process is exited either via komorebic stop or
ctrl-c, and to automatically try to reload that dumped state file if it
exists on the next run.
A new flag "--clean-state" has been added to both komorebi.exe and the
komorebic start command to override this behaviour.
The dumped state file can only be applied if the number of connected
monitors matches the number of monitors recorded in the state, and if
every HWND listed in the state file still exists.
This is validated by calling Window.exe(), which under the hood checks
for the continued existence of the process associated with the HWND.
Only the "workspace" subsection of the state for each matching
connecting monitor will be applied.
This commit adds various transparency related global configuration
values to GlobalState, which is can be queried via the komorebic
global-state command.
resolve#1182
This commit corrects a typo which adds the "--masir" flag to the
autostart shortcut when the user has passed the "--bar" flag to the
enable-autostart command.
fix#1178
This commit makes use of the new `send_batch` function to batch all the
messages in one go when pressing the button to move between workspaces
or when moving between stacked windows.
Since we are creating this messages in one go we won't be mistakenly
changing the value of mff for the user.
It also only batches the mff messages when the mff value it's true, if
it is already false there is no need to be sending those extra messages.
This commit adds a helper function `send_batch` to komorebi-client that
allows sending multiple messages in a batch.
3rd party users of this library could already do this themselves but it
is nice to have this helper to simplify it.
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
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
Currently, komorebi checks if a move is happening by checking if the
left mouse is pressed and updates the borders when there is a move while
the left mouse button is pressed (BTW this is why when moving with the
keyboard using the system move it only updates after pressing enter).
However, for some reason AltSnap somehow steals this left button
information and komorebi thinks the button is not pressed.
This PR makes it so it checks for the state of the pending_move_op and
keeps updating the borders while this is_some().
This fixes both that issue with AltSnap and the issue with system move,
as well as any other situations that might allow moving a window with
anything else that doesn't use a left mouse button press.
This commit makes sure we refocus the window on `Show` event when it is
the only window on the workspace.
This is needed because some windows send the `FocusChange` event before
the `Show` event and on the first event we will be focusing the desktop
window to unfocus any previous window from other workspace because the
workspace will still be empty. So after adding the window, we need to
focus it again.
This commit allows `workspace-rules` and `initial_workspace_rules` to be
applied to floating windows. As a by product of this commit, now the
command to show `visible-windows` will now also show the maximized
windows, monocled windows and floating windows.
This commit adds a `matches_floating_applications` to the `RuleDebug`
which allows users to know if a window was matched as a floating window
when using the debug part of the GUI.
This commit adds a new SocketMessage::Theme which allows for themes to
be set programmatically. This change has also been plumbed through to
komorebi-bar so that the bar theme will also update after komorebi
processes the message and passes it on to subscribers.
A new theme_manager module has been introduced to add notification-based
handling of theme changes, both from the static config file being
updated and from SocketMessage::Theme being received.
This commit updates the build and release workflow to enable multi-arch
builds and releases.
A number of Rust-specific actions have been added, namely rust-cache to
handle cargo caching and actions-rust-cross to handle cross-compilation.
A release-dry-run target has been added to run on master which should
help catch any issues in release workflow changes early.
Releases drop goreleaser entirely in favour of action-gh-release which
was already in use to add msi installers to the releases previously
created by goreleaser.
This commit adds support for a v2 format of the application specific
configuration file, centralizing on JSON to maximize the knowledge
crossover for people already familiar with the types used in
komorebi.json.
The biggest difference besides the format change is that matchers must
be used explicitly for every kind of rule, rather than being able to
specify options on a default rule. This is a bit more verbose, but
ultimately allows for significantly more flexibility.
After some investigation by @alex-ds13 on Discord it looks like there
are times where attempting to gain a lock on the WindowManager inside of
read_commands_uds results in the thread becoming blocked when it's not
possible to obtain the lock.
Instead of waiting indefinitely for a lock, this change ensures that we
will wait for at most 1 second before discarding the message so that the
command listener loop can continue.
Warning logs have been added to inform when a message has been dropped
as a result of lock acquisition failure.
This commit adds a new SocketMessage variant,
RetileWithResizeDimensions, to preserve any resize dimensions applied by
the user.
This new variant is now used when clicking on a workspace using the
komorebi widget in komorebi-bar.
This commit adds a new method, subscribe_with_options to
komorebi-client.
The first option introduced is to tell komorebi to only send
notifications when the window manager state has been changed during the
processing of an event.
This new subscription option is now used with komorebi-bar to improve
rendering and update performance.
This commit changes the `move_container_to_monitor` from the WM to allow
moving floating windows as well.
It also adds a new method `move_to_area` to the `Window` that allows
moving a window from one monitor to another keeping its size.
This commit creates a new function for the workspaces to check if they
are empty or not.
This function properly accounts for maximized windows, monocle windows
and floating windows.
This should fix the cases where the WM was checking if the workspace was
empty to focus the desktop in order to loose focus from previously
focused window.
Previously it wasn't checking for floating windows so it cause continues
focus flickering when there were only floating windows on the workspace.
This commit introduces a new option `float_override`, which makes it so
every every window opened, shown or uncloaked will be set to floating,
but it won't be ignored. It will be added to the floating_windows of the
workspace, meaning that the user can later tile that window with
toggle-float command.
This allows the users to have all windows open as floating and then
manually tile the ones they want.
This interactively rebased commit contains changes from the following
individual commits:
0e8dc85fb1
feat(wm): add new float override option
30bdaf33d5
feat(cli): add command for new option `ToggleFloatOverride`
b7bedce1ca
feat(wm): add window_container_behaviour and float_override to workspaces
221e4ea545
feat(cli): add commands for workspace new window behaviour and float_override
b182cb5818
fix(wm): show floating apps in front of stacked windows as well
7c9cb11a9b
fix(wm): Remove unecessary duplicated code
This commit introduces a distinction between ignored applications
(previously identified with float_rules) and floating applications.
All instances of "float_" with the initial meaning of "ignored" have
been renamed with backwards compatibility aliases.
Floating applications will be managed under Workspace.floating_windows
if identified using a rule, and this allows them to now be moved across
workspaces.
A new border type has been added for floating applications, and the
colour can be configured via theme.floating_border.
This interactively rebased commit contains changes from the following
individual commits:
17ea1e6869
feat(wm): separate floating and ignored apps
8b344496e6
feat(wm): allow ws moves of floating apps
7d8e2ad814
refactor(wm): float_rules > ignore_rules w/ compat
d68346a640
fix(borders): no redraws on floating win title change
a93e937772
fix(borders): update on floating win drag
68e9365dda
fix(borders): send notif on ignored hwnd events
This commit ensures that whenever komorebi.json is read and deserialized
into StaticConfig via StaticConfig::read, all known paths where
$Env:KOMOREBI_CONFIG_HOME and $Env:USERPROFILE are accepted will be run
through the resolve_home_path helper fn.
This commit fixes the cases where you'd call this command on a monitor
which was not focused, for example by pressing a button on a bar like
komorebi-bar or other when you had focus on another monitor.
This change ensures that first we focus the monitor where the mouse cursor
is, this way it will act on the monitor that you've just pressed instead
of the monior that was focused before.
This commit adds a "bar_configurations" option to the static config file
which takes an array of PathBufs.
If this option is defined and the --bar flag is passed to the "komorebic
start" command, komorebic will attempt to launch multiple instances of
komorebi-bar.exe with the --config flag pointing to the PathBufs given.
This configuration option is only consumed by komorebic, not by the
window manager directly, so it could also be used by other status bar
projects to read configuration file locations from.
There is no requirement for the PathBufs to point specifically to
komorebi bar configuration files if the --bar flag is not being used
with "komorebic start".
This commit replaces almost all uses of the egui Viewport API for bar
window positioning with calls to SetWindowPos via komorebi_client's
Window struct.
This seems to play much more smoothly with multi-monitor setups where
each monitor has a different scaling factor, opening the door for
multiple instances of komorebi-bar.exe to run against multiple monitors.
As a result of this change, the "viewport" configuration option has been
renamed to "position" and doc strings have been changed to remove the
reference to the egui crate docs. Similarly, "viewport.position" and
"viewport.inner_size" have been renamed to "position.start" and
"position.end" respectively. Backwards-compatibility aliases have been
included for all renames.
This commit ensures that the komorebi-bar.exe process is DPI aware and
applies DPI compensation to viewport.position and viewport.inner size
both on launch and on configuration reload. viewport.position changes
are now hotloaded wihtout having to restart the process.
re #1024
This commit ensures that when switching to a workspace, if that
workspace is empty, the desktop window will be focused (and focus will
be removed from the last focused window on the previous workspace)
regardless of the value of follow_focus.
This commit ensures that other "slow" applications (besides firefox)
which require a compensation time to sleep before continuing with
eligibility checks can be configured by end users in komorebi.json.
As the compensation time will vary depending on the specs of the end
user's machine, the compensation time in ms has also been made
configurable.
This commit ensures that komorebi will compile when targeting 32-bit
architectures, namely `stable-i686-pc-windows-msvc`.
Thanks to @kennykerr for pointing out that Get/SetWindowLongPtrA/W calls
don't actually exist on 32-bit builds of Windows and are aliased instead
to Get/SetWindowLongA/W which take i32 args instead of isize args:
https://github.com/microsoft/windows-rs/issues/3304
This commit ensures that the full range of matching strategies for both
Simple and Composite matching rules will be respected for both initial
and persistent workspace rules.
The generate-static-config command will no longer attempt to populate
workspace rules, and will likely slowly be deprecated as the
overwhelming majority have users have already migrated to the static
configuration file format.
fix#991
This commit adds transparency_ignore_rules to the komorebi.json static
configuration format. Windows that match any rules given in this list
will not have transparency applied when they are unfocused.
For example, to ensure that a browser window is not made transparent
when the focused tab is a YouTube video:
```json
"transparency_ignore_rules": [
{
"kind": "Title",
"id": "YouTube",
"matching_strategy": "Contains"
}
]
```
This commit adds a --quickstart flag to the komorebi-bar binary to
output an example komorebi.bar.json into the user's desired
configuration directory.
This is to avoid the case where running komorebic quickstart would
result in clobbering an existing komorebi.json file.
Additionally, if a user tries to run the bar for the first time without
a configuration file, the example configuration will be written to disk
for them.
Finally support for loading a komorebi.bar.yaml file has been removed
because I have no desire to support multiple configuration formats over
the long term.
Not a huge fan of these updates in the windows-rs crate which swap the
isize values which were previously wrapped in various handles with *mut
core::ffi:c_void pointers.
In order to at least keep this codebase sane, all of the wrapper
functions exposed in WindowsApi now take isize wherever they previously
took HWND, HMONITOR, HINSTANCE etc.
Going forward any pub fn in WindowsApi should prefer isize over Windows
handles which wrap c_void pointers.
This commit builds on c3f135703e and
1080159e68 to add layout-specific edge
index awareness to all default layouts.
This is most useful for UltrawideVerticalStack and
RightMostVerticalStack, which have a lot of edge cases due to the
positioning of the 0th index changing with the number of containers on a
workspace.
This commit expands the komorebi layout subwidget to update the layout
indicator accordingly when the user switches to a floating workspace, or
when the window manager is paused.
This commit ensures that when focusing across a monitor boundary to the
left, the container at the back of the Ring<Container> in the target
workspace will be focused, and when focusing across a monitor boundary
to the right, the one at the front will be focused.
This commit introduces a new wrapper, CustomUi, which is used to
implement custom methods on top of eframe::egui::Ui.
The default ui::add_sized method always has the text in a label
centered, which is not desirable for a status bar where the layout
should be ltr.
A new function CustomUi::add_sized_left_to_right has been added to
ensure that labels can be truncated with a custom width (which requires
allocate_ui_with_layout), while also retaining the ability for the text
to be aligned to the left rather than the center of the allocated
layout.
This commit ensures that when moving across a monitor boundary to the
left, a container will be added to the back of the Ring<Container> of
the target workspace, and when moving across a monitor boundary to the
right, that it will be added to the front.
This commit ensures that the focused window komorebi subwidget is aware
of multi-window containers and displays an ordered list of windows in a
container stack which can be clicked to change focus in the stack.
When there are >1 windows in a stack, the title of the focused window
will take from komorebi.json's theme.stack_border if theme is defined
(falling back to the same default value in komorebi), or from
theme.accent in komorebi.bar.json, if defined.
This commit updates the various komorebic json schema generation
commands to generate the schemas locally, without requiring a running
instance of komorebi to communicate with over IPC.
This commit introduces a new SocketMessage, ReplaceConfiguration, which
attempts to replace a running instance of WindowManager with another
created from a (presumably) different komorebi.json file.
This will likely be useful for people who have multiple different
monitor setups that they connect and disconnect from throughout the day,
but definitely needs more testing.
An experimental sub-widget which calls this SocketMessage has been added
to komorebi-bar to aid with initial testing.
This commit adds instructions for komorebi-bar to the Getting Started
section of the documentation website, adds an example komorebi.bar.json
configuration file, integrates that file with the quickstart command,
and updates the start and stop commands to take --bar flags similar to
the --whkd flags.
In updating the documentation I also decided to rename in the internal
tag for the KomobarTheme and KomorebiTheme enums to "palette" instead of
the previous generic "type" tag which was copied from the serde docs.
This commit adds hot reloading for changes made to viewport.inner_size
in the configuration file. I still don't understand how the scaling
works with egui, but at least for the time being there are some rough
heuristics I've thrown together.
The transformation of y still seems a little off, but the transformation
of x seems pretty accurate when dividing by native_pixels_per_point.
This commit ensures that whenever komorebi.json is updated, komorebi-bar
will try to apply whichever theme is set in that file by the user (if
one is set).
Similarly, if a theme is not set in komorebi.bar.json, komorebi-bar will
load the theme set in komorebi.json (if one is set).
A new configuration "bar_accent" has been added to the KomorebiTheme
struct to make this process as uniform as possible.
This commit abstracts the theme-related code from komorebi-bar into a
separate library which is now also consumed by komorebi.
The static configuration file for komorebi has been updated to allow
users to specify themes and provide palette overrides for various border
styles and stackbar configuration options.
In the event that both a theme and border-specific and/or
stackbar-specific colours have been specified, the theme will take
priority to make it as easy as possible for users who have already spent
time tweaking their colours to try out themes and quickly revert back if
they prefer their existing colours.
This change makes it easier for users to have unified themes between
komorebi and the komorebi status bar.
This commit adds an initial version of the komorebi status bar.
At this point the bar is still considered "alpha" and the configuration
format may see some small breaking changes based on usage and feedback.
There is an accompanying video series which details the creation of this
bar on YouTube: https://www.youtube.com/watch?v=x2Z5-K05bHs
Some high level notes on the bar:
* An external application which exclusively consumes komorebi_client's
public API surface - anyone can create this without hacking directly
on komorebi's internals
* Generally a very simple bar with limited configuration options - users
who want more configurability should use alternatives such as yasb or
zebar
* Scope is deliberately limited to provide a tighter, more focused
experience: Windows-only, komorebi-only, single-monitor-only,
horizontal-only
* No support for custom widgets or templating
* Colours are controlled exclusively through themes which adhere to a
palette framework such as Base16 or Catppuccin (and possibly others in
the future)
This commit contains all of the commits listed:
e5fa03c33c
feat(bar): initial commit
b3990590f3
feat(bar): add config struct with basic opts
bc2f4a172e
feat(bar): handle komorebi restarts gracefully
ca6bf69ac7
feat(bar): add basic widget config opts
18358efed8
feat(bar): add interactive layout and media widgets
92bb9f680b
perf(bar): use explicit redraw and data refresh strategies
8e74e97706
feat(bar): add battery and network widgets
fdc7706d23
feat(bar): add custom font loader
025162769b
feat(bar): allow right side widget ordering
a1688691cf
feat(bar): add app icon next to focused window title
9f78739c3f
feat(bar): add komorebi widget (+config) and themes
a4ef85859e
feat(bar): use phosphor icons for uniformity
e99138a97e
feat(bar): add first pass at configuration loader
d6ccf4cf9a
feat(bar): add logging and config hotwatch
34d2431947
feat(bar): handle monocle containers in komorebi widget
7907dfeb79
feat(bar): add optional data refresh intervals to config
96a9cb320e
feat(bar): add flag to list system fonts
42b7a13693
feat(bar): add activity to network widget
ac38f52407
feat(bar): to_pretty_bytes on network activity
6803ffd741
feat(bar): configurable network activity fill char len
7d7a5d758d99808cd2b81da2b3ddbb11c52aa92f
ci(github): add bar to wix and goreleaser configs
da307e36fc1faf84ecca3f91811fdd15f70ef2ff
feat(bar): expand theme sources
c580ff7899889309dfa849ad4fb05b80b6af8d9b
feat(bar): add accent config for themes
bc4dabda4a941c0c9764fae2c8d11abbfdc0a9f5
feat(bar): add accents to widget emojis
a574837529dd6c5add73edf394c1c9c2e6cc6315
feat(bar): add to hard-coded float identifiers
ff41b552613f911e56b1790e68389525ee7e603c
chore(deps): bump base16-egui-themes
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 is a squashed combination of the following commits from #920
by @thearturca. Thanks to both @thearturca for @amnweb for their work in
fixing and thoroughly testing these changes respectively.
935079281a
fix(animation): added pending cancel count to track `is_cancelled` state
84ad947e1f
refactor(animation): remove cancel idx decreasing
804b0380f7
refactor(animation): remove `ANIMATION_TEMPORARILY_DISABLED` global vars
f25787393c
fix(animation): extend cancelling system to support multiple cancel call
dfd6e98e9c
refactor(window): reuse window rect in `animate_position` method
18522db902
fix(animations): change check for existings animation to `pending_cancel_count` field
Before it was checking `cancel_idx_counter` which is `id` counter. It
never gonna equals `0` and doesn't represent all animations that running
for that window. So it doesn't delete entry from hashmap.
That leads to bug when border and stackbar doesn't get notified after
animation ends.
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:
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.
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
In the case when the `komorebi-client` is used in one project with some
dependency that is transitively used crate `parking_lot` with feature
`send_guard`, a compilation error occurs because `komorebi-client`
transitively importing `parking_lot` with feature `deadlock_detection`
and these features are mutually exclusive.
This fix suggests enabling `deadlock_detection` feature in `parking_lot`
crate only if `deadlock_detection` enabled for `komorebi` crate, by
default it is disabled so it will solve issue with `komorebi-client`
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 addresses a regression in v0.1.26 that was introduced by the
win32-display-data crate, where virtual monitors would not be detected
in scans by the wm.
The actual fix has been made upstream in win32-display-data:
2a0f7166dafix#846
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.
This commit adds hiding and restoring of other containers on a workspace
with monocle on/off, and exits early when a monocle container is found
on workspace restores to avoid flashing of other containers before the
workspace focus operation completes.
Focus is also restored when focusing a monocle container on another
monitor as part of a cross-monitor focus operation.
The border rendering for monocle containers has also been tightened up.
re #819
This commit addresses two visual artifacts with monocle mode:
* Flashing of background windows when switching to a monocle container
on another monitor is now gone
* Stackbars are automatically disabled whenever a container enters
monocle mode
re #819
This commit fixes a number of monocle container-related regressions.
* Monocle container on one monitor preventing border updates on another
* Cross-monitor focus changes towards a monitor w/ a monocle container
* Cross-monitor move towards a monitor w/ a monocle container
re #819
This commit handles the EVENT_OBJECT_NAMECHANGE WinEvent which is
emitted when window titles change to update Stackbar labels in real-time
when StackbarLabel::Title is used.
re #826
This commit fixes a small regression that was introduced with the
addition of the Grid layout, where stacking right from index 0 on the
UltrawideVerticalStack layout would actually end up stacking to the
left.
This commit introduces a new stackbar label configuration option backed
by the StackbarLabel enum, which now has two variants, Process and
Title.
The state tracker for this option is kept in an AtomicCell, and the
state tracker for StackbarMode has also been changed from an
Arc<Mutex<T>> to an AtomicCell to match.
resolve#826
This commit adds the promote-window command, which allows the user to
promote the window in the specified OperationDirection from the
currently focused window to the largest tile on the workspace layout.
This commit adds a new cli command, cycle-move-workspace-to-monitor.
After the introduction of the monitor reconciliator module in
combination with display_index_preferences, this command should never
really be necessary, however it is worth having as a backup.
resolve#718
This commit renames a number of border-related code refs, removing the
ActiveWindow prefix since these borders are no longer just for the
active window.
Aliases have been added to preserve backwards compat for existing
configs.
An example AHK configuration file has been added to the Common Workflows
section of the docs site.
A link to the docs site has been added to the output of komorebic start.
A note has been added recommending that users disable system animations
for the best experience in the Getting Started guide.
This commit updates the initial design of single_window_work_area_offset
to window_based_work_area_offset where the user can set
window_based_work_area_offset_limit to determine the limit of windows on
the screen that this offset should apply to.
By default this is 1, and in the most extreme case of someone using a
super ultrawide monitor this might be 2.
This commit fixes a regression which led to the adjusted work area for a
monitor not being respected when applying additional window-based work
area offsets.
re #811
This commit adds a new monitor configuration option, single_window_work_area_offset, which will
apply to a monitor when only a single window is open on a workspace. This is implemented as a Rect
to enable its use on both horizontally and vertically positioned monitors. This option will be
particularly useful for ultrawide monitor users, where a single window taking up the full width of
the work area can often hinder usability.
resolve#434
This commit ensures that both windows and borders will make a comparison
to the current values returned by WindowRect before attempting to make
update calls to SetWindowPos. This should greatly reduce visual
flickering in both the borders and sensitive apps like JetBrains IDEs.
This commit adds some rough heuristics to workspace_reconciliator which
should help with having the correct window focused after reconciliation
in the majority of, but probably not all, cases.
EnumWindows generally returns HWNDs according to z order, and a window
selected by alt-tab will almost always be put on the top of the z order.
Before sending a workspace_reconciliator::Notification, we store this
HWND along with an Instant and an AtomicBool telling us that we have a
candidate to focus after the workspace switch.
This commit ensures that if and when either the border_manager or
workspace_reconciliator notification handlers crash in their respective
threads, they will be restarted instead of killing the whole thread.
This is acheived via a loop running in the spawned threads of both
listeners, which will report whichever error killed the notification
handler functions.
Clippy annotations to deny expect and unwrap calls have been added to
these two modules.
Calls to DestroyWindow for expired borders were sporadically failing in
unpredictable circumstances, so these have been switched out with calls
to CloseWindow which has been working well so far with the stackbar
feature.
This commit ensures that even border hwnds that may now be untracked as
a result of events such as monitor changes will now be reaped in the
destroy_all_borders function.
This commit ensures that if a user uses index-based commands to switch
workspaces, workspace layout update code paths will not be run if the
user is already on the desired monitor and workspace indices.
resolve#647
This commit adds a new "NoOp" MoveBehaviour for users who don't want any
moves to happen across monitor boundaries. The
toggle-cross-monitor-move-behaviour will only toggle between Swap and
Insert, and will do nothing if NoOp is the selected MoveBehaviour.
resolve#667
This commit adds the workspace_reconciliator module which uses a tightly
bounded channel (cap: 1) to update the focused workspace in situations
where the user or another process has foregrounded a window that is on a
different workspace.
This most often happens via Alt-Tab, or by clicking a link which opens
in another application.
workspace_reconciliator::Notification contains the target monitor and
workspace indices, which when received allows for the correct workspace to
be focused.
These notifications are sent in process_event.rs when handling
WindowManagerEvent::Show, Manage and Uncloak events.
All previous logic pertaining to workspace reconciliation which lived in
the handler for these events has been removed and replaced with
notifications sent to the reconciliator.
As the notifications channel is tightly capped and any notifications
which overflow the cap will never be delivered, we are able to avoid the
infinite workspace switching loops which happened when using the
previous logic, which ran on every single event.
This commit removes all border-related code from process_command,
process_event etc. and centralizes it in the new border_manager module.
Instead of trying to figure out where in process_event and
process_command we should make border-related changes, a notification
gets sent to a channel that border_manager listens to whenever an event
or command has finished processing.
The border_manager listener, upon receiving a notification, acquires a
lock on the WindowManager instance and updates borders for the focused
workspace on every monitor; this allows us to centralize all edge case
handling within the border_manager listener's loop.
Borders on workspaces that lose focus are now destroyed and recreated
when those workspaces regain focus, instead of trying to share
individual border instances across workspaces.
A number of common edge cases that have been addressed in this commit
are:
* Paused window manager
* Floating workspaces
* Maximized windows
* Fullscreen videos
* Monocle containers
* Ghost borders on workspace switching
* Incorrect focused window border colours
Global state related to borders has also been moved into the
border_manager module, which also tracks the state of border objects
(BORDER_STATE), their rects (RECT_STATE) and their focus kinds
(FOCUS_STATE).
This allows us to now track multiple borders per-container, enabling
unfocused border windows for the first time.
Additionally, the Z-Order for border windows is now also configurable.
ActiveWindowBorderColours has been expanded to include Unfocused, but in
order to not introduce a breaking configuration change for end users,
all members of this struct have been made Option<Colour>.
This commit ensures that in situations where the last container on a
monitor is moved to an adjacent monitor, the focused container index of
the origin monitor will be appropriately decremented.
When adding selective handling of Uncloak events, a regression was
introduced where, for example, when clicking a link from Discord on
Workspace 2, a Firefox instance on Workspace 1 would be moved to
Workspace 2 to open the link, but when moving back to Workspace 1, a
ghost tile would be left, and the Firefox instance would be duplicated
across two workspaces.
This commit fixes this regression and makes the handler a bit easier to
reason about while also removing unnecessary early return statements
which prevent notifcations from getting sent to subscribers.
This commit adds selective handling for WindowManagerEvent::Uncloak
alongside Show and Manage, avoiding the workspace-switching logic that
is known to cause infinite workspace loops.
This commit ensures that if a window is moved to a workspace on another
monitor which is not the currently focused workspace on that monitor,
the target workspace will be focused as part of the operation.
This commit completely removes the custom Clone and Drop trait
implementation for Stackbar, and moves the handling to be explicit
within container.rs, which helps us to avoid unintentional drops when
the Stackbar struct is cloned for Notification events sent to
subscribers such as Zebar.
re #746
This commit ensures that when we call methods to change
Container.stackbar we are not unintentionally invoking a Drop which
kills a stackbar window that already exists.
Checks have been added to make sure that we not change the value of the
stackbar variable if it is already an Option::Some.
re #746 re #792
This commit ensures that tiling on a workspace will be enabled if a user
specifies layout rules or custom layout rules without providing an
option to the "layout" key.
This commit adds a new RightMainVerticalStack layout, adapting code from
the similarly named LeftWM layout.
It turns out that the horizontal axis flip on the VerticalStack does not
play well with resize offsets.
It was ultimately easier to implement this layout and the logic for
resizing both VerticalStack and RightMainVerticalStack independently
than to make resize offsets and horizontal axis flips work together.
I still have no idea why resize offsets and horizontal axis flips aren't
working properly together.
Horizontal axis flips have been disabled for both the VerticalStack and
RightMainVerticalStack layouts.
re #789
This commit ensures that when floating the sole window visible on a
workspace that the focused container index for the workspace will not be
decremented below 0.
re #787
This commit ensures that the wm's mouse_follows_mouse state is respected when handling FocusChange
WindowManagerEvents, so that applications opened on empty workspaces do not automatically center the
cursor unless configured to do so.
fix#782
The example configuration mistakenly used the key `border_padding` in
the place of `border_width`. As `border_padding` does not exist in the
spec, modifying its value has no effect.
As this file is used by `komorebic quickstart`, new users will have this
incorrect key in their default configuration. Notably, setting its value
to `0` to remove gaps has no effect. The rest of the documentation uses
the correct key, so users copying and pasting from that would not
encounter the bug.
This commit ensures that if a container stack has a stackbar, when
toggling off monocle mode, the stackbar will be restored as expected.
This requires an additional retile which it would be nice to avoid in
the future.
This commit adds a move-to-monitor-workspace command, which, following
the existing convention, does the same action as
send-to-monitor-workspace, but sets the focused monitor, workspace and
container to the window container once it is inserted into the target
monitor and workspace indices.
This commit ensures that after 3 failures to start komorebi with
'komorebic start', 'komorebi.exe' will be run directly in order to show
the detailed error output to the end user.
This commit ensures that enforce_workspace_rules() will try to match
exact exe names, classes and titles, and then against any potential
regexes that may have been used as keys to index matching rules against
the current window's exe, title and class.
Support for other matchers isn't implemented yet. Not sure it's worth
adding while using a HashMap to store the workspace rules, probably need
to rethink the data structure first.
* re-add the #requires line that was removed in commit e044a5a
* remove the "generated by komorebic" comment which is incorrect. komorebic only generates an AHK v1 lib
* update common-workflows/autohotkey.md to remove line about `komorebi.generated.ahk file which no longer exists
This commit ensures that when the stackbar mode is updated via a
SocketMessage or static config update, any visible stackbars will have
their mode updated immediately without having to wait for user
interaction.
This commit adds support for debugging windows and emitting information
about how they go through komorebi's decision making pipeline and rules
engines which ultimately decide how they are or aren't managed.
This commit ensures that new features such as stackbar, particularly
where the configuration is located in the global state, can be
configured via SocketMessages.
A few structs had to be moved to komorebi-core to make this possible.
I've also cleaned up a bunch of strum snake_case attrs which seemed to
be unused.
A new GlobalState SocketMessage has been introduced, and going forward
we should make sure that this can send all global state to a requester,
and move global state out of the State handler, which should only handle
window manager state.
This commit ensures that a window is restored before a focus call is
made on it when switching windows in a stack by using a window's tab in
the stackbar.
This handles the issue where two clicks are required to trigger a layout
update the first time a window that is not currently at the top of the
stack is brought to the front via a stackbar click.
As we have been working down some bugs from earlier changes, we
introduced some additional error conditions in the logs. Now that the
new focus approach is available, switching the stackbar to that means we
can avoid needing to pass down ForceUpdate and FocusChange events for
non-windows, which removes many of these cases.
In addition we do a check in should_manage that the target object is
actually a window, ignoring the event if it is not.
We had been setting managed windows to HWND_TOPMOST which is a sticky
and viral parameter. This was also the cause of the border window ending
up behind other windows in an undesirable fashion, as even though it was
marked WS_EX_TOPMOST, we were then having to mark it HWND_NOTOPTMOST
when raising it to avoid it ending up drawing over other windows.
Since we've fixed the border window to no longer be visible when
unmanaged windows are focused, we can now set the border window to
HWND_TOP when we reposition, which will ensure it's drawing in the order
that we want.
Now we also set managed windows only to HWND_TOP, rather than
HWND_TOPMOST which stops us from incorrectly reordering internal
concerns vs. child windows and owned windows that we're not managing.
Windows are still brought to the foreground as expected/desired, but
they're no longer 'sticking' there, nor are they drawing over the border
window.
This change does have a slight transition behavior as it initially rolls
out, as prior versions of the Komorebi have been setting HWND_TOPMOST,
which as a sticky parameter won't be cleared until the application or
host system removes that flag. This means that the final z-order
behavior will come good eventually.
To immediately see the correct results, restarting affected apps or
logging out / in will do. Unfortuantely we can't just set
HWND_NOTTOPMOST, as similarly to setting HWND_TOPMOST, this can cause
issues with an applications intended owned-window Z-Ordering - mostly
affecting toolwindows and child windows, such as file dialogs, toolbars
and so on, most of which we do not manage.
Use the same method as FancyZones to enable setting the foreground
window. This makes it possible then to remove the thread attachment
behaviors that have a number of other complex side effects, and aren't
always allowed.
In addition, cleanup old focus/raise methods some, in particular the
border window is now explicitly not activated when it is raised, as it
should never be activated.
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
This commit ensures that workspace change events get emitted even when
changing to workspaces with no window containers. Previously these were
failing due to early returns triggered when the workspace focused did
not have a focused container.
This commit fixes a regression that was most likely introduced in #678
which changed a bunch of stuff related to window and border dimension
calculation.
See commit 4e98d7d36d for more information
as the same approach to fix the behaviour there has been applied here.
This commit switches out the serde_json crate with the
serde_json_lenient crate, forked by Google, which allows for JSON files
with comments to be parsed properly.
Users can set the format of komorebi.json to "jsonc" in their editors in
order to write // comments without being faced with lint errors.
The expected file extension remains the same (json). komorebi and
komorebic will not look for files with the "jsonc" file extension or any
other JSON-variant file extension.
resolve#693
This commit fixes a regression that was most likely introduced in #678
which changed a bunch of stuff related to window and border dimension
calculation.
While we could previously assume that the points resize.right and
resize.bottom would always be 0 if we were dealing with a move rather
than a resize, these two points now depend on the values of BORDER_WIDTH
and BORDER_OFFSET. The code has been updated to reflect this and
calculate this constant just-in-time.
This commit introduces the komorebi-client library crate for other Rust
applications to interact with a running instance of komorebi over Unix
Domain Sockets.
Currently the crate re-exports everything one might find in the
komorebi::State struct and everything that is publicly exposed in
komorebi-core.
Public types and methods are still lacking documentation, and this crate
should not be published on crates.io until this is no longer the case.
This commit adds some contribution guidelines and updates the "Window
Manager Event Subscriptions" section with information on using
subscribe-socket and komorebi-client.
This commit includes backwards-compatible renames of
active_window_border_offset and active_window_border_width to
border_offset and border_width respectively.
Since the invisible window border adjustments were removed in #678, the
invisible window borders set by the OS can now also be adjusted via
border_offset and border_width, which is the primary reason for the
rename.
invisible_borders has been marked as deprecated and the previously
deprecated alt_focus_hack option has been removed.
This trades one issue for another, in order of importance:
- Pop-up windows such as a file upload dialog box for Firefox no longer
have a window border drawn over the top - better.
- Opaquely bordered windows without DWM decorations, combined with a -1
offset / single pixel border end up as invisible borders (e.g. EPIC
Games Launcher).
The default window corner rounding is still slightly visible at offset
-1 until this corner radius that completely closes up the transparent
region, without needing to invasively draw over the target window.
topmost has a special meaning, in that it is a sticky raise, which is
not what we want - we don't want to be permanently above all other
windows, as this leads to bugs where for example the windows can end up
stuck above non-topmost windows in a different security context, such as
programs running with administrator priviliges.
In the new border painting strategy, the 20 pixel border is huge. The
border is now offset -1 by default, so as to draw over the standard DWM
1px border (avoiding a "1 pixel see through gap"), and the default width
is 8px.
The SetWindowPos API will inset the provided dimensions by the amount of
space required for window decorations (shadows, etc). Compute the size
of the decorations and add them as padding to the provided size,
resulting in windows being set precisely to the target dimensions.
An active_window_border_width=1, active_window_border_offset=-1 will now
paint over the 1px window decoration consistently.
The border window is always made topmost on resize, so that it paints
over custom borders (e.g. EPIC Games Launcher) as those borders are
opaque and as such a 1px border configuration as above becomes invisible
in that condition.
The layout should leave the space configured for the border, so that the
border always stays within the workspace bounds.
Border offset is cleaned up, as it is no longer a rect, but instead just
a fixed value.
The rect function for adjusting padding now takes a concrete value, as
the optional has no local meaning to the operation, being equivalent to
the default value.
A margin function is added to centralize the notion of increasing the
size of a rect by the given margin, the opposite of the padding
operation.
This fixes a regression from an earlier commit that dropped the DWM
style borders without fixing corner rounding on Windows 11. This is now
fixed for Windows 11 again, while avoiding the extra system border
decorations.
This makes the borders pixel-perfect, and border_overflow can be
disabled on all applications.
Unfortunately this also means we lose the corner rounding, so that may
need to be done differently or the offsets refined in some way to
address that.
Switch to using the DWM API to get Window bounds so as to exclude the
outside of window decorations from the computation.
This is getting close to a precise window size, you can now set an
active border width of 1 and an offset of 1 and get a 1 pixel line
around most windows, except that there's some extra top padding I have
yet to find the cause of.
This implementation needs to be DPI aware, but I haven't yet tested if
the DPI scaling approach is entirely valid - we may instead need to get
the per-monitor DPI scale, identify the monitor the window is on, and
scale to that, rather than using the system wide scale.
Maybe fixes#574
Maybe updates #622
This commit adds the "komorebic whkdrc" command to go along with the
"komorebic configuration" command introduced in
608ec03047, aimed it making it easier to
edit this file using a command line editor.
The "config" command has been renamed in the code to Configuration, with
an alias of "config". The Whkdrc command similarly comes with the "whkd"
alias.
This commit introduces the ability for users to specify colours in the
static config file in either RGB or Hex format.
This is done by introducing a new enum, Colour, which provides variants
wrapping the internal Rgb type, and the HexColour type from the
hex_colour crate. HexColour itself is wrapped in a new struct, Hex, in
order to allow the implementation of the JsonSchema trait.
A number of From<T> implementations have been done in order to make
working with the Colour enum more ergonomic.
Ultimately, the core representation for colours in komorebi remains the
Rgb struct, any and Hex-specified colours will be converted to this Rgb
type before being converted to u32 to pass them on to various Win32 API
calls.
This commit adds the "komorebic config" command as a helper to print the
path to komorebi.json, while respecting the KOMOREBI_CONFIG_HOME
environment variable if it exists.
This is particularly useful for users who wish to edit this file on the
command line, as they can now run commands like:
"lvim $(komorebic config)"
This commit addresses and number of bugs and improves the experience of
working with floating workspaces (ie. Workspace.tile = false).
- When the user moves or resizes a window on a floating workspace,
WindowManagerEvent::MoveResizeStart will no longer trigger, which
prevents the mouse focus from going to the middle of the window rect
after the resize or move action (if mouse_follows_focus = true)
- If active_window_border = true, it will no longer be shown on focused
windows in floating workspaces
- When windows are moved using a komorebic command from a floating
workspace to a tiling workspace and active_window_border = true, the
active window border will be shown again
This commit remove the socket connection retry loop in send_message
which is no longer required after @raggi's changes in
c8f6502b02.
@azinsharaf noticed that when trying to run komorebic commands while
komorebi was not accepting connections, multiple hanging komorebic
instances could be spawned, particularly if commands were retried.
@eythaann proposed an additive fix for this in PR684 but ultimately as
the previous race condition with the query/response commands has been
handed by @raggi we can remove the socket connection retry loop
completely.
This commit addresses a few bugs with regards to maximized window
handling.
- Correctly restoring and focusing when switching to a workspace
containing a window previously maximized with the toggle-maximize
command
- Unmaximizing a window during the initial window scan when the wm
initializes so that windows that are maximized before running komorebi
will no longer have the ugly white bar at the top
- When updating workspace layouts, windows that have been maximized
without using the komorebic toggle-maximize command will be
unmaximized to prevent the wm state drifting out of sync with what is
happening on the screen
This commit ensures that the focus changes to the appropriate window
when a container stack is being cycled through by a user who has
disabled the mouse_follows_focus feature.
fix#680
- Use a single thread to bind the hook, and then start dispatching.
- Use a blocking loop for message dispatching.
- Remove the locks around crossbeam channel, as it's already Send + Sync
This commit splits the komorebi crate into a mixed binary and library
crate.
All types and logic related to window management have been moved under
lib.rs, and are imported from there for use in main.rs, which is now
only responsible for starting and running the window manager process.
In preparation for exposing a new komorebi-client crate in the future,
serde::Deserialize has been derived on Notification and any struct that
may appear in a notification receievd by a process that has subscribed
to event updates.
re #659
This commit adds support for subscriptions via Unix Domain Sockets which
are better suited for IPC between Rust processes compared to Named Pipes
which have issues that I don't want to spend time resolving.
The main motivation for this change is to provide an easy way for the
new zebar project to consume information about komorebi's state in the
Rust backend so that a bar module can be created for komorebi users.
The next step in this process will be to finally refactor the komorebi
crate into a mixed bin/lib crate, and expose all notification-related
structs and maybe some connection helper methods in a new
komorebi-client crate.
The previous "subscribe" and "unsubscribe" komorebic commands have had
the "-pipe" suffix added to them, with aliases in place for the previous
names in order to ensure backwards compat.
Replace the client socket with replies sent on the other side of the
querying stream, for both UDS and TCP clients. This has two results:
unix socket clients such as komorebic no longer race on the socket bind,
fixing the out of order bind error, and the response mixup conditions
that could occur. Queries over TCP now receive replies over TCP, rather
than replies being sent to a future or in-flight command line client.
This commit ensures that the $Env:LOCALAPPDATA/komorebi dir is created
by the quickstart command, as it cannot be assumed that this will always
exist, especially on new machines with recent versions of Windows 11.
fix#671
This commit is a fix that handles a subtle breaking change in
sysinfo::Process:root() which no longer can be used to see if a process
is a scoop shim.
Instead we can stringify the executable path and see if the absolute exe
path contains the substring "shims".
With this fix duplicate process detection is once again working
correctly.
This commit ensures that the KOMOREBI_CONFIG_HOME environment variable is recognized by the
komorebic check command and the static config loader when used to specify the location of the
applications.yaml file.
resolve#660
This commit uses a more reliable Win32 API call to determine the scaling
factor / DPI of user monitors, so that the scale of a window can be
correctly adjusted when moved between monitors with different DPI
settings.
fix#622
This commit adds a new komorebic command, "visible-windows", to make
tracking down ghost windows easier. The returned JSON structure will try
to use the device id to identify a monitor if it is available, or fall
back to the monitor index. Thanks to raggi on Discord for suggesting
this command!
This commit builds on @EBNull's comment shedding light on the uses of
the -A and -W functions in the Win32 API, and standardizes the calling
of the -W functions across the project.
Since UTF-16 String handling is a bit lacking in the Rust standard
library, I have pulled in the widestring crate to use the
from_slice_truncate fn to automagically remove all of the trailing null
chars when handling values returned from the various Win32 -W fns.
Comment ref: 657ac441ae (r135643553)
This commit handles an edge case where the first registered display
monitor has an index preference that is greater than the current length
of the Ring data structure storing the monitors.
re #612
Thanks to @ids1024 for pointing out that the failing system calls were
likely due to optimizations being made with the release profile's
opt-level=3 and to @saethlin for pointing out that in the previous
commit I was returning a pointer to a temporary that was about to be
deallocated.
https://fosstodon.org/@ids1024/111627094548141620https://hachyderm.io/@saethlin/111627135615930244
With this commit, the display ids are now successfully returned from
calls to EnumDisplayDevicesA on release builds.
This commit begins to build on some of the knowledge shared by EBNull in
allowing users to specify monitor index preferences using physical
device identifiers. This does not presently go all the way to EDIDs, but
the display model and what I believe is a port identifier on the display
adapter(s) can be used to uniquely identify a display in most use cases.
However, I believe I may have unfortunately run into a bug in either
windows-rs or Rust itself, as when the code calling EnumDisplayDevices
is called, it always fails when running a release build, and always
succeeds when running a debug build. This needs to be investigated
further.
re #612
This commit attempts to introduce miette to provide users with quick
feedback when there may be syntax errors such as trailing commas in
their komorebi.json configuration file.
The lines and columns reported by serde_json don't actually line up with
the visualization of where we want to indicate a syntax error on the
miette Report. Some hackery has been done, but this should be improved
upon. Notably, this hackery does not accurately reflect the location of
a syntax error when the syntax error is a missing comma after a string
value.
* feat(cli): autostart without a console window
This moves `komorebic` logic into a `lib.rs` file and calls it from `main.rs` (normal behavior) and then there is a second binary `komorebic-no-console` binary that uses `#![windows_subsystem = "windows"]` which tells the linker to not attach a console window to this binary.
* Revert "feat(cli): autostart without a console window"
This reverts commit 08494b46dd.
* feat(cli): autostart without a console window
This creates a second binary `komorebic-no-console` binary that uses `#![windows_subsystem = "windows"]` which tells the linker to not attach a console window to this binary and its only job is to run and pass its args to `komorebic`.
* add behind `--no-console` flag
* reference the new binary in wix
* remove no-console
* fix typo
This commit adds a command to output a JSON Schema for the
applications.yaml file maintained in the
komorebi-application-specific-configuration repo, and also adds an
up-to-date version of the JSON Schema as a file in the root of this
repository so that users can reference it as an autocompletion source.
This commit makes the --config flag on komorebi.exe optional, and
updates the configuration loading logic to try to find a komorebi.json
file in the HOME_DIR, which is either $Env:KOMOREBI_CONFIG_HOME or
$Env:PROFILE.
This unlocks the way for Amr's PR to make the --config flag optional on
the enable-autostart command.
re #596
After another round of deep diving to find a workaround to all of the
mechanisms within Windows that prevent a process from changing the
focused window, I came across this gist which I saw setting
SPI_SETFOREGROUNDLOCKTIMEOUT to 0:
https://gist.github.com/EBNull/1419093
This tentatively seems like it works and it removes the need for the
alt_focus_hack setting.
However, according to this StackOverflow discussion, it seems like on
Win10+ changes to ForegroundLockTimeout in the registry are no longer
respected and changes made via SPI_SETFOREGROUNDLOCKTIMEOUT are not
persisted:
https://stackoverflow.com/questions/73735129/setforegroundwindow-relationship-between-the-foregroundlocktimeout-registry-val
Therefore on starting, komorebi will now check the value with
SPI_GETFOREGROUNDLOCKTIMEOUT and if it is not 0, it will be set to 0.
Logging has been added to inform the user of the changes that are
happening.
This commit ensures that the required calls are made to the system to
enable and disable the Windows focus-follows-mouse implementation when
users make changes to the focus_follows_mouse option in the static
config file.
fix#603
- Avoids unnecessary string allocation when tracing paths
- Replaces `mut path & path.push()` with `path.join()`
- Avoids unncessary cloning of paths where applicable
- Use `dunce` crate to remove `UNC` prefix
- Improve performance of resolving `~` by avoiding unnecessary string allocations
- Resolve `~`, `$Env:USERPROFILE` and `$HOME` consistenly between different code paths
- Use `PathBuf` instead of `String` for paths in CLI args
I may have missed a couple of places but I think I covered 90% of path handling in the codebase
The user dumbhighrank mentioned on Discord that it was not possible to
call enable-autostart with the --ffm flag, as one might expect to be
able to do, given that it is accepted by the start command. This commit
introduces the --ffm flag for the enable-autostart command.
This commit adds a new komorebic quickstart command to handle the
downloading of example configuration files, which is currently done
manually by the user if they are following the quickstart guide on the
README.
re #585
This commit adds a last-second override the string output of the
derive-ahk proc macro for the stop command, which unfortunately ends up
in a broken state in komorebic.lib.ahk with the addition of a 'whkd'
flag in v0.1.19.
fix#578
This commit ensures that when a layout or a custom layout is not defined
for a workspace in the static configuration file, Workspace.tile will be
set to false. Thanks to M. Kichel on Discord for pointing out the need
for this!
This commit fixes a regression introduced in the regex rule matching
refactor.
Invisible borders should be removed from applications that are not
identified as border overflow applications, not vice versa.
This is because applications that are overflowing their borders
effectively erase the invisible borders, while applications that are not
overflowing their borders leave the system's invisible borders
visibility intact.
It is this latter group that we should be targeting with the
should_remove_border variable.
* Command to ToggleLayout
* Just improve logic of figuring out next layout
* Addr review: rename to "Cycle" instead of toggle, and add a small comment
* As per review comments, implement cycle method on DefaultLayout
* I forgot to remove this, my bad
* feat(cli): fixups for cycle-layout cmd
* Update komorebic/src/main.rs
Co-authored-by: Kushashwa Ravi Shrimali <kushashwaravishrimali@gmail.com>
---------
Co-authored-by: LGUG2Z <jadeiqbal@fastmail.com>
Co-authored-by: جاد <LGUG2Z@users.noreply.github.com>
This commit introduce two new commands, enable-autostart and
disable-autostart, to help create shortcuts for users in shell:startup
to automatically start komorebi after logging in.
* Allow different resize constraints for layouts
Change Workspace::enforce_resize_constraints to enforce constraints differently for different layouts
Add enforce_no_resize method for all but bsp layout resize_dimensions
* Add resize constraints for UltrawideVerticalStack layout
Add Workspace::enforce_resize_for_ultrawide method to apply resize
constraints for ultrawide vertical stack layout.
* feat(wm): Use resize_dimensions in calculate for ultrawide layout
Add function calculate_ultrawide_adjustment to calculate adjustments for
individual containers in ultrawide vertical stack layout
Refactor ultrawide layout generation in separate function and use
calculated adjustments
* feat(wm): Enable ultrawide layout in DefaultLayout::resize
* feat(wm): refactor ultrawide resize calculation
Add some helper function and descriptive variable names in calculate_ultrawide_adjustment
Apply clippy lints
This commit ensures that matching strategies can be used wherever
IdWithIdentifier is used, and that they are respected for users opting
to use the static configuration file format.
Some thought and planning needs to go into how this can be backported to
dynamic configurations via the CLI without breaking existing user
configurations.
re #60
This commit is the first in a series of commits which will pave the way
for regex rule matching support in komorebi.
For now, in order to maintain backwards compat and not break anything,
all rules without a matching strategy will get assigned as using the
"Legacy" strategy.
This and the "Equals" strategy are the only two which have been
implemented so far.
There should not be any breaking changes in this commit, not any
functionality lost for users with pre-existing configurations.
re #60
This commit aligns the border option naming and arguments between the
dynamic and static configuration approaches.
The previously named border_width and border_offset options in the
static config will be replaced by active_window_border_width and
active_window_border_offset in v0.1.19.
Similarly the option for the offset will now take a single signed
integer, as it does when using the komorebic command.
re #526
This commit remedies a regression noticed by user @notkvwu in #493,
which results in 'komorebic start' failing, due to an empty ArgumentList
being passed to the PS Start-Process command.
This has been fixed by ensuring that the ArgumentList is only passed
when the user has specified flags on the start command.
fix#493
This commit introduces a new --ahk flag to the start command, which
works similarly to the --whkd, and attempts to load an ahk key binding
configuration script on startup.
The attempt is made from within the komorebic process, rather than the
komorebi process.
resolve#529
This commit adds a '--whkd' flag to the 'komorebic stop' command, which
will also stop any running instance of whkd when stopping the window
manager.
This flag defaults to false, and should not change the existing
behaviour that users are used to.
This commit adds an "monitor_index_preferences" key to the static config
schema, which was missed during the initial rollout of the static
configuration files. To help with testing, these indexes have also been
exposed on the State struct.
resolve#522
This commit is an implementation of a static JSON configuration loader.
An example komorebi.json configuration file has been added.
The application-specific configurations can be loaded directly from a
file, and workspace configuration can be defined declaratively in the
JSON. Individual rules etc. can also be added directly in the static
configuration as one-offs.
A JSONSchema can be generated using komorebic's static-config-schema
command. This should be added to something like SchemaStore later.
Loading from static configuration is significantly faster on startup, as
the lock does not have to be reacquired for every command that is sent
over the socket.
When loading configuration from a static JSON file, a hotwatch instance
will automatically be created to listen to file changes and apply any
updates to both the global and window manager configuration state.
A new --whkd flag has been added to the komorebic start command to
optionally start whkd in a background process.
A new komorebic command 'generate-static-config' has been added to help
existing users migrate to a static JSON config file. Currently, custom
layout file path information can not be automatically populated in the
output of this command and must be added manually by the user if
required.
A new komorebic command 'fetch-asc' has been added to help users update
to the latest version of the application-specific configurations
in-place.
resolve#427
This commit applies a technique shared by Lars from GlazeWM and first
noticed by J.SH on Discord to add the SWP_NOSENDCHANGING flag when
positioning windows to overcome any hard-coded minimum width
restrictions an application might have.
Thanks to @thesobercoder and @olivoil for opening my eyes on this one.
This commit reduces the number of containers required before a custom
layout can be triggered. Please see the closed issue for more discussion
and rationale behind this change.
fix#390
This commit adds a new command, focus-workspaces, to allow the user to
change workspaces across all monitors at the same time. I'm not
convinced of the stability of this command and I would strongly
discourage using komorebi in this manner.
resolve#426
This commit reintroduces some old code from the feature/remove-titlebars
branch. This feature is very unstable and it is strongly advised that
nobody actually uses it. Wherever possible, please use the "remove
titlebar" functionality provided directly within an application.
This commit updates the config generator used by the ahk-asc command to
emit AHKv2 syntax.
An AHKv2 syntax-compatible komorebic.lib.ahk has been (re)introduced to
the repo root as a file to be distributed. This file is created by
taking the AHKv1 syntax output of ahk-library and automatically
converting it to AHKv2 using the automatic script converter by @mmikeww
available on GitHub.
Given that ahk-library is still being used to emit AHKv1 syntax in this
pipeline, it will remain in the repo.
The justfile has been updated to automate as much of this as possible
(the converter still needs to be run manually).
re #324
The whkd process does not start with an s - unless something is wrong or buggy on my computer, it is just "whkd.exe" and so it should be that in this file as well.
A number of people have been tripped up by not having the latest version
of PowerShell installed, which is referenced by the binary "pwsh", so
this commit sets the default .shell in whkdrc.sample to "powershell"
which _should_ come installed with every version of Windows since
Windows 10.
resolve#365
This commit adds a command to generate application-specific
configuration in the format of a PowerShell ps1 file, as well as the
ability to automatically launch a komorebi.ps1 configuration file on
startup.
If a komorebi.ps1 file is found and launched at startup, the
watch-configuration command will watch and hot reload this file when any
changes are made.
A sample komorebi.ps1 file has been added to the root of the repository,
along with a sample whkdrc file, showing how the two can be used
together to replace AHK.
re #339
This commit introduces three new commands, ensure-named-workspaces,
named-workspace-rule, and focus-named-workspace, which email to reduce
the configuration complexity by allowing users to refer to workspace
names instead of monitor and workspace indices.
This commit adds cloaking as a window-hiding-behaviour option.
https://devblogs.microsoft.com/oldnewthing/20200302-00/?p=103507 for
more information on cloaking.
Cloaking is the same mechanism used by the native Virtual Desktops
feature by the Windows team, however it is deliberately hidden from the
public Windows API.
GitHub user Ciantic's VirtualDesktopAccessor crate documents the private
IApplicationView COM interface which contains the hidden and
undocumented SetCloak method, which can be used to cloak and uncloak
application windows by their HWNDs.
With some help from Ciantic and manual exploration to determine the
correct flags values to use, komorebi is now able to use the cloaking
mechanism when switching workspaces, which results in significantly
higher reliability and significantly less jank on workspace transitions.
komorebi's use of this cloaking mechanism also retains the flexibility
of per-monitor workspaces that users have come to know and enjoy.
This has only been tested on Windows 11, it is not yet known if calling
the SetCloak function in IApplicationWindow will cause crashes on
Windows 10.
This commit ensures that when the focus is changed to a monitor with an
empty workspace with the focus-monitor or cycle-monitor commands,
subsequent commands such as focus-workspace will operate successfully on
the chosen monitor.
fix#148
This commit adds an optional focusing hack using simulated ALT key
presses to ensure that focus changes always succeed. As noted in the
documentation for LockSetForegroundWindow, the system automatically
enables calls to SetForegroundWindow if the user presses the ALT key.
This commit ensures that the bounds of the resize_dimensions member on a
workspace are checked before attempting removal when maximizing a window
using the toggle-maximize command or cycle-focus commands.
fix#331
This commit ensures that the force-focus command reads the window
manager state to get the coordinates of the window that should be
currently focused, places the cursor in the middle of that rect, and
then simulates a left-click.
This commit introduces a new command, active-window-border-offset, which
allows the user to offset the starting position of the active window
border, thereby allowing for thicker or thinner active window borders,
when used in conjunction with the active-window-border-width command.
resolve#232
On rare occasions and usually with Firefox, the desired application will
fail to be focused with the regular focus commands. This commit
introduces a new command, force-focus, which can be used to simulate a
left-click on a window that has failed to take focus, since this is what
I have to do to work around the issue anyway.
This commit introduces a new command which lets the user set a custom
width value for the active window border when it is enabled.
Unfortunately a little more width is required when working with rounded
windows on Windows 11 to fill the gap left by the rounding. The default
width remains set at 20.
re #232
This commit introduces two new commands which will allow the user to
move or send the currently focused window to either the next or previous
workspace depending on the cycle direction.
re #297
This commit removes the focused window monocle/maximized check when
trying to focus a container in a direction that requires the focus to
cross a monitor boundary.
Unfortunately, trying to remove the same check from the move command
results in undesired behaviour (the wrong window gets moved, the state
gets funny on both the origin and the destination monitor)
This commit introduces a lazy monitor cache that only gets populated
with a monitor has been disconnected, before the monitor is removed from
the state. If and when the same monitor is reconnected and identified by
its size on the virtual screen, the cached monitor state will be used to
repopulate layout options, avoiding a potentially expensive full
configuration reload.
re #275
This commit adds a new komorebic command, monitor-index-preference,
which allows the user to set the index preference within the VecDeque of
monitors based on the "size" of a display.
This works as the size Rect identifies a unique display on the greater
virtual screen and persists across display connections and
disconnections unless the user deliberately changes the positioning of
the display monitor on the virtual screen.
When a new monitor is added to the state, the monitor preferences will
be checked, and if a preference exists, the new monitor will be inserted
at that index, otherwise, it will be pushed to the back of the VecDeque.
resolve#275
This commit replaces all usages of MONITORINFO with MONITORINFOEX in
order to retrieve a name for each connected display device.
This display device name makes for easier deduping during monitor
reconciliation, so that matching display monitor names can simply have
their hmonitor id updated instead of trying to figure out which id
corresponds to which monitor by looking at the windows currently visible
on each.
fix#267
This commit adds listeners on two more events, WM_SETTINGCHANGE and
WM_DEVICECHANGE, in the hope of more reliably catching monitor
attachments and detachments based on info in an SO answer.
fix#267
This commit removes the previous polling strategy on ObjectCreate events
and uses a hidden window to listen to WM_DISPLAYCHANGE.
Unfortunately, as all monitors change HMONITOR values on monitor
attach/detach, even if the monitor remains attached, the only real
choice we have when a monitor which previously held windows is detached
is to read the entire monitor and workspace state again, as we do when
we initialise the window manager for the first time.
Since it's possible that the "wrong" monitor in the state has its
HMONITOR value updated, we also have to load the configuration again.
This commit deprecates WindowManagerEvent::MonitorPoll.
fix#267
This commit ensures that the generated AHK library for komorebic uses
RunWait instead of Run, as the latter is asynchronous and can result in
an unexpected order of calls when used in a komorebi.ahk configuration
file.
re #269
This commit adds SocketMessage::FocusWindow as a target to update the
border position on at the end of the command handler. There are some
occasions where the EVENT_SYSTEM_FOREGROUND notification isn't being
sent (on newer versions of Win11, I think), so we can't count on the
border being updated when that event is received by the event handler.
The sample config only provided three of the four required arguments in
the example call to ActiveWindowBorderColour. Uncommenting the line as
it was would raise an error from AuthoHotKey.
this commit makes a small refactor to the way PostMessageW is used so now be able to handle the
returned bool, as well as adding a custom error message to WindowsApi::close_window and updating the
ahk generated library
#259
For the past few weeks since upgrading the windows-rs crate I've seen
sporadic failures when calling SetForegroundWindow which require a full
restart to get the wm working as expected again. Adding in a retry loop
here seems to help when the issue comes up for me on Windows 11.
This commit ensures that a response socket is opened before sending a
query request from komorebic to komorebi. Additionally, I have taken
this opportunity to ensure that all socket files are created in
DATA_DIR.
fix#218
This commit ensures that monocle containers are given priority when
handling WindowManagerEvent::FocusChange.
This is especially important when switching workspaces to ensure that
the keyboard input focus stays with the monocle container's focused
window when returning to a workspace with a monocle container activated.
fix#219
This commit ensures that when navigating away from and then back to a
workspace with a monocle window container, that the monocle window
container will be properly focused when navigating back, including
having the focus of the active window border.
fix#219
This commit ensures that the active window border has non-zero HWND
before attempting to either hide it or set the border position. This is
required as the border is only initialized when a komorebic command is
received, meaning that the default value of 0 will never change if a
user decides to use komorebi without the active window border.
Most notably this commit fixes an issue where users who did not have the
active window border enabled would not be able to move away from an
empty workspace using a komorebic command.
fix#217
This commit ensures that any calls to AttachThreadInput which are used
to allow the focusing or raising of a window are paired with a closing
call to detach the thread input.
Although undocumented, it seems that when attaching the input thread of
a window to an admin/sudo process, this prevents that window from
handling inputs from any unelevated processes (including regular
keyboard and mouse inputs), until the input thread is detached.
fix#86
This commit removes mstsc.exe from WSL2_UI_PROCESSES. Recent changes to
WSLg unfortunately mean that even with this exe being included in the
override list, WSLg windows once again no longer tile correctly. On top
of that, mstsc.exe is also used for traditional Windows RDP connections,
so leaving this in the override list results in ghost window tiles for
users connecting to other machines via RDP.
Users who wish to keep mstsc.exe included in WSL2_UI_PROCESSES are
welcome to maintain a fork of komorebi.
My official recommendation for users wishing to run Linux GUI
applications from WSL on Windows is to use VcXsrv, which is fully
compatible with komorebi, and generall just a very mature, stable, tried
and tested piece of software.
fix#216
This commit ensures that when there is only one container on the target
workspace in a cross-monitor move, meaning that there won't be one
swapped back, we only decrement the focused container index on the
origin workspace if there is a focused container at an index greater
than 0.
fix#209
This commit adds a TCP listener that can be optionally exposed on a port
provided by the user using the --tcp-port flag. If the flag is not
provided, the TCP listener will not be started.
Client state is tracked using the connecting address, and clients are
purged if they send unrecognised messages.
A JSON Schema of the SocketMessage enum can be exported via komorebic
and be used to generate type definitions in various programming
languages.
This commit also makes some improvements to the handling of 'komorebic
start'.
The previous backoff approach was not working as once the Windows API
denies access to the process for any call, no amount of retries with the
same process id will result in approval.
Therefore, 'komorebic start' now checks if the process has been started,
and if it hasn't (ie. it has errored out because of an access denied
error), it will continue to restart the process until all the komorebi
startup calls to the Windows API succeed.
resolve#176
This commit wraps calls to the Windows API which may intermittently fail
in backoff blocks, reducing the potential of early exits from errors
returned by the Windows API before the tiling has even started.
Hopefully this makes calls to 'komorebic start' more relible for use at
login time.
This commit reduces some of the jank when the active border window deals
with windows that have been floated by the wm.
- The border on a floated window is always on top of all other windows,
just like the floated window itself
- When a floated window is moved by the mouse, it retains its border
- When a floated window loses and then regains focus via mouse
interactions, it regains its border
Note that now border changes are handled afer the main match block in
process_event.rs, early returns should be avoided unless absolutely
necessary, as this will prevent the border state from being updated
until the next event is received.
This commit moves the border window drawing logic into the WNDPROC
callback and uses BeginPaint -> Rectangle -> Endpaint to draw a
rectangle around the outside of the window in a specific colour that is
not black, which is used as the transparency colour with
SetLayeredWindowAttributes.
All of this results in a non-filled border rect and a much nicer
experience for users who are using transparency or translucent effects
on their windows.
This commit also introduces an optional second active border colour when
the user is focused on a stack of windows. If this is not set, the
default colour for single windows will be used.
Finally, a bunch of small issues relating to the border window staying
drawn on the screen even when there are no active windows on a workspace
have been addressed.
resolve#201
This commit introduces a new komorebi.sample.ahk in the repository root,
as well as adding the latest generated versions of komorebic.lib.ahk and
komorebi.generated.ahk.
Pushing new users to use the AHK library by default will significantly
simplify the process of building a new configuration, and including the
application-specific configuration generated from the configuration
repository will result in a better first impression of komorebi where
more and more applications "just work".
This new sample is focused on setting a few sane configuration defaults,
and as few keybinds as possible, really just enough to allow the user to
switch focus and move windows around. This significantly reduces the
possibility of the first-time user accidentally triggering a command
that leaves them confused, frustrated and would probably end in them
killing the komorebi.exe proc from the task manager.
The new sample configuration will no longer be bundled with scoop
starting from the next release, which is also expected to introduce
support for installation via winget.
Instead, instructions have been added for users to download the latest
example configuration and generated libs from GitHub in the getting
started section.
resolve#62
These changes to the GitHub actions workflows will include an MSI
installer in the artifacts that are uploaded at the end of each
successful build, and also attach an MSI installer to a release when the
job runs on a tag that creates a new release version.
re #152
This commit enforces a check to ensure that the active-window-border
configuration is enabled before trying to redraw a border than has been
hidden by a drag or move event.
This commit ensures that active window border updates in the event
processing loop are skipped if the current workspace has tiling
disabled. Previously this check was not enforced so the border would
reappear on a workspace that had disabled tiling after new events had
been processed.
This commit ensures that when the workspace-tiling command is called to
disable tiling for a workspace, that the border is also disabled for the
duration that tiling is diabled. This was previously only implemented
for the toggle-tiling command.
This commit introduces a few changes to reduce border jank, especially
when switching workspaces:
- The border is hidden before the windows start to reorganize when a
workspace switching command is received instead of after
- Avoid unncessary window.focus() call when switching workspace
- Use WindowManager.focused_window() instead of the window received from
the WindowManagerEvent when updating or setting the active border
position as it more accurately matches user expectations when
switching back to a workspace to find the focused window being the one
that you left when you switched away
This commit ensures that failures to focus on the Settings and similar
windows on Windows 11 will allow execution to continue so that the
active window border location can be updated without exiting early from
the command handler with a propagated error.
This commit ensures that when a custom layout is loaded, either manually
or via a workspace layout rule trigger threshold being amtched, any
layout_flip property for the impacted workspace will be removed, to
allow for key bindings to work as expected on the custom layout.
This commit adds an optional active window border with a user-defined
colour. This is achieved by spawning a dedicated "border window" and
constantly placing it behind the focused window, or hiding it whenever
necessary.
Some constraints to note:
- The border will only be applied to windows managed by komorebi
- This means that if you temporarily float a window, it will lose the
active window border
- There are some issues where parts of the border will be broken by
applications like Zoom, even if Zoom is behind the currently focused
window
- You probably want to turn off window shadows globally in Advanced
System Settings -> Performance for the borders to have a consistent
colour all the way around the window
- There is some inevitable jank due to trying to reposition both the
focused window and the "border window" behind it simultaneously
- There are no borders for unfocused windows
resolve#182
This commit introduces a new flag to komorebi and komorebic,
--await-configuration, which when enabled, will stop the process from
processing window manager events and updating the layout until the
'komorebic complete-configuration' command has been sent.
This should typically be added at the end of a user's komorebi.ahk
configuration file if they decide to enable this feature.
resolve#190
This commit ensures that monocle containers and floating windows are
considered validate candidates for the 'toggle-maximize' command and are
handled accordingly if the command is called when they are in the
foreground.
fix#194
This commit ensures that monocle containers and maximized windows are
considered valid candidates for the 'toggle-float' command and are
handled accordingly if the command is called when they are in the
foreground.
fix#193
This commit improves Windows path resolution so that when people run the
ahk-asc command with "applications.yaml" as an argument, without having
".\" prepended, the command will still succeed as expected.
fix#192
This commit ensures that if a window maximized using the 'komorebic
toggle-maximize' is minimized using the UI, on the receipt of the
Minimize WindowManagerEvent, the window will be normalized with
SW_NORMAL before being removed from the window manager state.
This ensures that if the window is later managed again, the user will be
able to toggle-maximize normally again as expected.
This commit ensures that when a window has matched a float rule, the
managed override rule will only apply to that window if the override
identifier is of the same kind (exe, title, class) as the float rule
identifier.
This ensures that the wm isn't constantly trying to allow and disallow
certain windows such as Slack's hidden window, resulting in an infinite
show/hide and retile loop.
This commit fixes a bug with the startup check which tries to ensure
that there is only ever one instance of komorebi running at any given
time.
Previously, only one shim was being checked for, but if a user runs
'komorebic start' multiple times, multiple shims will be active, causing
the check to mistakenly pass.
The changes in this commit now account for N active shims.
This commit ensures that the final argument of the
'workspace-layout-rule' command, which takes a variant of the
DefaultLayout enum, is properly labelled with the #[arg_enum] tag so
that serialization and deserialization works as expected with other
commands that take a DefaultLayout enum variant as an arg.
fix#171
This commit ensures that manage rules have priority over float rules.
This is useful for applications such as Steam, where all windows
including pop-ups have the same class name.
The class name can be used with a float rule to ensure that all Steam
pop-up windows are ignored, and then the title "Steam" can be used with
a manage rule to ensure that the main Steam window does get managed.
fix#163
This commit provides two new commands, to set and toggle the behaviour
(swap, insert) when moving window containers across monitor boundaries.
MoveBehaviour::Swap has been selected as the default as this seems to be
the default on bspwm.
resolve#145
This commit ensures that when moving across a monitor boundary, the
origin window container will be swapped with the last focused window
container on the other side of the monitor boundary.
If there is no window container on the other side of the window
boundary, it will be treated as a move instead of a swap.
re #145
This commit ensures that when focusing across a monitor boundary, the
focus will go to the last focused window container on the focused
workspace on the other side of a given window boundary.
re #145
This commit introduces the ability to operate across monitor boundaries
with the 'move' and 'focus' commands.
When operating down or to the right, the target index of the monitor in
that direction will be 0. When operating up or to the left, the target
index will either be len() - 1 if focusing, or len() if moving.
re #145
This commit ensures that border overflow applications are correctly
identified as being moved instead of being resized when dragged to a new
position using the mouse.
fix#159
This commit introduces two new environment variables to override the exe
name that komorebi uses to verify that AutoHotKey is installed before
launching and reloading 'komorebi.ahk' configuration files.
resolve#147
This commit ensures that a custom layout that is set by a layout rule
will correctly have the width of the primary column increased or
decreased when resize-axis is called with Axis::Horizontal.
re #154
This commit allows the Window.focus() fn to continue execution if
AttachThreadInput fails, as there are valid situations in which this
might fail, but the focusing of the window may/should still succeed.
fix#156
This commit tweaks how float rule matching for titles and classes works.
Previously, they required an exact match to be triggered.
This change allows starts_with and ends_with matches on classes and
window titles to also trigger a float rule for applications that
dynamically change their window titles or window classes.
Exe matches are still required to be exact.
This commit ensures that what monitor reconciliation is triggered from a
MonitorPoll event, the focused monitor is only updated when the HWND
associated with the event is known not to be tied to a specific (in this
case, the primary) monitor.
This ensures that silent state updates do not occur and avoids
unexpected behaviour when performing operations relative to the
currently focused window on a non-primary display (focus, move etc.)
This commit adds a new command, 'unmanaged-window-operation-behaviour'
which allows the user to configure their desired behaviour in situations
when sending window container commands which operate on the focused
window container in the workspace state, but having an unmanaged window
as the foreground hwnd.
The default previously was previously Op (and this remains the default
with these new changes), but the user can now select NoOp, which will
return an error when the focused hwnd is unmanaged and not allow any
write operations to take place on the focused workspace state.
resolve#133
This commit ensures that the origin workspace will be updated after a
container is removed to be sent to a target workspace (specified, or
currently focused) on another monitor.
With this change in place, moving window containers to another monitor
should not result in a ghost container that remains until the next
retile on the origin workspace.
fix#132
@riverar pointed out on Discord that I had my if and else clauses here
mixed up. This commit reintroduces null value checks for HWNDs returned
from Windows API calls.
Previously, generated AHK did not surround with quotes inputs which
could contain spaces such as application titles. This commit ensures
that in any generated AHK code where an application id is passed to a
komorebic.exe command as input, that input will always be quoted.
This fixes bugs related to float rules, manage rules and other
application identification commands not being properly executed via
komorebic called from the generated AHK files when the app id contained
a space.
Small commit to temporarily handle a regression introduced by my changes
when upgrading from 0.34 to 0.35.
Checking for a 0 HWND value results in an Err being propagated in fns
like GetForegroundWindow, while the error message just reads "The
operation completed successfully. (os error 0)".
This behaviour was causing regressions in features such as window
floating which seems to be resolved by removing the 0 HWND check.
This commit adds a second optional argument to the ahk-asc command which
can take an override yaml file. This file can include either entirely
new entries that are not suitable for the asc definitions in the
community repo, or overrides for entries that exist in the community asc
definitions files which will take precedence in the generated ahk file.
This can be useful for example, when the default behaviour for an app is
to minimise to system tray, but that option has been disabled on a
user's computer, making the 'tray_and_multi_window' option no longer
appropriate for their komorebi configuration.
In the case of wanting to override an existing entry, only the "name"
key needs to match; upon a match the entry from the community asc
definitions will be entirely replaced with the entry from the override
definitions.
re #62
This commit adds a fmt command which allows users to prepare PRs to the
configuration repository in a unified way.
The 'custom' formatter basically just ensures that the yaml array is
sorted by application name to make for easier diffs.
Serializing of Option::None has been disabled to keep the yaml file more
concise.
Finally, an option for adding comments to float rules has been included
as some of these rules can be quite esoteric and there is value in
having them annotated with comments in the configuration to preserve and
pass down the knowledge.
The config generation command has been renamed to
'ahk-app-specific-configuration' (with a short alias of 'ahk-asc') to
emphasise that an ahk file is being generated (similar to
'ahk-library').
re #62
This commit introduces a configuration generator for
application-specific config options passed to the cli via a file path.
The hope is to have a public repository that any user can contribute
application-specific configs and fixes to, and for the generated AHK to
be available to any new user as part of the initial setup to make the
onboarding as frictionless as possible.
re #62
Users on Discord noted that Microsoft Office applications were not being
handled correctly by the wm. After some investigation it was clear that
this was because the application windows had WS_EX_LAYERED set.
This had only been seen once before with Steam, and so a whitelist for
layered applications was previously added to the codebase with steam.exe
hard-coded, but this had not been exposed via the cli.
This commit adds a command to allow users to specify layered
applications which should be managed, and also renames the whitelist to
reflect that classes can also be used to identify applications on the
whitelist.
A section has been added to the README to guide Microsoft Office users
to guide Microsoft Office users in configuring komorebi to correctly
handle Office applications with Word given as an example.
This commit also renames the identify-border-overflow command to
identify-border-overflow-application for consistency, while retaining
the previous command as an alias to maintain compatibility with existing
user configurations.
It should be noted however, that those like me who are using the
generated komorebic AHK library, will have to update any AHK function
calls to use IdentifyBorderOverflowApplication().
resolve#124
This commit introduces focus cycling behaviour for a workspace when
either a maximized window or a monocle window exists.
Now, the container in the cycle direction relative to the current window
container will take the maximized or monocle window container space
whenever the cycle-focus command is called.
resolve#97
This commit adds a new feature which allows the user to specify a set of
rules for a specific workspace that will be used to calculate which
layout to apply to that workspace at any given time.
The rule consists of a usize, which identifies the threshold of window
containers which need to be visible on the workspace to activate the
rule, and a layout, which will be applied to the workspace when the rule
is activated.
Both default and custom layouts can be used in workspace layout rules.
When a workspace has layout rules in effect, manually changing the
layout will not work again until the rules for that workspace have been
cleared.
This feature came about after trying but failing to modify the custom
layout code in such a way that the width percentage of a primary column
in a custom layout might be propagated to the fallback columnar layout
when the tertiary column threshold is not met.
Although this new feature introduces more complexity, it is strictly
opt-in and can be completely ignored if the user has no interest in
adjusting layouts based on the visible window count.
re #121
A user on the Discord noted that PyCharm windows were not being managed
as expected when initially launched. After some digging this seems to be
the same issue that was addressed for IntelliJ and Firefox early on in
development, where these applications send EVENT_OBJECT_NAMECHANGE on
launch instead of the regular event when drawing a new window.
The OBJECT_NAME_CHANGE_ON_LAUNCH vec was not previously exposed via
komorebic to allow users to identify other applications that exhibit the
same behaviour. This commit adds a command to allow users to specify
further applications in their configuration files.
This commit introduces the 'notification-schema' command to generate a
JSON schema of the Notification struct which gets sent when notifying
subscribers of updates.
This commit introduces a change to allow users to set a custom
configuration directory for Komorebi to address concerns about $HOME
getting cluttered.
The custom directory can be set with the environment variable
$Env:KOMOREBI_CONFIG_HOME (this should probably be done in $PROFILE).
If this variable is not set, komorebi will default to using
the $HOME directory.
resolve#61
This commit addresses issues that users have been faced with when
installing komorebi with scoop, which resulted in komorebi exiting
almost immediately without providing any feedback as to what had
happened.
Scoop launches komorebi using an exe shim of the same name, which
results in two komorebi.exe named processes running at the same time.
This situation then fails the startup check which attempts to ensure
that only one instance of komorebi.exe ever runs at any given time.
The process startup check has been updated to allow for two komorebi.exe
named processes to be running if one of them is recognised as a Scoop
shim process.
fix#95
This update ensures that whenever a new float rule is added, the focused
workspaces on all monitors will be checked to see if there are any
currently managed windows which match that rule. If so, the matching
window(s) will be removed from the workspace and the workspace will be
updated.
Matching windows on non-focused workspaces will not be removed, as these
windows may be hidden, and removing them could result in these windows
being inaccessible, requiring them to be killed before they can be
relaunched
fix#93
This commit adds a new komorebic command to move the entire focused
workspace and all managed windows and containers to a target monitor
index. Windows that have been excluded from management using various
rules will not be moved as they are not tracked in the window manager
state.
resolve#88
This commit ensures that errors are sent to komorebic in response to the
state command if they occur, so that komorebic is not left hanging
indefinitely waiting for a successful response that will never come.
This commit fixes a regression introduced in
85fe20ebba, where running komorebi before
creating and interacting with virtual desktops via the task view on
Windows 10 would cause komorebi to panic when it could not find the
CurrentVirtualDesktop key in the registry, as it only gets populated
after interacting with virtual desktops via the task view in a new
session.
This commit adds a new command which allows the focusing of workspaces
on monitors other than the currently focused monitor by specifying a
monitor index.
Sending this command to komorebi will make the target monitor index the
currently focused monitor.
resolve#85
This commit refactors the validations that ensure that only commands and
events originating on the same virtual desktop that komorebi was started
on are managed.
This was previously handled by the winvd crate which relied on
undocumented APIs that broke as of Windows 11. This method, while not
very elegant, seems like the best solution for now.
In short, komorebi checks the registry (which has different paths on
Win10 and Win11...) to keep track of the current virtual desktop id.
This is problematic because we just end up comparing byte arrays, and
there is no meaningful representation of the ids that are being
compared, not even a GUID. Nevertheless, it works and it ensures that
komorebi is limited to operating on a single virtual desktop.
resolve#77
This commit adds a command to let the user decide if they want windows
to be hidden with SW_HIDE or minimized with SW_MINIMIZE when workspaces
are changed or window container stacks are cycled.
After a modest amount of local testing, SW_MINIMIZE does not appear to
introduce any regressions, and given that alt-tabbing is a common
workflow on Windows, it makes sense to have minimizing be the default
setting to ease the onboarding experience for new users.
resolve#72
This commit adds OPContainerClass and IHWindowClass to the
FLOAT_IDENTIFIERS global vec, to ignore by default the extra invisible
input and output handling windows created by mstsc.exe when WSL is
launched on Windows 11.
fix#74
This commit ensures that when a window is dragged over another window container while
WindowContainerBehaviour::Append is set, the window will be removed from its current
container and appended to the target container instead of swapping the positions of the two
containers, as would be the case for WindowContainerBehaviour::Create.
re #72
This commit introduces a new command, toggle-new-window-behaviour, which
can be used to toggle how new windows on the screen will be handled.
The default setting is to add a new window in a dedicated container, but
when toggled, new windows will be stacked on top of the currently
focused window container.
This can be useful if you only want to use a certain number of columns,
and when you have enough windows on the screen for them, you can toggle
the new window behaviour to start appending to the existing column
stacks.
This commit also fixes a bug where stacked windows being closed did
cause the next window underneath in the stack to be shown.
re #72
This commit allows the resize-axis cmd on Axis::Horizontal to operate on
the Primary column of a CustomLayout.
Note that this will only operate on a CustomLayout that has met the
window count threshold to enable the tertiary column. If it has not, the
layout will render as DefaultLayout::Columns, which does not support the
resize-axis cmd.
This commit adds a command to set the resize delta used under the hood
by the resize-edge and resize-axis commands. The resize delta defaults
to 50 pixels as was hard-coded previously.
This commit updates a number of komorebic subcommand names while
maintaining their old names as aliases in order to preserve backwards
compatibility.
Resize becomes ResizeEdge, to complement ResizeAxis, and all of the
commands for saving and loading BSP resize adjustments (QuickSave,
QuickLoad, Save, Load) are now post-fixed with "Resize" in order to make
it clear that these commands are not related to custom layout saving and
loading.
This commit adds a new command to resize by axis. Resizing is still
limited to the BSP layout. This command is intended to be bound to mouse
wheel up and down events, with different modified keys determining the
axis to operate on.
This commit ensures that when a window is dragged across a monitor
boundary, the ownership of the window container will be transferred to
the target monitor's currently focused workspace.
In order to achieve this, a new WindowManagerEvent variant has been
added, MoveResizeStart, which will store an optional pending_move_op on
the WindowManager struct. This must be consumed at the beginning of the
handler for MoveResizeEnd.
This is necessary because as soon as the window is dragged across a
monitor boundary, an event is sent (and handled) to update the currently
focused monitor and workspace as the target monitor and workspace, and
we still need to have the information about the original monitor,
workspace and container in order to make comparisons and ultimately
remove the origin container to be able to transfer it.
fix#58
This commit bumps the version of the windows-rs and deprecates the
bindings crate in favour of using the pre-packaged APIs that are
available as of 0.22.
This commit embeds the latest window manager state (as returned from
'komorebic.exe state') as part of the event notifications sent to
subscribers.
Separately, WindowManager.update_focused_workspace has been refactored
to allow a failure to set the foreground window to the default desktop
window on an empty workspace to log a warning instead of returning an
error, allowing messages previously impacted by this to run to
conclusion and be surfaced in the event notifications stream.
resolve#56
I came across some panics when trying to run the custom serialization of
the Window struct for windows that were in the process of being
destroyed recently.
This commit replaces all of the expect() calls in the Serialize
implementation for Window with calls to serde::ser::Error::custom()
which should fail gracefully without rendering the thread that
previously panicked as useless.
fix#55
This commit renames add-subscriber and remove-subscriber to subscribe
and unsubscribe for more semantic consistency in command names, as well
as improving and fixing the cli documentation for these commands.
@denBot's example of how to create named pipes and subscribe to events
has also been added to the readme.
This commit adds two new commands to add and remove subscribers to
WindowManagerEvent and SocketMessage notifications after they have been
handled by komorebi.
Interprocess communication is achieved using Named Pipes; the
subscribing process must first create the Named Pipe, and then run the
'add-subscriber' command, specifying the pipe name as the argument
(without the pipe filesystem path prepended).
Whenever a pipe is closing or has been closed, komorebi will flag this
as a stale subscription and remove it automatically.
resolve#54
This commit adds some documentation around custom layouts as well as a
YAML example.
The load-layout command has been renamed to load-custom-layout for
consistency.
resolve#50
This commit adds support for loading custom layouts from yaml files, and
also moves the custom layout loading and validating logic into the
komorebi-core crate.
re #50
This commit adds a ColumnWidth for Column::Primary which can optionally
be given as a percentage of the total work area of a monitor. The
remaining columns will have their widths calculated by dividing the
remaining work area space evenly.
This commit also fixes a bug with the Promote command, which was not
calculating the primary container index of custom layouts properly, and
was also not using this value to update the focused container index at
the end of the promotion handler.
re #50
This commit introduces a number of refactors to layouts in general in
order to enable navigation across custom layouts and integrate both
default and custom layouts cleanly into komorebi and komorebic.
Layout has been renamed to DefaultLayout, and Layout is now an enum with
the variants Default and Custom, both of which implement the new traits
Arrangement (for layout calculation) and Direction (for operation
destination calculation).
CustomLayout has been simplified to wrap Vec<Column> and no longer
requires the primary column index to be explicitly defined as this can
be looked up at runtime for any valid CustomLayout.
Given the focus on ultrawide layouts for this feature, I have disabled
(and have not yet written the logic for) vertical column splits in
custom layouts.
Since CustomLayouts will be loaded from a file path, a bunch of
clap-related code generation stuff has been removed from the related
enums and structs.
Layout flipping has not yet been worked on for custom layouts.
When switching between Default and Custom layout variants, the primary
column index and the 0 element are swapped to ensure that the same
window container is always at the focal point of every layout.
Resizing/dragging to resize is in a bit of weird spot at the moment
because the logic is only implemented for DefaultLayout::BSP right now
and nothing else. I think eventually this will need to be extracted to a
Resize trait and implemented on everything.
This commit introduces a new Trait, Dimensions, which requires the
implementation of a fn calculate() -> Vec<Rect>, a fn that was
previously limited to the Layout struct.
Dimensions is now implemented both for Layout and the new CustomLayout
struct, the latter being a general adaptive fn which employs a number of
fallbacks to sane defaults when the the layout does not have the minimum
number of required windows on the screen.
The CustomLayout is mainly intended for use on ultra and superultrawide
monitors, and as such uses columns as a basic building block. There are
three Column variants: Primary, Secondary and Tertiary.
The Primary column will typically be somewhere in the middle of the
layout, and will be where a window is placed when promoted using the
komorebic command.
The Secondary column is optional, and can be used one or more times in a
layout, either splitting to accomodate a certain number of windows
horizontally or vertically, or not splitting at all.
The Tertiary window is the final window, which will typically be on the
right of a layout, which must be split either horizontally or vertically
to accomodate as many windows as necessary.
The Tertiary column will only be rendered when the threshold of windows
required to enable it has been met. Until then, the rightmost Primary or
Secondary column will expand to take its place.
If there are less windows than (or a number equal to the) columns
defined in the layout, the windows will be arranged in a basic columnar
layout until the number of windows is greater than the number of columns
defined in the layout.
At this point, although the calculation logic has been completed, work
must be done on the navigation logic before a SocketMessage variant can
be added for loading custom layouts from files.
This commit introduces an allow_wsl2_gui override in
Window.should_manage() which ensures that Linux GUI apps being run
through WSLg, VcXsrv or X410 will be automatically tiled.
For now the exes that trigger this override are kept in a static Vec in
the codebase, but this could be made configurable in the future if there
is a specific feature request.
resolve#52, resolve#53
This commit applies 'cargo fix --edition' to safely migrate the project
to Edition 2021 of Rust.
A rustfmt.toml has also be added to enforce the flattening of use
statements when running 'cargo fmt'.
This commit fixes a boolean logic error with an extra pair of parens to
ensure that apps like Firefox don't end up with their HWNDs reaped by
Workspace.remove_window() when another window is stocked on top of them.
fix#51
This commit extracts independent functions for calculating row and
column layouts in an arbitrary work area. This should be useful in the
future for some ideas I have around custom serializable layouts.
This commit ports the CenterMain, MainAndVertStack, and
MainAndHorizontalStack layouts from LeftWM to komorebi as
UltrawideVerticalStack, VerticalStack and HorizontalStack.
These layouts are fixed-size layouts, meaning that individual containers
cannot be resized. The VerticalStack and UltrawideVerticalStack layouts
support horizontal flipping, whereas the HorizontalStack layout supports
vertical flipping.
resolve#48
This commit adds a new komorebic command to specify offsets for work
areas to be applied across all monitors. The areas covered by these
offsets will be excluded from the tiling area, and can be used for
custom task bars, Rainmeter desktop widgets etc.
When setting an offset at the top, the same offset will need to be
applied to the bottom to ensure that the tiling area is not pushed off
of the screen, but this is not necessary when applying an offset to the
bottom as the top of the work area will never go lower than 0.
resolve#46
This commit adds focusing and moving window containers using cycle
directions when the layout has not been flipped on any axis.
This naive implementation simply increments or decrements the index
number in the desired direction and does not accomodate for axis
flipping.
When the current index number is either at the beginning or the end of
the collection, further operations will loop around.
Ideally I would like an implementation which works coherently on any
LayoutFlip state, but this can be implemented at a later date if
specifically requested in the future.
re #47
This commit expands on the autosave/load functionality to allow saving
and loading layouts from any file.
Handling relative paths and paths with ~ on Windows is a little tricky
so I added a helper fn to komorebic to deal with this, ensuring all the
processing happens in komorebic before the messages get sent to komorebi
for processing.
There will still some lingering uses of ContextCompat around the
codebase which I also took the opportunity to clean up and replace with
ok_or_else + anyhow!().
windows-rs is also updated to 0.20.1 in the lockfile.
resolve#41
This commit adds two new komorebic commands to quicksave and quickload
BSP layouts with custom resize dimensions. The quicksave file is stored
at ${Env:TEMP}/komorebi.quicksave.json, and is a Vec<Option<Rect>>
serialized to JSON.
If a user tries to quickload without a quicksave file being present, an
error will be logged.
At this point there is only one quicksave file which will always be
overwritten whenever the quicksave command is called. Both commands will
only operate on the focused workspace of the focused monitor.
This means that you can quicksave a layout on one workspace, and then
quickload it onto multiple other workspaces (individually) on the same
or other monitors.
If the number of elements in the deserialized Vec is greater than the
number of containers on a workspace, the Vec will be truncated when
Workspace.update is run, and similarly if the number of elements is less
than the number of containers on a workspace, the Vec will be extended
by the difference using None values.
resolve#39
Whatever resize dimensions are at the front of the workspace were
previously being thrown away and overwritten with None whenever a
Promote command was being handled.
This commit preserves any resize dimensions that may already be there
and restores them after the container promotion has been completed.
fix#40
The 0.20.0 release of windows-rs includes a Handle trait which provides
ok() and invalid() fns for implementors, including HWND and HANDLE.
This is pretty cool (and also a big breaking change since the release
takes away is_null() at the same time...), so the code in windows_api.rs
has been updated to make use of this by implementing a
ProcessWindowsCrateResult trait with a process() fn.
When implemented for a windows::Result<T>, it will do any required
processing for T, and ensure that windows::Error is converted to an
eyre-compatible Report.
Switching to this means that I have been able to get rid of some of the
hacky error handling for weird behaviours encountered previously. So
far, they don't seem to be presenting again, but I will run with this
build for a couple of days to see if the false-negative errors are
really gone for good with this update.
This commit expands the reconcile_monitors fn to also update resolution
and work area sizes if they are different from what is stored in the
window manager state.
Another WindowManagerEvent has been added as a polling mechanism for
monitor-related changes (scaling, dpi, resolution etc.), and this will
now also trigger the reconcile_monitors fn in the existing event
pre-processing block.
resolve#36
Following the discovery that the custom FFM implementation significantly
increases CPU usage, and that the underlying library used to track mouse
events is already as optimised as possible for CPU usage, this commit
makes the enabling of custom FFM explicit via a command line flag when
launching the window manager.
The underlying library does not provide for a way to clean up and
recreate a message loop on demand, which means that once it starts,
there is no way of reclaiming those CPU cycles even when FFM is
disabled.
If a user has not started komorebi with the --ffm flag and tries to
enable or toggle custom FFM, a warning will be shown in the logs and
komorebi will override their selection to operate on the Windows FFM
implementation.
In light of this, the default implementation values for komorebic's FFM
commands have been updated to 'windows'.
This commit also takes the opportunity to allow the state and stop
commands to pass when the window manager is in a paused state.
resolve#33
This commit ensures that the focused workspace on the target monitor is
updated with the latest layout after it receives a window via the
send-to-monitor command.
resolve#37
Following the changes I witnessed in the invisible window border size
following an OS update, this commit makes the invisible border offset
configurable via a new komorebic command 'invisible-borders'.
When sending a new set of invisible border offset dimensions via
komorebic, a full retile across all monitors will take place after the
new values have been set.
The default values have been set to what is currently correct for my
machine, and will likely be updated again in the same way in the future
if further changes occur in subsequent OS updates.
This commit also updates some dependencies to their latest releases, and
removes from the CI workflow a line that attempts to delete the
rustup-init.exe binary after installation which has been causing builds
to fail.
resolve#35
Applications like Spotify and Discord draw over the default invisible
borders of Windows 10, which means that when komorebi is setting their
positions, the offset is always off by the amount of pixels of the
invisible borders on each side.
This commit makes it possible to identify applications that have
overflowing borders so that they can be handled appropriately by the
window manager.
This commit also takes the opportunity to consolidate the tray and multi
window identifiers into a single vector instead of spreading them across
multiple vectors by identifier type.
resolve#32
When monitors turn on and off, they do not retain their hmonitor id,
therefore this commit introduces an initial attempt to reconcile invalid
and valid hmonitors after monitor changes based on the windows that are
assigned to them.
If a monitor has at least one window, and has been assigned a new
hmonitor id, komorebi will look up the current hmonitor of that window's
hwnd and update Monitor.id in-place.
When reconciling monitors, any monitor marked as invalid will be purged
from the window manager state.
This commit also applies some of the new clippy lints that come along
with the latest nightly release of Rust.
resolve#31
Explorer windows are made up of multiple different sub-windows which can
make trouble for the ffm implementation if not known about.
This commit pushes up a check to ignore the raise request if the window
are the cursor position is already raised and in the foreground, and
also makes checks against an overlay_classes array to try and look up an
underlying hwnd that should probably be raised by a cursor move.
Previously, when switching focus from unmanaged windows such as the
taskbar and the system tray, komorebi would still recognise its last
known focused window as the currently focused window although that would
not be strictly true, making the ffm functionality stop working until
focus was set to a known window specifically either via a click or an
alt-tab.
This commit fixes that by always also comparing against what the OS has
registered as the current foreground window.
There is another little fix here to reset the pending raise op tracker
whenever ffm is toggled or disabled in the event that it ever gets
stuck.
This commit adds an optional flag to allow users to select the focus
follows mouse implementation that they wish to use (komorebi or
windows). The flag defaults to komorebi.
The ahk-derive crate has been updated to enable the generation of
wrappers fns that require flags.
I pushed the ffm check up to listen_for_movements() so that we don't
even try to listen to the next event from the message loop unless
komorebi-flavoured ffm is enabled.
re #7
This commit implements an initial attempt at a custom focus follows
mouse and autoraise implementation which only responds to hwnds managed
by komorebi.
I was browsing GitHub and came across the winput crate which has a clean
API for tracking both mouse movements and button presses, which seems to
be just enough to get this functionality working.
Once again, Chromium and Electron are the bane of every platform they
run on and Windows is no exception, so I've had to add a hack to work
around the legacy Chrome windows that get drawn on top of Electron apps
with the Chrome_RenderWidgetHostHWND class.
It is fairly naive; it just looks up an alternative (and hopefully
correct) hwnd based on the exe name, but this will no doubt be fragile
when it comes to applications that have multiple windows spawned from
the same exe.
For now I've opted to keep the same komorebic commands for enabling,
disabling and toggling focus-follows-mouse, in order to preserve
backwards compat, but those commands will now enable and disable this
custom implementation instead of the native Windows X-Mouse
implementation.
Perhaps in the future the specific implementation to target could be
specified through the use of an optional flag.
re #7
If a user wants to switch workspace on a secondary monitor which
contains no windows, komorebi doesn't register the monitor as focused
unless the corresponding komorebic command to switch monitor focus is
called explicitly. This generally works fine for users with a
keyboard-heavy workflow.
This commit changes the workspace switching behaviour to look up the
current monitor based on the cursor position just before the switch
takes place, so that the behaviour is still intuitive when trying to
change the monitor focus via the mouse.
re #30
This commit adds a new query command to komorebic, which allows for the
current focused monitor, workspace, container and window indices to be
queried directly without having to use jq run lookups on the entire
output of the state command.
resolve#24
Adding a section under ##About for links to translations of the document
in other languages, starting with @crosstyan's Chinese translation.
resolve#21
Previously, the implementation of maximized and monocle windows assumed
that the only valid state for them to transition to would be to restore
them to the index that they were maximized/monocle-d from in their host
workspace.
This is not exclusively the case as it is also possible for them to be
closed when they are in a maximized or monocle state.
This commit updates the Workspace.remove_window() fn to also look for
the hwnd to be removed in the monocle container and maximized window, if
they exist.
fix#19
This commit adds two commands to allow the user to send the currently
focused container to a different workspace or monitor as a background
operation, without following the moved container to the destination
workspace or monitor.
resolve#20
Decided there should be a quick way to toggle the native ffm
functionality, it gets especially annoying when trying to click drop
downs from the system tray etc.
re #7
This commit removes the unnecessary eyre dependency and instead uses the
relevant imports from color-eyre.
Additionally, after reading the eyre readme a little more closely, I
have switched out .compat() for the ok_or() combinator function as
suggested here: https://github.com/yaahc/eyre#compatibility-with-anyhow.
This commit pushes as much of the generation logic as possible to the
derive-ahk crate, so that when it is used in komorebic, we only need to
do an as_bytes() call to prepare it for being written to a file.
Besides that, this commit changes the generation command name to
'ahk-library' for clarity, and adds both additional samples and
instructions in the readme file and Scoop post-install hook.
Woke up today and thought this would be a cool way to learn more about
deriving functionality with proc macros.
Hopefully having this wrapper/helper library will make first time
configuration for new users easier.
Silly boolean error meant that if a link was clicked in one
monitor/workspace, the browser, if not on the same workspace, would be
brought into the workspace the link was clicked in.
This was because I was checking if the focused monitor != the known
monitor && the focused workspace != the known workspace, when in fact,
we don't need both of those conditions to be true in order to switch to
where the browser is, we only need one of them to be true.
After changing the && (and) to a || (or), the behaviour is now as
expected, and clicking a link will switch to the workspace where the
browser is open.
2021-08-20 17:16:16 -07:00
312 changed files with 49350 additions and 4091 deletions
Please **do not** open an issue for applications with invisible windows leaving ghost tiles.
You can run `komorebic visible-windows` when the ghost tile is present on your workspace to retrieve the invisible window's exe, class name and title, and then use that information to [ignore the window](https://lgug2z.github.io/komorebi/common-workflows/ignore-windows.html) responsible for the ghost tile.
If it is not possible to uniquely identify the invisible window resulting in a ghost tile through a mixture of exe, title and class identifiers, then this is not a bug with komorebi but a bug with the application you are using, and you should open an issue with the developer(s) of that application.
- type:textarea
validations:
required:true
attributes:
label:Summary
description:>
Please provide a short summary of the bug, along with any information
you feel is relevant to replicating the bug.
You may include screenshots and videos in this section.
- type:textarea
validations:
required:true
attributes:
label:Version Information
description:>
Please provide information about the versions of Windows and komorebi
running on your machine.
Do not submit a bug if you are not using an official version of Windows
such as AtlasOS; only official versions of Windows are supported.
description:Suggest a new feature (Limited to Sponsors, Commercial License Holders, and Collaborators)
labels:[enhancement]
title:"[FEAT]: "
body:
- type:dropdown
id:Eligibility
attributes:
label:Eligibility
description:>
Feature requests are considered from individuals who are current $5+ monthly sponsors to the project, individual commercial use license holders, and approved collaborators.
Please specify the platform you use to sponsor the project.
options:
- Individual Commercial Use License
- GitHub Sponsor
- Ko-fi Sponsor
- Approved Collaborator
default:0
validations:
required:true
- type:textarea
validations:
required:true
attributes:
label:Suggestion
description:>
Please share your suggestion here. Be sure to include all necessary context.
If you sponsor on a platform where you use a different username, please specify the username here.
- type:textarea
validations:
required:true
attributes:
label:Alternatives Considered
description:>
Please share share alternatives you have considered here.
Feature requests on this repository are only open to current [GitHub sponsors](https://github.com/sponsors/LGUG2Z) on the $5/month tier and above, people with a valid [individual commercial use license](https://lgug2z.com/software/komorebi), and approved contributors.
This issue has been automatically closed until one of those pre-requisites can be validated.
{"event":{"type":"FocusChange","content":["SystemForeground",{"hwnd":329264,"title":"den — Mozilla Firefox","exe":"firefox.exe","class":"MozillaWindowClass","rect":{"left":1539,"top":894,"right":1520,"bottom":821}}]},"state":{}}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
