option to force window to draw in foreground

[ExpandingMan]

Description of the requested feature

I'm not entirely sure whether this should be considered a new feature or a bug, or if there's already some way of doing this that I can't figure out.

It would be nice to tell eww that a window should be drawn on top of everything and necessarily visible (my use case is for bringing up menus while watching full-screen video). Currently this does not seem possible on Xorg, at least not without special configuration of the window manager.

I know it's possible to do this because dunst does, though this is the only thing I'm currently aware of that draws on top of full-screen windows in X.

Proposed configuration syntax

The :stacking argument to defwindow should be further clarified. Presumably this behavior would either replace "fg" or get its own value.

Additional context

Again, particularly relevant if something else is in full-screen.

[elkowar]

:stacking "fg" is already pretty much all we can do in terms of what X supports, as well as setting the window type to something your WM might see as "keep in front". What you can do if your WM doesn't handle this properly is try setting :wm-ignore true, in which case the window tends to be drawn in the front of everything, as the WM doesn't care about it at all.

[elkowar]

The only thing that I can see dunst do here would be either that they too set override redirect (which is what wm-ignore does) or that maybe, in some weird WM, _NET_WM_WINDOW_TYPE = _NET_WM_WINDOW_TYPE_NOTIFICATION is the magic sauce that's needed to actually force it to stay in the foreground,... In that case, that'd be a very weird interpretation of the EWMH spec (which clearly states that _NET_WM_STATE_ABOVE is supposed to keep the window above other windows)

[ExpandingMan]

Hm, not sure. I tried doing it with :wm-ignore true and it does not seem to make a difference. I also tried messing with :windowtype but it doesn't seem to make any difference.

This is only i3, nothing weird or fancy. I doubt it'll be very enlightening, but you can see the config in question here.

Just to be extra clear: I'm pretty sure the only circumstance in which :wm-ignore true, :stacking "fg" does not place the window on top is when another window is fullscreen. Again, dunst most definitely does draw on top of the full screen in these circumstances.

I suppose this should be considered a "bug", though I wouldn't be surprised if dunst does some weird shenanigans to get around it.

If there's anything you want me to check to help debug this, I'll give it a shot. When I get a chance I'll try doing xprop on the fullscreen window, but I'll have to set up a special keybinding to do this as there's no other way for me to call the command while something else is in fullscreen.

Update: I had mostly been trying this on the browser watching fullscreen video, as that was the intended use case for this particular window, but I also just tried it with fullscreen alacritty, just in case the browser was doing some crazy nonsense (as browsers are wont to do) but I have the same issue even with alacritty.

[ExpandingMan]

WM_STATE(WM_STATE):
        window state: Normal
        icon window: 0x0
I3_FLOATING_WINDOW(CARDINAL) = 1
_NET_WM_DESKTOP(CARDINAL) = 4294967295
_NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE, _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER
WM_HINTS(WM_HINTS):
        Client accepts input or input focus: True
        Initial state is Normal State.
        window id # of group leader: 0x1600001
_GTK_THEME_VARIANT(UTF8_STRING) =
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 2559, 0, 0
_NET_WM_STRUT(CARDINAL) = 0, 0, 0, 0
XdndAware(ATOM) = BITMAP
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 23070189, 23070190
_NET_WM_USER_TIME(CARDINAL) = 22555825
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x16005ec
WM_CLIENT_LEADER(WINDOW): window id # 0x1600001
_NET_WM_PID(CARDINAL) = 10195
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "tv"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
        program specified minimum size: 368 by 73
        program specified base size: 0 by 0
        window gravity: Center
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "eww-powermenu", "eww-powermenu"
WM_ICON_NAME(STRING) = "Eww - powermenu"
_NET_WM_ICON_NAME(UTF8_STRING) = "Eww - powermenu"
WM_NAME(STRING) = "Eww - powermenu"
_NET_WM_NAME(UTF8_STRING) = "Eww - powermenu"

btw, here is the xprop of the eww window I'm trying to open. This is of course just one of my attempted configurations.

Also, I suggest that, regardless, you add a "notification" window type to :windowtype.

[elkowar]

I guess Ill look into what Dunst is doing a bit more closely

[ExpandingMan]

Thought I'd mention, I was messing around in dunst today and noticed that they actually have a bunch of different options specifically regarding what to do if something else is in full screen, see here.

No idea what they are actually doing to achieve that, but it seemed relevant that they have multiple options.

[p0ryae]

I guess Ill look into what Dunst is doing a bit more closely

Any updates on this? I experience the same issue on bspwm - On startup, its always in the background and doesn't show up on top of other windows or fullscreen - but once I reload bspwm, it draws it on top of basically everything, no matter if its fullscreen or a normal window

[elkowar]

Not yet, still don't really have time to work on eww, as I'm busy writing my bachelors thesis. Once that's done, in about a month, this will be one of the first issues I'll try to tackle, tho!

[p0ryae]

Not yet, still don't really have time to work on eww, as I'm busy writing my bachelors thesis. Once that's done, in about a month, this will be one of the first issues I'll try to tackle, tho!

Sounds totally fine! Thanks for putting the effort you put on this project

[elkowar]

Ok, so after looking into dunst for a bit, It doesn't seem to do anything special, at least on X. It just sets the window type to NOTIFICATION and UTILITY -- which shouldn't do anything more than what the things eww already supports do. I might add the notification window type just to be sure, but that shouldn't be it. otherwise it sets _NET_WM_STATE_ABOVE -- which eww also does.

On wayland there's the different layers etc, but that's another beast alltogether, which should already work in eww.

I'll look through the dunst sourcecode for a bit more tho

[elkowar]

Ok, it seems as though dunst sets WM_REDIRECT, which corresponds to eww's wm-ignore property -- Maybe that's all you need for it to be consistent :/

[p0ryae]

Wait so once the WM_REDIRECT feature gets implemented, it'll fix the problem regarding the draw on foreground?

[elkowar]

Wait so once the WM_REDIRECT feature gets implemented, it'll fix the problem regarding the draw on foreground?

WM_REDIRECT is ewws wm-ignore, so if you set wm-ignore to true on your window, it will have the wm redirect thing. Tbf, I have also seen Dunst windows actually go behind others in certain cases, so Im not sure if there's anything we can do about the edge cases where it doesn't work. X is a clusterfuck of complexity, window stacking order is only provided by a protocol extension, and many WMs just do whatever they want with that -- im not sure if it's possible to have a solution that just works everywhere...

[p0ryae]

Its so weird because on startup, everything is perfectly fine for eww but when it comes to restarting eww, It just puts it above all windows. I can't find a reasonable explanation for that lol

[p0ryae]

Dunst has a fullscreen property where you can set pushback and it will not draw any notifications to the fullscreen window.

have you taken a look at it? 🤔

[elkowar]

Haven't looked into that in detail, will do.

[p0ryae]

Haven't looked into that in detail, will do.

So... Anything?

[MostHated]

Are any of these proposed changes possibly going to allow me to have a working button over top of my top menu bar (Dash-to-Panel)?

I have it visually drawn on the bar, but the button was not able to be clicked. For a while I just thought my action was not working properly until I made the eww widget taller so it stuck out from the underside of the top bar and I was able to click the small part that was "exposed"