Add komorebic.exe command to add new workspace to focused monitor #4
Labels
enhancement
New feature or request
Comments
alex-ds13
added a commit
to alex-ds13/komorebi
that referenced
this issue
Jan 21, 2025
# This is a combination of 8 commits.
# This is the 1st commit message:
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.
# This is the commit message LGUG2Z#2:
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.
# This is the commit message LGUG2Z#3:
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.
# This is the commit message LGUG2Z#4:
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!
# This is the commit message LGUG2Z#5:
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).
# This is the commit message LGUG2Z#6:
docs(schema): update all json schemas
# This is the commit message LGUG2Z#7:
fix(bar): update example bar config
# This is the commit message LGUG2Z#8:
fix(bar): correct work_area_offset on secondary monitors
alex-ds13
added a commit
to alex-ds13/komorebi
that referenced
this issue
Feb 22, 2025
# This is a combination of 4 commits. # This is the 1st commit message: 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. # This is the commit message LGUG2Z#2: refactor(wm): move update of known_hwnds to a function # This is the commit message LGUG2Z#3: feat(wm): update known_hwnds on process_command # This is the commit message LGUG2Z#4: refactor(wm): simplify loops on monitor/workspaces This commit uses the new `known_hwnds` hashmap to simplify looking for windows on all the monitors and all the workspaces. 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. This commit already does this on some situations from the `process_event`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Workspaces in
komorebiare unrelated to Windows Virtual Desktops; they are implemented as a thin layer on top of the existing DWM by showing and hiding windows programmatically. You have a few options for workspace creation right now:komorebic.exe ensure workspaces MONITOR_IDX DESIRED_WORKSPACE_COUNTThis is usually run at the start of a config file to ensure the minimum number of workspaces that you want to work with on each monitor.
This will try to switch to the given workspace index on the active monitor, and if it doesn't exist, it will be created, along with any other required workspace indices on the way. For example, if you only have one workspace (
0) on the monitor, and you try to focus workspace index3, workspaces1and2will also be created in the process.I think it's a good idea to have a command that will just append a new workspace on the currently focused monitor (similar to the Win+Ctrl+D behaviour); I'll open a separate ticket to track this.
Originally posted by @LGUG2Z in #1 (comment)
The text was updated successfully, but these errors were encountered: