baskerville / bspwm

A tiling window manager based on binary space partitioning
BSD 2-Clause "Simplified" License
7.79k stars 414 forks source link

Orphaned Nodes From Desktop Closure Are Broken #1243

Open p0da opened 3 years ago

p0da commented 3 years ago

When removing a desktop containing any number of nodes those orphaned nodes are sent to the next available desktop where they unable to take keyboard input and appear on top of any other nodes. They remain in this state until they are forcibly killed. Additionally this issue seems to require that a sticky node be present at the time of the deletion.

ortango commented 3 years ago

is there more to this issue?

as described it is not reproducible for me.

p0da commented 3 years ago

Ill do some more testing to see if I can reproduce on other machines, but doing something like: bspc monitor --add-desktops A; bspc desktop --focus next; alacritty; bspc desktop --remove

with only one initial desktop would result in alacritty being rendered in the aforementioned "broken" status on the remaining desktop until it is forcible killed.

emanuele6 commented 3 years ago

Wow, that is very annoying; it will also unmanage your sticky windows.

Correcting your reproduction steps a bit

bspc monitor --add-desktops A
bspc desktop A --focus
alacritty &
bspc desktop A --focus --remove
emanuele6 commented 3 years ago

@Rayqan By the way, note that you can use xqp to get the id of the windows that got unmanaged (you need to hover the cursor above before running it); and then you can the hide and show subcommands of xdo to make bspwm remanage the window that got unmanaged.

Sxhkd hotkey to fix unmanaged windows by clicking on them (you can use this as a temporary fix until this gets fixed if some of your important windows get unmanaged and you want to avoid closing them):

# Manage the window under the pointer if it is not managed
~button1
    id=$(xqp); \
    bspc query -N -n "$id" && exit; \
    xdo hide "$id" && xdo show "$id" \
        && notify-send "managed $id"

EDIT: maybe bind it to something other than ~button1 (e.g. super + n); I just noticed that this will trigger also if you click on, for example, polybar and you probably want to avoid that. (polybar would still work; it just makes it blink when you click on it which may be annoying.)

# Unmap and re-map the window under the pointer
super + n
    id=$(xqp); \
    xdo hide "$id" \
        && xdo show "$id"
p0da commented 3 years ago

Thanks, I also seem to be able to reproduce the behavior on multiple machines.

ortango commented 3 years ago

Wow, that is very annoying; it will also unmanage your sticky windows.

Thanks, I also seem to be able to reproduce the behavior on multiple machines.

just to confirm, for this issue to present it requires a sticky window?

(as a side note: there are a few commands that don't work correctly with sticky windows present)

emanuele6 commented 3 years ago

Oh, it looks like it does require the presence of a sticky window to occur. I happened to have a sticky window when I tried to reproduce this bug and I didn't test without.

ortango commented 3 years ago

@Rayqan i think the issue would benefit from adding something about the sticky node requirement to the original description.