ortango

anecdotally, i have never had this happen and use qutebrowser frequently. possibly a graphics driver issue?

an unmanaged window that gains focus will cause this behavior (no window will regain bspwm focus). i think that is probably what's going on here.

for actually fixing the issues - it's over my head. i tried flameshot out. it runs in the background and pops the capture widget when requested -`flameshot gui` will exit...

you can do something like node="${1:-focused}" bspc node "${node}.fullscreen" -t \~ -n @brother || bspc node "$node" -i -t fullscreen to avoid resizing other nodes when switching in and out...

check `honor_size_hints` config

>Problem now is that I can't grow window with increment lesser than hint suggests. i had forgotten all about that. it's really unfortunate. >I believe growing logic should be corrected....

this issue is similar to #1336. maybe this fix could be as simple as something like [this](https://gist.github.com/ortango/bd104ecf29506379e250e001374b9bc5), but i'm not sure about side effects. it won't help with monitor order...

fyi: the xprop output looks like it is for the main window and not the splash screen does the main window appear or do you only see the splash until...

i tried digikam 7.2.0 with bspwm 0.9.10 and am not able to recreate the issue here. you don't have a rule or an external rules script that could be interfering...

out of curiosity: why is this the window manager's fault? EAF seems to have issues with a few wms. bspwm uses a simple `xcb_set_input_focus()` to set focus (i think bspwm...