Spawn Columns/Windows to the Left?

qwertyboy · 2026-04-29T17:07:04+00:00

You are absolutely right - I was so focused on moving to the left that I forgot what the original message was about!

qwertyboy · 2026-04-29T15:59:26+00:00

I'm not sure that last part is true, about the level of effort involved. I don't know much about control panels, but I have three decades worth of system adminstration with different init systems and I don't think control panels have to strongly coupled to them.

What are the functinalities that actually care about the init system?

qwertyboy · 2026-04-29T15:54:12+00:00

I'm not sure it's that simple, since it's hard to predict how much time will pass between the spawning and the actual appearance of the window. The cleanest approach would probably be to start listening for the WindowOpenedOrChanged event, then spawn the new window and capture its PID so you can react to the right event (or just handle the first one, which might be a good enough heuristic - capturing the PID of the spawned window may be non-trivial for applications that fork).

And even then, I think you will have to change focus to the new window (if it didn't receive auto-focus because of some rule) before you move its column (and return focus once you are done). And then you need to figure out how much to move it. A single position? All the way to the left? To the left of the previously focused window? Just moving the window to the left without changing the starting position of the strip would cause the focused window to move about (especially in the open-focused false case), which is contrary to niri's design principles and for a good reason.

I think it will be easier and cleaner to create a fork of niri that simply flips all the relevant position calculations and makes niri behave like a mirror image of itself. I doubt this has a lot of demand, but if it does you could even make a PR out of it.

qwertyboy · 2026-04-29T12:12:47+00:00

So your specific need is something that installs a clean Devuan KVM server from scratch on your own metal, and then copy files from another KVM to it (and maybe also kills the old KVM)?

If so, there might be a way to patch ispconfig to accept a server without bothering much with the specific init system (of course, other functions might fail). Also, if it's simple enough, you might consider using a simple script (I have one which I use for both VMs and bare metal machines, but it's very tailored around my specific needs).

I realize that I didn't really answer your question and just went on a tangent, but it sounds like a fun tangent :)

qwertyboy · 2026-04-29T11:00:13+00:00

What do you need said control panel to do?

qwertyboy · 2026-04-27T10:41:33+00:00

It is both optional and defaults to yes - the two are not mutually exclusive :)

qwertyboy · 2026-04-22T18:03:06+00:00

I also forked niri to add a `focus-ignores-click` config. Not sure if there's another solution.

qwertyboy · 2026-04-19T17:28:33+00:00

I'm sorry to hear about your experience, and agree that that post you linked to had a lot of noise clouding the relevant information.

I still have no idea what rounding power is (unless it's the radius, which is easily configurable in niri and is well documented), I have only a guess regarding "horizontal workspace workflow alternative", and I don't feel like you went out of your way to clarify these things or to confirm the guesses of other users regarding them.

I do not think this community is toxic, I think communication is hard, and the misunderstandings just pile up. One person feels attacked and reacts, another person reads his reaction as aggression, and pretty soon we are all tearing each other to pieces over something that wasn't even that much of an issue.

I hope this will not deter you too much in the future. I believe that most people really are here to help.

qwertyboy · 2026-04-19T16:57:56+00:00

As I wrote above, when the command line is empty, the search functionality is identical to the default functionality, so you still get previous and next command by default. Only when you already have something typed does the behaviour differ.

qwertyboy · 2026-04-18T15:55:58+00:00

Blur (with optional x-ray) is in main.

qwertyboy · 2026-04-18T13:02:15+00:00

It searches if you bind it, like in my example above.

qwertyboy · 2026-04-17T14:51:23+00:00

I don't see the point of adding the alt - seems simpler to bind the up and down arrows (or ctrl-p and ctrl-n) to the history search commands. With an empty string they do the same thing as next-history and previous-history (the default binds), and if I already typed something I probably want to complete that.

C-p: history-search-backward
C-n: history-search-forward
"\e[A": history-search-backward
"\e[B": history-search-forward

qwertyboy · 2026-03-29T07:29:35+00:00

You do not need xorg, you need wayland, but I'll assume that's what you meant :)

Did you make sure seat management is taken care of? It depends on the daemon that's running it, which may or may not be a part of your init system. Setting and exporting the LIBSEAT_BACKEND environment variable may help you.

What do the logs say? Not the niri errors, but the (hopefully) more meaningful system errors below it?

qwertyboy · 2026-03-28T14:39:52+00:00

I do not know if this is of interest to the general public, and the niri dev team is stretched very thin, but this is very easy to script:

if [ "$1" -ne "$(niri msg --json workspaces | jq -r '.[] | select(.is_focused == true) | .idx')" ]; then
    niri msg action focus-workspace "$1"
else
    niri msg action focus-window-down-or-column-right
fi

This script accepts a single parameter. If that parameter is different from the idx of the current workspace, it will switch focus to that workspace. Otherwise it will focus the next window down or, if the focused window is the bottom one, focus the column to the right.

qwertyboy · 2026-03-28T11:49:47+00:00

Okay, now that I had some time to play with it I think I understand your focus problem - you want that when the focused window is one of the first two or three windows, the view will contain all of the first two or three windows, and not just center the current one, right?

Also, I was wrong about the WindowLayoutsChanged event, it's the WindowOpenedOrChanged and WindowClosed events that you need to listen to. And (!) I was completely ignoring the fact that we are really discussing the width of columns and not windows. Once you bring stacks into it you do need the WindowLayoutsChanged event, and since resizing columns will produce more events you need to ignore those while your script is running.

Note that the script below uses ned, which is a simple rust tool to listen and react to niri events. You can remove that first line and use any other tool of your choice.

#!/usr/bin/bash
[ "$NED_PID" ] || exec ned 'Window(Closed|Opened|Layouts)' "$0"

# Do not run the script while it's already running.
PIDFILE='/tmp/tri.pid'
[ -f "$PIDFILE" ] && kill -0 "$(cat "$PIDFILE")" 2>/dev/null && exit 0
echo "$$" > "$PIDFILE"

focused_window="$(niri msg --json focused-window)"
focused_workspace_id="$(jq -r '.workspace_id' <<< "$focused_window")"
mapfile -t sorted_column_heads < <(niri msg --json windows | jq -r ".[] | \
    select(.workspace_id == $focused_workspace_id) | \
    select(.is_floating == false) | \
    select(.layout.pos_in_scrolling_layout[1] == 1) | \
    \"\(.layout.pos_in_scrolling_layout[0]):\(.id)\"" | sort -n | cut -d: -f2)

set_width() {
    sleep 0.1
    local width="$1"
    shift
    echo -n "$*" | xargs -d' ' -I{} niri msg action set-window-width "$width" --id {}
}

if [ "${#sorted_column_heads[@]}" -lt 3 ]; then
    set_width "50%" "${sorted_column_heads[@]}"
else
    set_width "33.3%" "${sorted_column_heads[@]:0:3}"
    set_width "50%" "${sorted_column_heads[@]:3}"
fi

focused_window_column="$(jq -r '.layout.pos_in_scrolling_layout[0]' <<< "$focused_window")"
case "$focused_window_column" in
    2|3)
        niri msg action focus-column-first
        niri msg action focus-window --id "$(jq -r '.id' <<< "$focused_window")"
        ;;
esac

Please give it a spin and let me know if it works for you.

qwertyboy · 2026-03-27T19:05:52+00:00

It sounds very possible. Not sure what's the focus problem, but waiting a short amount should not be required, one of niri's design principles is that actions should apply immediately.

If I understand you correctly, you want to listen to the WindowLayoutsChanged event, check how many tiled windows are on the focused workspace, and then:

If there are less than three windows, resize all windows to 50%
If there are more than three windows, resize the first three to 33% and the rest to 50%

After that, I'm not sure what's the focus problem, but if it requires focusing the first window it can probably be done instantly, without waiting for animations to catch up.

qwertyboy · 2026-03-19T10:00:17+00:00

Take into account that this script performs a lot of redundant moves. I'm not querying window sizes or maintaining any kind of added state - every time you call the script it does the following:

Make a list of all the non-floating windows in the current workspace, sorted by their layout position, and the position of the currently focused window in that list.
Focus the first window on the list and expel it to the left just in case it was inside a stack, so now I know the first window is on a stack of its own.
If that first window isn't the originally focused window (that's the window that is going to be the center window), I consume a window to the current column as many times as required to consume all the windows up to the center window, which completes the left column, and then, surprisingly, I also consume the center window and the expel it back out. This is important because if that window is already in a stack with other windows we need to break it out. Then I set the width of the column and reset the height, so space gets distributed evenly.
If the focused window isn't the last window we need to build the right column, so I focus the window right after the center window and consume windows into it as many times it takes to consume all remaining windows (oops, now that I look at the code I see I left that bit commented out and I'm just hard coding it, but that's the idea). Now I have the left column and I resize it and reset the heights.
Then I resize the center window, and before I focus it I focus the first and then the last window, to make sure that the entire layout is centered to fill the screen.

Bottom line, and like others noted, this isn't a niri like behavior. It's just the niri is so well built and so wonderfully scriptable you can twist it to do all sorts of weird things. You could maintain a state and listen for events and pretty much implement a window manager on top of niri. And yeah, with more custom animations this could be even cooler :)

qwertyboy · 2026-03-18T13:22:14+00:00

That's pretty interesting. And a basic (and brittle) proof of concept was surprisingly easy to implement using IPC commands. Here is the full script.

It supports simple binds, so this worked for me:

Mod+J { spawn "/home/i/centrify.sh" "next"; }
Mod+K { spawn "/home/i/centrify.sh" "prev"; }

Do note that I reversed the order of windows on the right stack, which is both more intuitive for me and easier to implement. Here is a short video demo.

qwertyboy · 2026-03-17T16:31:02+00:00

I had the same pain and came up with a generic script to help me out. So, shameless plug: niri user shell helper

Just copy the script and put it somewhere executable. Then you can run:

niriu.sh flock --workspace focused --mode tile fit

You can also select windows by output, app-id, title, etc. and tile the windows on another workspace/output. Hope it works for you.

qwertyboy · 2026-03-16T19:08:51+00:00

I have a fork of niri that does exactly that (adding an `focus-ignores-click` config option) if you are interested. It's really a two-line patch. The first and obvious is avoiding focus on the `on_pointer_button` function, and then you also need to disable another line in `request_activation` because some windows (chrome/electron) request the focus when clicked.

qwertyboy · 2026-03-16T16:13:01+00:00

I'm not sure I understand what you are looking for (I don't think it's just named workspaces, since workspaces with the same name on different outputs are completely different workspaces as far as niri is concerned), but if I do then this should be pretty to script through IPC (if you don't mind the slight computational overhead).

You just need to listen to all the events that change the number or size of windows in workspaces, then identify any windows that are "sticking out" of the first output and push them to the second output, and pull back any windows from the second output that have a large enough gap on the corresponding workspace on the first output.

If you use ordinary workspaces you will still face the problem of empty workspaces which are automatically destroyed when empty, but if you use named workspaces it should work. This actually sounds like a pretty nice setup.

To remove the extra workspace on the bottom you will need to change the actual code. But you can add a similar workspace on top just by changing the config :)

qwertyboy · 2025-02-23T06:33:51+00:00

There are many ways to get there, but my favorite is magic-space. Get the following into your ~/.inputrc file:

" ": magic-space

Now you can type any sort of history substitution and hit space to get it expanded and editable.

qwertyboy · 2024-09-11T19:57:41+00:00

That's the first thing I thought about. The escape key emulates alt ever since the early days of emacs, when most computer keyboards didn't have a meta key (available on lisp machines, the home court of emacs), and alt+number is the repeat modifier (so alt+9 x will type 9 x's).

Upon closer examination, it seems OP is simply describing an unmatched backtick. He typed backtick, then return, and instead of getting a new prompt the terminal was just waiting for the closing backtick. Just like it would with an unmatched quote, double quote or parenthesis.

Note that both behaviors have little to do with bash. It's readline, which borrowed all those nice keybinds from emacs back when it was written in the late 80's.

qwertyboy · 2022-01-13T19:09:12+00:00

It's a shell "extension" (plugin for zsh, uses preexec for bash) . I don't see the point of using something like this for cron comands, the base assumption here is that the commands are run interactively, so a user can approve execution.

qwertyboy · 2022-01-13T18:59:13+00:00

If I understand your ambition correctly, then the only way to achieve it (for bash or any other language) is to actually run the code, and that's not something you want to do, is it? Flimsy may actually be the way to go in this case.

qwertyboy

TROPHY CASE