[FEAT]: Make window based work area offset togglable #576

New Issue

2026-01-05T14:51:41+01:00

adam commented

2026-01-05 14:51:41 +01:00

Originally created by @swebra on GitHub (Feb 20, 2025).

Originally assigned to: @LGUG2Z on GitHub.

Eligibility

Individual Commercial Use License

Suggestion

Using my new found commercial license (yahoo! excited to support the project) to pull up the suggestion of exposing the apply_window_based_work_area_offset workspace setting via the CLI to make it set-able/togglable at runtime.

This has previously been suggested at the end of Q&A #952 (here and here), but those comments were not directly related to the original question and were made after the question was answered, so they may have been lost.

I think the use-case largely stems from a desired window size being content dependent, take a browser on an ultrawide monitor as an example. A more-reasonably-sized window afforded by window_based_work_area_offset is great in the general case of reading webpages, but when interacting with a spreadsheet through the browser, the full width may be desired.

Alternatives Considered

Using the existing toggle-maximize to mock a "apply_window_based_work_area_offset": false (as suggested in the original comments)
- Doesn't maintain gap configuration
- Doesn't address the case where window_based_work_area_offset > 1
Moving the window(s) to a new workspace where "apply_window_based_work_area_offset": false
- Breaks the flow of "always have X content on Y workspace to be able to jump to it quickly with Z shortcut"
- Requires an empty workspace on standby (though I'm not entirely sure if dynamically created workspaces can have "apply_window_based_work_area_offset": false set)
- Just sort of feels inelegant
Allowing the window_based_work_area_offset region to be resized via CLI similar to resize-axis
- More complex than just hooking into the existing apply_window_based_work_area_offset toggle
- As window_based_work_area_offset is currently set per-monitor, a naive implementation would be monitor-wide rather than for the one workspace
- That granularity of control is certainly not needed in my case, so may not be worth the complexity.

Originally created by @swebra on GitHub (Feb 20, 2025). Originally assigned to: @LGUG2Z on GitHub. ### Eligibility Individual Commercial Use License ### Suggestion Using my new found commercial license (yahoo! excited to support the project) to pull up the suggestion of **exposing the `apply_window_based_work_area_offset` workspace setting via the CLI to make it set-able/togglable at runtime.** This has previously been suggested at the end of Q&A #952 ([here](https://github.com/LGUG2Z/komorebi/discussions/952#discussioncomment-10899823) and [here](https://github.com/LGUG2Z/komorebi/discussions/952#discussioncomment-10930788)), but those comments were not directly related to the original question and were made after the question was answered, so they may have been lost. I think the use-case largely stems from a desired window size being content dependent, take a browser on an ultrawide monitor as an example. A more-reasonably-sized window afforded by `window_based_work_area_offset` is great in the general case of reading webpages, but when interacting with a spreadsheet through the browser, the full width may be desired. ### Alternatives Considered 1. Using the existing `toggle-maximize` to mock a `"apply_window_based_work_area_offset": false` (as suggested in the original comments) - Doesn't maintain gap configuration - Doesn't address the case where `window_based_work_area_offset` > 1 1. Moving the window(s) to a new workspace where `"apply_window_based_work_area_offset": false` - Breaks the flow of "always have X content on Y workspace to be able to jump to it quickly with Z shortcut" - Requires an empty workspace on standby (though I'm not entirely sure if dynamically created workspaces can have `"apply_window_based_work_area_offset": false` set) - Just sort of feels inelegant 1. Allowing the `window_based_work_area_offset` region to be resized via CLI similar to `resize-axis` - More complex than just hooking into the existing `apply_window_based_work_area_offset` toggle - As `window_based_work_area_offset` is currently set per-monitor, a naive implementation would be monitor-wide rather than for the one workspace - That granularity of control is certainly not needed in my case, so may not be worth the complexity.

adam added the enhancement komorebic i-will-definitely-work-on-this labels 2026-01-05 14:51:41 +01:00

adam closed this issue

2026-01-05 14:51:41 +01:00

adam commented

2026-01-05 14:51:42 +01:00

@github-actions[bot] commented on GitHub (Feb 20, 2025):

Feature requests on this repository are only open to current GitHub sponsors on the $5/month tier and above, people with a valid individual commercial use license, and approved contributors.

This issue has been automatically closed until one of those pre-requisites can be validated.

@github-actions[bot] commented on GitHub (Feb 20, 2025): 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.

adam commented

2026-01-05 14:51:42 +01:00

@LGUG2Z commented on GitHub (Feb 21, 2025):

Hi @swebra, thanks for opening this issue! I had actually sent an email out to your employer which purchased the license yesterday asking for the name of the person to associate the license with, I'm lucky you came to track me down first!

This feature request makes sense; I think komorebic toggle-window-based-work-area-offset is a command we can add in the next release.

@LGUG2Z commented on GitHub (Feb 21, 2025): Hi @swebra, thanks for opening this issue! I had actually sent an email out to your employer which purchased the license yesterday asking for the name of the person to associate the license with, I'm lucky you came to track me down first! This feature request makes sense; I think `komorebic toggle-window-based-work-area-offset` is a command we can add in the next release.

adam commented

2026-01-05 14:51:42 +01:00