Open p0da opened 3 years ago
is there more to this issue?
as described it is not reproducible for me.
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.
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
@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"
Thanks, I also seem to be able to reproduce the behavior on multiple machines.
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)
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.
@Rayqan i think the issue would benefit from adding something about the sticky node requirement to the original description.
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.