11–20 of 33 posts
I’m curious: after about four things the windows seem to start getting really small. Does anyone really find much use in a window manager that can subdivide infinitely?
This is single handedly the greatest increaser of my productivity.
A great aspect of bspwm is that it is relatively unopinionated about how it is configured and controlled. You can easily invoke bspc from any language of your choosing. No need to be limited by an inexpressive configuration file. No need to write the configuration in one specific language that the developer favoured. Another feature I appreciate is that it does not bind any keys. It is left up to the user to implemen…
An example I've implemented for myself: When opening a single app in an empty workspace, by default bspwm stretches the window to fit the whole screen (as usual with tiling window managers). On big monitors, this can be pretty annoying (e.g. staring at the very upper left corner of your 32" monitor when using a terminal). Using bspc, I can listen to when new windows are added, inspect bspwm's state to see if the new window is in a workspace on its own, and then use bspc to adjust the margins on the workspace to make the window a more comfortable size in the center of the screen. Even in Python I can do this in ~100ms.
Isn't this what XMonad also does with their Zipper?
In my experience XMonad typically can do anything any other tiling WM can do, but the high barrier of needing to know Haskell before being able to do the most basic of configuration keeps most people from finding that out. Oh, and it wasn’t stable for me. That might be related to the prior comment, since I really don’t know Haskell at all.
Later I switched to i3 but kept using Haskell.
Even later, I mostly use Macs with a smattering of Debian with vanilla GNOME, so no Xmonad or any other tiling window manager. Still use Haskell.
It's similar to bspwm.
- Both are controlled over a socket by a client program. Anything you can do to windows with a mouse or keyboard you can do with a script, and vice versa.
- The configuration for both is an rc file that's executed.
- Both are dynamic tiling managers, with a binary tree of containers.
- Both compare well to i3 by limiting the container tree to a binary tree, and eliminating keybindings to change container focus or move containers.
For examples of various window managers and accessories https://www.reddit.com/r/unixporn/
I never understood why its a big deal that windows are leaves of a binary tree? Its that good? Not trying to be snarky, just curious.
I recommend https://herbstluftwm.org/ It's similar to bspwm. - Both are controlled over a socket by a client program. Anything you can do to windows with a mouse or keyboard you can do with a script, and vice versa. - The configuration for both is an rc file that's executed. - Both are dynamic tiling managers, with a binary tree of containers. - Both compare well to i3 by limiting the container tree to a binary tree,…
I never understood why its a big deal that windows are leaves of a binary tree? Its that good? Not trying to be snarky, just curious.
Same here. What's problem does this solve? Or, is this just a neat proof-of-concept project? This isn't a loaded question, I'm genuinely curious.
Focus will still follow your mouse I believe.
The binary tree concept just is a way of sorting the windows such that the rotation is predictable regardless of tiling layout.
I recommend https://herbstluftwm.org/ It's similar to bspwm. - Both are controlled over a socket by a client program. Anything you can do to windows with a mouse or keyboard you can do with a script, and vice versa. - The configuration for both is an rc file that's executed. - Both are dynamic tiling managers, with a binary tree of containers. - Both compare well to i3 by limiting the container tree to a binary tree,…