starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

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

New Issue
Closed
opened 2026-01-05 14:51:41 +01:00 by adam · 3 comments
adam commented 2026-01-05 14:51:41 +01:00
Owner
Copy Link

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

  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
  2. 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
  3. 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 enhancementkomorebici-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
Author
Owner
Copy Link

@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
Author
Owner
Copy Link

@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
Author
Owner
Copy Link

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

This will be in the next nightly and 0.1.35 when it is released

@LGUG2Z commented on GitHub (Feb 21, 2025): This will be in the next nightly and 0.1.35 when it is released
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label enhancement i-will-definitely-work-on-this komorebic
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#576
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?