Bspwm: Consider dropping the default automatic mode

[Ploppz]

The default "fibonacci" behaviour when creating windows, I cannot see how it is useful in any sense. It served only as an inconvenience to me, and now that I finally got around to change it, I am relieved. This is of course my opinion, but I think for attracting new users (and making them stay) it would be beneficial to provide a better automatic mode. I find this one very convenient: split in the current window, along the greatest dimension.

[baskerville]

I won't mind dropping it: I don't remember it being praised by anyone.

@msteen: any thoughts?

[HaoZeke]

If it's an opinion thing, I rather enjoy the current default behavior...

[Pilen]

One thing to note is how easily it is to customize for the user.
For example, the script @Ploppz mentions is fairly small, how complex would it be to recreate the current behaviour as a script if defaults change?

Honestly I dont know if the current setup is good or bad, but i do know that the documentation for changing it is rather lacking.
You need to know that there is a thing called "external_rules" to even understand that you can change it. Currently the only documentation is the following small section in the man page:

External command used to retrieve rule consequences. The command will receive the following arguments: window ID, class name, instance name, and intermediate consequences. The output of that command must have the following format: key1=value1 key2=value2 ... (the valid key/value pairs are given in the description of the rule command).

Yes there is an example, but you need to know what an external_rule is to find it, then you need to figure out what pseudo_automatic_mode means and how to utilize the file external_rules within it.
There is no description of how this example is used or what it is supposed to do. Beginners might therefor not see it, and probably wont notice that the way bspwm manages windows can be changed.

I think it would be beneficial if the Readme stated how and what could be customized in bspwm, and if the examples documented what they changed and how they did it.

[Ploppz]

Yes it would be great if the docs said more about how to configure it.
Still I would argue that first impression is important.

Regarding whether it's an opinion thing: I suppose. I can elaborate what I don't like about it:

• Adding a window has an almost global effect on the layout in a desktop. The layout you currently have is suddenly drastically changed, so it's hard to build up a layout in a controlled way. (I never got the hang of it anyway). And I find the resulting relocation of windows sometimes erratic.
• Automatic mode splits windows that are already the smallest, which more often than not, is not what I want. It seems that no matter what window is focused, it will always split one of the smallest windows (or that is, deepest in the tree) on the desktop.

It's a good point that maybe it's not that easy to achieve this with an external_rules though.

[msteen]

@baskerville Personally I would not mind if the automatic mode changed to something else, but I think care should be taken not to lose some of the existing users only to potentially attract more new users, since some of the existing users might rely heavily on the current behavior and would not like to see it changed.

The automatic mode has always used the Fibonacci layout, as far as I know, so I would recommend keeping it that way, but I definitely would love to see the option to choose a different layout for automatic mode.

To support different layouts for automatic mode the obvious solution would be to just include them in bspwm and have a config option that allows you select the one you like. However I do not like that approach, because that would mean @baskerville would have to implement them, or they need to be contributed, which is unlikely to happen if you look at the amount of contributions to the current code base. So that approach would likely result in a few obvious layouts, which you can almost guarantee will not cover most of the specific behaviors people have in mind.

So instead I would like to see the capability to define your own layout scheme for automatic mode. You already can do this, sort of, with external_rules, but as mentioned by @Pilen and @Ploppz, external_rules is not a good fit for this, since it is an entirely different use case if you ask me. Instead it probably would be better to have a separate way to define layout schemes, which would give you the complete state of the relevant desktop, so you have the necessary data to make the decision where the new node should be placed. This state could be in the form of JSON, but if that would cause too much overhead, maybe something like Cap'n Proto might be a good alternative considering the following two features:

Inter-language communication: Calling C++ code from, say, Java or Python tends to be painful or slow. With Cap’n Proto, the two languages can easily operate on the same in-memory data structure.

Inter-process communication: Multiple processes running on the same machine can share a Cap’n Proto message via shared memory. No need to pipe data through the kernel. Calling another process can be just as fast and easy as calling another thread.

In summary my preferred solution to this question would be:

• Keep the current Fibonacci layout scheme.
• Have an option to change the default layout scheme.
• Allow setting the layout scheme per desktop.
• Beside the built-in layout schemes (at least Fibonacci should be build-in), allow externally defined layout schemes by providing enough information.
• Clearly document the above so it should be clear to new users that changing the layout scheme is possible and that the Fibonacci scheme is just the default.

[eyvindbjartiandersen]

I would like a layout or a restriction to limit the nodes to a grid of maximum 4. New nodes would then populate next desktop. The spawn order is less important. If you're using a tiled mode I can't see much use for minuscule nodes. Could anyone help me define some external rules for this?.

[msteen]

@eyvindbjartiandersen I do not have the time to write it for you, but I could sketch a way for you to implement it yourself.

First I would use a programming language you are comfortable in that has good enough JSON support. The external_rules program does not have to be a shell script.

Then I would check if the currently focused desktop has less than 4 windows with bspc query --nodes --desktop or else whether it has a preselection available bspc query --nodes --node '.!automatic'. If neither is the case, you would have to focus the next desktop bspc desktop --focus next and repeat the checks. Be careful to keep track of the desktops you have already checked, because you want to prevent an infinite loop. If none of the desktop match the conditions, you could choose to create a new desktop bspc monitor --add-desktops <desktop_name>.

If you ended up with finding a desktop that had a preselection available you are done, the window will be placed there. And if you found or created a desktop with less than 4 windows, you will have to decide where the next window should be placed. I think the best behavior would be to just take the biggest window and split that, that should result in a grid, and is probably still you want if you made some customization with preselections. In order to decide the biggest window, I found that bspc --query --nodes --desktop --node biggest did not work the way I expected it to (I expect a cascading filtering, but biggest always works on the total set of windows), so you would have to implement this yourself, which you can do using bspc query --tree --deskop to get the JSON data for the currently focused desktop and then you can traverse the JSON to get out a list of the nodes that have a client. Filter out the biggest window and split depending on which side is the largest as in this script.

[eyvindbjartiandersen]

Thank you for the explanation. When running bspc query --nodes --desktop I get unexpected results. I get more node IDS than visible nodes. Often just one more. How is it supposed to work?.

[msteen]

@eyvindbjartiandersen Maybe try bspc query --nodes --desktop --node .window instead?

[!]window
    Only consider nodes that hold or don’t hold a window.

[eyvindbjartiandersen]

Thank you again. This simply works. I'm trying to make my layout work with a case statement.

[eyvindbjartiandersen]

I've come with a rough draft.

!/bin/bash

node_number=$(bspc query --nodes --desktop --node .window | wc -l)

case $node_number in
    1) split_dir=east;;
    2) split_dir=south;;
    3) bspc node -f biggest.local && echo split_dir=south;;
    4) bspc desktop -f next;;
esac

[ghost]

While would be nice and useful to have some different layouts by default (like Awesome WM) what really bother me (sometimes) is the way the new windows are placed.

New windows are placed in the beginning of the tree, and then the windows previously opened are pushed to inside the tree.

IMHO, that would make a lot more sense if the new windows were placed at the end of the tree by default.

I managed archive this behavior using bspc rule -a '*:*' private=on but I could not use that in practice due to some programs not liking that (I do not know why) like Neomutt.

Thanks!

[alecive]

@baskerville what about having a couple different behaviors that can be handled through an option in the config file? I also don't like the default behavior to be honest (but I have never had time to change it).

I can see at least two variations :

• one that puts the fourth window in a 2x2 grid
• one that puts the third window side by side with the other two horizontally | 1 | 2 | 3 | (which can be very useful with ultra-wide monitors)

Having that as an option would be great for new users!

[baskerville]

I just realized that since the external rules are executed in parallel, even the simple example given in examples/external_rules/pseudo_automatic_mode can fail depending on how fast the windows are spawned.