💾 Archived View for gemini.dimakrasner.com › snail-layout.gmi captured on 2023-01-29 at 15:27:37. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-07-16)
-=-=-=-=-=-=-
It started as a thought experiment, but I'm slowly translating it into C.
https://github.com/djpohly/dwl/compare/main...dimkr:dwl:snail
I want a tiling layout for dwl that can do this:
┌───────────────┬────────────────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └───────────────┴────────────────┘
┌───────────────┬────────────────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ ├───────┬────────┤ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └───────────────┴───────┴────────┘
┌───────────────┬────────────────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ ├───────┬────────┤ │ │ │ │ │ ├───────┤ │ │ │ │ │ │ │ │ │ └───────────────┴───────┴────────┘
┌───────────────┬────────────────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ ├───┬───┬────────┤ │ │ │ │ │ │ ├───┴───┤ │ │ │ │ │ │ │ │ │ └───────────────┴───────┴────────┘
dwl, like dwm, has a "fibonacci" patch that does this. Most of the time, I can use this layout, and it works much better than the normal tiling layout. I like old laptops, and these have 1366x768, 16:9 displays. They're terrible if the windows are split horizontally.
However, at work, I have a 2021 Dell XPS 13 with a high resolution 16:10 display. Soon, after the renovation is over and we finally move to our apartment, I'm going to build a nice home office with a 21:9 or 4K 16:9 display. Therefore, I need something that works well on many kinds of displays and adapts well to my needs.
Also, I want something more flexible, because sometimes I want two big windows instead of just one. One big window is nice for university stuff, most of the time, but for work, sometimes I need to fit 3 or more windows with documentation, side-by-side.
Sometimes, I want a "non-standard" layout, like this:
┌───────────────┬────────────────┐ │ │ │ │ │ │ │ │ │ │ │ │ ├───────────────┼───┬───┬────────┤ │ │ │ │ │ │ ├───┴───┤ │ │ │ │ │ │ │ │ │ └───────────────┴───────┴────────┘
And, if the resolution is high enough, I want to be able to do this:
┌──────────┬──────────┬──────────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ├──┬──┬────┤ │ │ │ │ │ │ │ │ ├──┴──┤ │ │ │ │ │ │ │ │ │ │ │ └──────────┴──────────┴─────┴────┘
Or, if the resolution is low, maybe this would be better:
┌───────────────┬────────────────┐ │ │ │ │ │ │ │ │ │ │ │ │ ├───┬───┬───────┼───┬───┬────────┤ │ │ │ │ │ │ │ ├───┴───┤ ├───┴───┤ │ │ │ │ │ │ │ │ │ │ │ └───────┴───────┴───────┴────────┘
And maybe, this would work on a low resolution display, too:
┌──────────┬──────────┬──────────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ├──────────┤ ├────┬─────┤ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └──────────┴──────────┴────┴─────┘
I want flexibility, but without having to split windows all the time. I really like ratpoison, but sometimes I just want something to tile the windows for me. I prefer ratpoison to many tiling window managers because their tiling algorithm does the right thing 60% of the time, and I have to fight them in the remaining 40%. I prefer to do that work manually without the window manager getting in my way.
The "snail" layout I'm working is an attempt to improve on the "spiral" and "dwindle" layouts from the fibonacci patch:
https://github.com/djpohly/dwl/compare/main...917Wolf:fib.patch
This new "snail" layout is designed (time will tell if it's a successful design) to scale better and cover the cases where the "tile" layout works better, in one or two keystrokes. It's not perfect, but I think this algorithm does the right thing for my workflows, at least 80% of the time, with zero configuration.
The display is divided into two areas: the master area and the stack area. By default, the master area is about 50% of the display, and contains only one window. All other windows go to the stack. (This is regular dwm/dwl stuff.)
┌───────────────┬────────────────┐ │ │ │ │ │ │ │ │ │ │ master │ stack │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └───────────────┴────────────────┘
Both areas follow the same logic, with a slight difference: the master area is productivity-oriented while the stack is all about space efficiency.
Every time a window is placed in one of these areas, the last window in this area is split, either horizontally or vertically (in right->down->left->up motion), to make room for the new window.
If the master area is wide enough to fit *two* wide windows side-by-side, the first window gets split horizontally and the second window is placed to its right. Then, we do the same check again, and if we have enough space for three or four wide windows, so be it. When we don't have enough space for a wide window, we go down->left->up->right. If the display is wide (for example, a 21:9 display) or the master area is very big (for example, 2/3 of the display), this makes it easier to work with two application side-by-side while everything else is packed nicely in the stack.
The stack follows the same logic, but the first split is horizontal if the *first* window is wide. This makes the stack more space-efficient.
By changing the number of windows in the master area and the master area width, it's easy to achieve many "non-standard" layouts, and the algorithm does the right thing, given the monitor width and master area shape. For example, to achieve this layout, shrink the master layout to 1/3 of the display width and 1 window:
┌──────────┬──────────┬──────────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ master │ stack┬──┬────┤ │ │ │ │ │ │ │ │ ├──┴──┤ │ │ │ │ │ │ │ │ │ │ │ └──────────┴──────────┴─────┴────┘
The windows are arranged like this because now the stack area is wide and not tall, so the first window is split horizontally.
To achieve this layout with 4 open windows, keep the 50% width of the master area, but add one window to the master area:
┌───────────────┬────────────────┐ │ │ │ │ │ │ │ │ │ │ │ │ ├───────────────┼────────────────┤ │ │ │ │ │ │ │ │ │ │ │ │ └───────────────┴────────────────┘
When a window is added to the stack, it looks like this:
┌───────────────┬────────────────┐ │ │ │ │ │ │ │ │ │ │ │ │ ├───────────────┼───────┬────────┤ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └───────────────┴───────┴────────┘
And, if the master area size is increased to 3 windows, the first window in the stack moves to the master area:
┌───────────────┬────────────────┐ │ │ │ │ │ │ │ │ │ │ │ │ ├───────┬───────┼────────────────┤ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └───────┴───────┴────────────────┘
I want to spend at least two weeks with this layout, to see how it works for me. The main advantage of the "fibonacci" layouts is simplicity: you know what's going to happen on every keystroke. It's definitely flexible and the default behavior seems pretty sane, but I'm not sure if the "snail" layout is intuitive enough and doesn't get in the way of the user, because the choice it makes when you change something (like the master area width) is based on multiple factors: maybe it's "too smart", to the point it's unpredictable.