[BUG] stacking not working on some WMs

[Paladin1991]

Hello, I have been using eww for some time, and I really like it, I use it basically for everything in my WM, but I use more than one WM, and the question is ... In xmonad the option stacking = "bg", works very well, however in other WM's this does not happen, leaving the widegets fixed, like bars, always above the windows, would there be any way to deal with this problem?

[undefinedDarkness]

Not really, I think but idk for certain. Try playing with the focusable attribute a bit ig

[elkowar]

Might be related to #176

[manderio]

what other wms do you use, how do you start eww and what does your current config look like? which wms does it not work in and can you share screenshots?

[danjenson]

Are there any plans to fix this? I use bspwm and love this, but it gets quite annoying for zoom / watching videos to have my bars not going into the background. A hack could be to solve this by hiding the node using bspc, but my eww widgets don't even show up with bspc query -N, which returns all nodes.

Curiously, if you set the windowtype to desktop it behaves like a normal bspwm window (but is un-clickable); when set to dock it is clickable, but no longer can be hidden, using either eww or bspwm mechanisms (doesn't show up in list of controlled bspwm nodes)

[elkowar]

Well, I'd love to fix it, I just have no idea how to ^^ from all I can tell, eww provides the correct, spec-compliant EWMH properties in the right moments, and WMs just ignore them. I'm pretty sure there is something eww could do to improve, but I have not been able to figure out what even after tooooons of playing around. If anyone that has more experience or knowledge here wants to chime in and he?, I'd be more than happy to accept any help I can get ^^

[danjenson]

Sadly, I'm not sure. But thank you for all the great work! In the interim, here is my hack for bspwm

bspc subscribe node_state | while read -r _ _ _ _ state flag; do
  if [[ "$state" != fullscreen ]]; then continue; fi
  if [[ "$flag" == on ]]; then
    xdotool search --class eww-bar windowunmap
  else
    xdotool search --class eww-bar windowmap
  fi
done &

[nicolasshu]

Thanks, @danjenson! You're amazing! I've expanded you case to deal with multiple monitors:

declare -A monitors
monitors[0x00200017]="DVI-D-0"
monitors[0x00200014]="HDMI-1"
monitors[0x00200012]="DP-0"
monitors[0x0020001C]="HDMI-0"

declare -A bars
bars["DVI-D-0"]="topbar_0"
bars["HDMI-1"]="topbar_1"
bars["HDMI-0"]="topbar_2"
bars["DP-0"]="topbar_3"

bspc subscribe node_state | while read -r _ mon _ _ state flag; do
  if [[ "$state" != fullscreen ]]; then continue; fi
  if [[ "$flag" == on ]]; then
    xdotool search --class ${bars[${monitors[$mon]}]} windowunmap
  else
    xdotool search --class ${bars[${monitors[$mon]}]} windowmap
  fi
done

[VuiMuich]

Curiously, if you set the windowtype to desktop it behaves like a normal bspwm window (but is un-clickable); when set to dock it is clickable, but no longer can be hidden, using either eww or bspwm mechanisms (doesn't show up in list of controlled bspwm nodes)

Very interesting, in leftwm the window gets drawn as specified in the yuck when it is of type desktop and it is clickable. At least one of the both WMs implemented the desktop type wrong I guess.

eww provides the correct, spec-compliant EWMH properties in the right moments, and WMs just ignore them.

I guess you are taking about hx crates/eww/src/display_backend.rs:119 and the next line where you expect the property being set, right? I tried different things, but the windows always reports those state atoms in xprop:

_NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE, _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER

So I guess GTK might do something wrong here?

Nevertheless I'll check if we can improve stacking in LeftWM. EWMH seems to be quite liberal on this topic and just recommends some stacking order, so no wonder different WMs handle it inconsistently.

Edit: while allready at the EWMH specs I looked up what they say about window type desktop:

_NET_WM_WINDOW_TYPE_DESKTOP indicates a desktop feature. This can include a single window containing desktop icons with the same dimensions as the screen, allowing the desktop environment to have full control of the desktop, without the need for proxying root window clicks.

so this looks to me as if bspwm might put the root of it's tree on an node of type desktop and therefore windows of this type are handled as nodes. So ignoring dock for the nodes makes somewhat sense.

[PoSayDone]

For bspwm users:

xdo above -t "$(xdo id -N Bspwm -n root | sort | head -n 1)" $(xdo id -n YOUR_EWW_WM_CLASS)

It's not permanent, but better than nothing

[joefiorini]

I don't know how to solve this issue, but I want to share one thing I noticed that might be related?

When I run xprop | grep -i desktop|type I get the following output when clicking on my eww dock bar:

xprop | grep -Ei "desktop|type"
_NET_WM_DESKTOP(CARDINAL) = 4294967295
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK

However, if I try the same command on a regular window on the same desktop (ie. a terminal window instance) I get a completely different value for desktop:

xprop | grep -Ei "desktop|type"
_NET_WM_DESKTOP(CARDINAL) = 0

And attempting to query the desktop with xdotool doesn't work either:

 xdotool search eww-bar get_desktop_for_window
Defaulting to search window name, class, classname, and role
XGetWindowProperty[_NET_WM_DESKTOP] failed (code=1)
-1

  xdotool search kitty get_desktop_for_window
Defaulting to search window name, class, classname, and role
0

This makes it impossible to query the bar on the current desktop. Perhaps _NET_WM_DESKTOP needs to be set differently?

[soranoningyo]

dwm user here, the issue is also occurring to me, tried all window types with combination with wm ignore

[bcyran]

Just reporting that I'm experiencing the same problem on i3. xprop on the eww window shows:

_NET_WM_STATE(ATOM) = _NET_WM_STATE_BELOW, [...]

So I guess eww is working properly and i3 ignores the _NET_WM_STATE_BELOW. Still, maybe some workaround would be possible, i3 is pretty popular and it would be a shame to exclude its userbase :cry:.

[eclairevoyant]

_NET_WM_DESKTOP(CARDINAL) = 4294967295

This is correctly set to 0xFFFFFFFF as per the EWMH spec:

0xFFFFFFFF indicates that the window SHOULD appear on all desktops.

If your WM doesn't respect EWMH that sounds like a WM bug tbh.

[lictw]

+1 here, why polybar for ex. responds for clicks and stays in background when float window hovering in bspwm while eww unclickable/in foreground, what properties are different in this cases?

PS poly has _NET_WM_STATE_ABOVE at the same time and still going in background, don't understand this magic..

[musjj]

Anyone noticing that this sometimes works in bspwm? Not sure what's happening, but sometimes it just works properly. But reloading with eww reload resets that behaviour and the eww bar once again becomes visible on top of full screen applications.

[jrachele]

Polybar seems to have coded their own workaround for this for bspwm, with their option wm-restack: bspwm. It will first query the bspwm root window, then tell X11 to position the bar directly above said window, so that it lies above the bspwm root, but below all bspwm child windows. I'm not sure if this is a desired/feasible addition to Eww as it is particular to BSPWM

As a workaround for BSPWM in particular, I've found you can do something like this in your bspwmrc: bspc rule -a eww-bar monitor=DP-2 state=floating focus=off sticky=on border=off

Then ensure that :windowtype "normal" is active in your Eww bar.

The caveat being that Eww is treated as any other window, meaning you can now manipulate your Eww bar directly and may end up accidentally closing it/moving it but that's an acceptable sacrifice imo

[soranoningyo]

Polybar seems to have coded their own workaround for this for bspwm, with their option wm-restack: bspwm. It will first query the bspwm root window, then tell X11 to position the bar directly above said window, so that it lies above the bspwm root, but below all bspwm child windows. I'm not sure if this is a desired/feasible addition to Eww as it is particular to BSPWM

As a workaround for BSPWM in particular, I've found you can do something like this in your bspwmrc: bspc rule -a eww-bar monitor=DP-2 state=floating focus=off sticky=on border=off

Then ensure that :windowtype "normal" is active in your Eww bar.

The caveat being that Eww is treated as any other window, meaning you can now manipulate your Eww bar directly and may end up accidentally closing it/moving it but that's an acceptable sacrifice imo

i have tried this but it doesn't seem to work i added this to my bspwmrc bspc rule -a dashboard monitor=DP-2 state=floating focus=off sticky=on border=off and :window-type is normal and my widget is called dashboard, am I missing something

[jrachele]

Polybar seems to have coded their own workaround for this for bspwm, with their option wm-restack: bspwm. It will first query the bspwm root window, then tell X11 to position the bar directly above said window, so that it lies above the bspwm root, but below all bspwm child windows. I'm not sure if this is a desired/feasible addition to Eww as it is particular to BSPWM As a workaround for BSPWM in particular, I've found you can do something like this in your bspwmrc: bspc rule -a eww-bar monitor=DP-2 state=floating focus=off sticky=on border=off Then ensure that :windowtype "normal" is active in your Eww bar. The caveat being that Eww is treated as any other window, meaning you can now manipulate your Eww bar directly and may end up accidentally closing it/moving it but that's an acceptable sacrifice imo

i have tried this but it doesn't seem to work i added this to my bspwmrc bspc rule -a dashboard monitor=DP-2 state=floating focus=off sticky=on border=off and :window-type is normal and my widget is called dashboard, am I missing something

If you open a terminal window and type xprop | grep WM_CLASS, then click on your eww bar it will tell you the class in the second field. I’m pretty sure regardless of the name of your bar, the class is still “eww-bar” so try it with that instead of “dashboard”

[Tsukimid]

Polybar seems to have coded their own workaround for this for bspwm, with their option wm-restack: bspwm. It will first query the bspwm root window, then tell X11 to position the bar directly above said window, so that it lies above the bspwm root, but below all bspwm child windows. I'm not sure if this is a desired/feasible addition to Eww as it is particular to BSPWM As a workaround for BSPWM in particular, I've found you can do something like this in your bspwmrc: bspc rule -a eww-bar monitor=DP-2 state=floating focus=off sticky=on border=off Then ensure that :windowtype "normal" is active in your Eww bar. The caveat being that Eww is treated as any other window, meaning you can now manipulate your Eww bar directly and may end up accidentally closing it/moving it but that's an acceptable sacrifice imo

i have tried this but it doesn't seem to work i added this to my bspwmrc bspc rule -a dashboard monitor=DP-2 state=floating focus=off sticky=on border=off and :window-type is normal and my widget is called dashboard, am I missing something

try eww-dashboard

[XXiaoA]

Polybar seems to have coded their own workaround for this for bspwm, with their option wm-restack: bspwm. It will first query the bspwm root window, then tell X11 to position the bar directly above said window, so that it lies above the bspwm root, but below all bspwm child windows. I'm not sure if this is a desired/feasible addition to Eww as it is particular to BSPWM

As a workaround for BSPWM in particular, I've found you can do something like this in your bspwmrc: bspc rule -a eww-bar monitor=DP-2 state=floating focus=off sticky=on border=off

Then ensure that :windowtype "normal" is active in your Eww bar.

The caveat being that Eww is treated as any other window, meaning you can now manipulate your Eww bar directly and may end up accidentally closing it/moving it but that's an acceptable sacrifice imo

This is the most hack-like wrokaround I've met this year. But it does work. Thx.

This bug have existed for a pretty long time....