mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
[FEAT]: Infinite Scrollable Tiling #613
Reference in New Issue
Block a user
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?
Originally created by @LeFauxMatt on GitHub (May 9, 2025).
Eligibility
GitHub Sponsor
Suggestion
As someone who uses an ultrawide monitor, inifinite scrollable tiling (such as the one implemented by niri for Linux) would help me make optimal use of my screen space. The challenge I have with any tiling window manager is that one or even two windows on a screen occupy a lot more horizontal space than is really necessary. What scrollable would solve is that I could pin windows to a desired width, and easily bring any desired window into focus.
Alternatives Considered
Such options exist for Linux (niri & PaperWM) and MacOS (PaperWM.spoon), but I have not found anything for Windows.
Update: Per the recent changelogs, it seems that Jwno may eventually have this as an option, but it hasn't been demonstrated beyond a POC.
@github-actions[bot] commented on GitHub (May 9, 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.
@LGUG2Z commented on GitHub (May 13, 2025):
Some on-going work here: https://github.com/LGUG2Z/komorebi/tree/feature/nirily
I'm probably just going to do the initial heavy lift to get something basic working and then let people who want to add additional features on top of this submit patches if they are interested (similar to komorebi-bar)
Some thoughts that came out of my initial implementation:
@42willow commented on GitHub (May 15, 2025):
@LGUG2Z thanks for your work :)
No, in niri the monitors have entirely independent workspaces, the only way to transfer a window or a workspace to another monitor is to explicitly move it there. Might be important to also note that if a device is undocked from a monitor, the workspaces on that monitor are transferred to the main screen (i.e. laptop), and when it is docked that workspace that was originally on the monitor is transferred back. (although this is less related to infinite scrollable tiling and I don't know if komorebi already does this)
There shouldn't be gaps between windows horizontally (for example if you close window 2 out of 3 on the same workspace, 3 should move to the left to fill in the gap). In niri, there's this cool feature called "preset column widths", where you can resize columns (i.e. >=1 window stacked vertically) to presets (e.g 1/3, 1/2, 2/3).
In this screenshot, each row is a different workspace, which is infinitely scrollable left and right - only the middle section is shown.
i.e. this is shown on workspace 2
@rottakore commented on GitHub (May 15, 2025):
Maybe
whkdwill need to update to supportWheelDownandWheelUpto be used in the scrollable layout?AHKalready have this.AHKis detected as a cheat in some games, like THE FINALS and the BATTLEFIELD franchise, sowhkdsupportingWheelDownandWheelUpcan be massive for some people.@42willow commented on GitHub (May 16, 2025):
wheel down and wheel up are very convenient to have with scrollable twm's when you don't have both hands on the keyboard
@rottakore commented on GitHub (May 16, 2025):
Just adding this video from LGUG2Z Youtube channel here so people coming from Github can have more details on how this feature is going.
@LGUG2Z commented on GitHub (May 16, 2025):
I believe this will require changes in https://github.com/iholston/win-hotkeys - Feel free to reach out to the maintainer with a feature request; if it gets added in that library at some point, I can expose it in
whkd@rottakore commented on GitHub (May 16, 2025):
I created a feature request in the win-hotkeys repository.
@LGUG2Z commented on GitHub (May 17, 2025):
In the interests of shipping something a little quicker, I've updated the branch to only allow setting a workspace layout to Scrolling if a single monitor is connected, now that we know that with the current implementation windows end up bleeding onto adjacent monitors
This could be further refined to also allow multiple monitors if we can validate that there are no two horizontally adjacent monitors
@42willow commented on GitHub (May 17, 2025):
Which implementation? Windows don’t bleed into horizontally adjacent monitors in niri
Unless you are considering the viewport as a workspace (which scrolls horizontally to other workspaces) rather than workspaces vertically that scroll infinitely horizontally?
The first screenshot I sent illustrates how niri does it
@LGUG2Z commented on GitHub (May 17, 2025):
I think you're misunderstanding - I am talking about the implementation on the feature/nirily branch in this repo
I've made some updates tonight
komorebic scrolling-layout-columnscan be used to set the number of visible columns on the flylayout_optionshas been added which includeslayout_options.scrolling.columnsto set the same configuration declarativelyI think this is probably the limit of the work that I'm personally interested in doing on this feature - I think we can get it into the first nightly after v0.1.37 is released and then whoever is interested on iterating further can take it from there
@rottakore commented on GitHub (May 17, 2025):
@LGUG2Z, is it still possible to resize apps in the scrollable layout freely? Or it will always snap in the number you put in
komorebic scrolling-layout-columns? Orkomorebic scrolling-layout-columnsis optional?@LGUG2Z commented on GitHub (May 17, 2025):
I've been resizing apps with
komorebic resize-axisand also with AltSnap on this layout without any issues; based on this I'm surekomorebic resize-edgealso workskomorebic scrolling-layout-columnsdefaults to3- if you resize a column to be smaller, the adjacent column will grow to take the space it releases, and if you resize a column to be smaller, it will make the adjacent column release space to expand into - when you scroll the viewport these resize adjustments are maintained so you can also end up with a window resized to be larger not being completely within the viewport if it is on the extreme left or right visible column within the viewport@LGUG2Z commented on GitHub (May 18, 2025):
I have just cut a new
nightlyrelease with theScrollinglayout included - make sure to point the$schemakey inkomorebi.jsontohttps://raw.githubusercontent.com/LGUG2Z/komorebi/refs/heads/master/schema.jsonto pick up the new configuration options when trying this out.I've closed the issue since I won't be working on this anymore; if anyone wants to continue iterating on this and submit PRs we can continue any focused implementation-related discussion there.
@DaitiDay commented on GitHub (Dec 20, 2025):
Just a couple of questions about the video: how can I spawn the first window in the center of the screen? And how can I change the size of the columns like it is shown in the video?