-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add depth limit as argument for how often to autotile #41
Conversation
Currently the script will autotile (vsplit/hsplit) every window focused on with no limit. At a certain depth this behaviour is not desirably to me and I want to add more windows to the same container. Especially for terminals I prefer to have more space horizontally than vertically to see the entire line if possible. To achieve this, I add a optional parameter to prevent further autotiling after the specified limit. For example with a 16:9 display and a depth limit of 1, it will split horizontally first and then only split vertically but in the same container. ``` ________________ | | | |--------| | | |-------| |--------| | |________|_______| ``` As a side effect, this enables stacking and tabbed layouts after reaching the limit. The default behavior is still the same with an infinite limit for how deep to autotile.
Well, I'm not sure. Need to give it a try and use for some time. |
I don't care about i3 in the |
Gaming keeps me on X11 for now. ;) Apparently the containers not being flattened is an i3 bug: i3/i3#3503 How does sway handle the nested containers? Do they get merged/flattened? |
I only have one game installed (Witcher 2), but it behaves perfectly well on sway.
Wish I knew. ;) |
You could try this #41 (comment) and then run |
|
You did not close all the upper terminals but yes, looks like sway does not flatten the hierarchy as well. Otherwise there would be no containers with only one other container in it:
|
Tried on HDMI-A-1.
|
You mean this situation, right (HDMI-A-1)?
Too bad! I like the behavior at the depth limit 1. |
With lots of splits the hierarchy can get deeper than normal, if containers get closed. i3 does not flatten this hierarchy (atm). This means that the depth option does needs to ignore containers that only contain one child/node. This is done only incrementing the current depth when checking against the limit if the nodes of the parent container is bigger than 1.
So I think I fixed it by ignoring containers with only one child container in them and disregard them as depth. Depth changed a bit:
|
Correct me if I'm wrong.
Right? If so, shouldn't we just have a boolean flag, e.g. |
Nope, I totally agree. Unless your aspect ratio is different maybe. I tried flipping my 16:9 monitor to vertical and there 3 might make sense – not to me though. We could provide both options and imply Do you use a master/stack layout on sway? If yes, is a sway feature or do you use scripts/tooling? I thought about making a script to swap containers in a certain way but that is out of the scope of this repo. |
Nope, but I liked it on DWL. In contrary to DWL itself. 🤣 I do believe in the KISS rule. Let's not multiply arguments that do the same job. If you find the current Whoever uses the original autotiling script, will decide on their own. |
My worry with So I'd say |
OK. Could you also update README.md? I'm working on a small fix to another repo at the moment. |
Absolutely, I'll get to it tomorrow.
|
Thanks! Hope you'll give sway & nwg-shell a chance one day. The project needs valuable contributors. |
The help and README did not go into details what exactly the --limit option does. Since it can be used to imitate a master-stack layout, and can enable tabbed or stacking layouts to some degree, this adds the explanation in the section talking about this limitation. It softens the limitations of autotiling while still stressing that tabbed and stacked layouts may behave unexpectedly and are not supported by autotiling.
Thank you! I'll merge later tonight. |
This genuinely makes me interested in giving Wayland a go, but if I remember correctly the problem with Wayland was nvidia drivers (bought while my daily driver was still Windows). |
No rush, I rephrased the section about not working with tabbed/stacked quite a bit. Please nitpick away. |
Dunno what the nvidia status nowadays is. My hardware is all-AMD. |
Pretty happy with my Ryzen 7 from a few years back. My next GPU will be red (or blue – one can hope). But currently not in need of a better one, (un)fortunately. But I am looking forward to a new one. Just a quick Google for the state of things in 2022:
They did not even try to game on it and it failed the test. |
Actually my previous laptop, back in 2015-2020, was an Intel/Nvidia hybrid, and sway worked well on it. The best test is what you check yourself. |
I think the easiest might be to add |
Haha! If I managed to integrate swaync and gtklock, this is going to be be an easy task. ;) |
Well, I've just realized that the version I use in nwg-shell allows a single instance only. :/ |
For my specific use case it's possible to store the |
Would there be use for something like: limit of 3 on output x with workspace 1 3 5, but limit of 3 on output y with any workspace. It would split the arguments in two groups: one for filtering (output, workspace, maybe more) and one for attributes (limit, ratio, etc.). This would add complexity which I am not a fan of. You can already do all this by running multiple commands. |
I know. But if it was possible through arguments you could use the @ symbol. Off topic: |
Well, I use PyCharm, so it will reformat it back on my next Ctrl+Alt+L. |
Black runs on save in my vscode 😅 Mainly check out the logic rewrites |
Looks good while reading. Needs to be tested carefully, anyway. If it comes to formatting: I'm strongly against reformatting def switch_splitting(i3, e, debug, outputs, workspaces, depth_limit): to def switch_splitting(
i3, e, debug, outputs, workspaces, depth_limit, splitwidth, splitheight, splitratio
): It's 1 line -> 3 lines. The more code I see w/o scrolling - the better. |
Ignore the formatting. It is done by black which is quite opinionated. The only reason it got touched is the line length. Again, Ignore the formatting. I just didn't turn it off for this. I'll wait for the open PR to be done. If you like the sieve/gate structure, I can open I PR for the logic changes and migrate them one by one to make it obvious that the behavior is still the same. |
Yes, please. There's still a thing I'd like to be considered there. |
Not sure if this is strictly related, but on ultrawide screens, tiles go three across before tiling correctly |
This behaves as expected and what is also reported by #29. There is an open PR #44 that will allow you to set the ratio when it will split. |
Thank you! |
Currently the script will autotile (vsplit/hsplit) every window focused on with no limit.
At a certain depth this behaviour is not desirably to me and I want to add more windows to the same container. Especially for terminals I prefer to have more space horizontally than vertically to see the entire line if possible.
To achieve this, I add a optional parameter to prevent further autotiling after the specified limit. For example with a 16:9 display and a depth limit of 1, it will split horizontally first and then only split vertically but in the same container.
As a side effect, this enables stacking and tabbed layouts after reaching the limit.
The default behavior is still the same with an infinite limit for how deep to autotile.
Edit: I mainly made this for me. Not sure if you are interested in this.