XRestackWindows and xscreensaver

Johannes Jordan jordan at lanrules.de
Tue Feb 7 11:25:38 CET 2023


Hello Kitten,

Thank you for your detailed inquiry.

As far as I see it, herbstluftwm already adheres to the recommendation given by XScreenSaver FAQ. It only uses XRaiseWindow for fullscreen windows and if you raise a window by command. For everything e
>> lse, XRestackWindows
is performed.

Notification windows are often unmanaged. I assume that's the case for the ones you are having problems with (a simple giveaway is if they are not decorated by herbstluftwm). Maybe setting a rule to managing them could help but will have other effects you might not like (window placement).

Maybe this issue (and related ones) may also help: https://GitHub.com/dunst-project/dunst/issues/553
Here, a recommendation for picom config if given (do you use a composite manager?)

Johannes

Feb 7, 2023 10:57:27 Kitten via hlwm <hlwm at lists.herbstluftwm.org>:

> Hi, I've loved the WM for years, and I wanted to bring up a small problem I've noticed. XScreenSaver occasionally has squares drawn over it, namely Polybar and Dunst notifications, so I went to read XScreenSaver's FAQ and found the following:
> 
>>  *Programs sometimes pop up dialog boxes over the screen saver while my display is locked, and I wish they didn't.*
>> 
>> This is a bug in your window manager and/or that application, and there is little that XScreenSaver can do about it. If this is happening it is because of one of two reasons:
>> 
1. >> The window manager is placing windows on screen with XRaiseWindow, meaning, "place this window atop all others, including the screen saver." This is wrong.
>> 
>> What it should be doing instead is ordering its windows using XRestackWindows, the semantics of which are, "here is the list of windows I manage, and the order in which they should be stacked." By using XRestackWindows, the window manager will never alter the stacking order of non-managed windows that are not within its remit.
>> 
2. >> The application is using an OverrideRedirect window, explicitly hiding its pop-up window from the window manager. This is also wrong.
>> 
>> Pop-ups, notifications, and all similar windows should be mapped as WM_TRANSIENT_FOR and/or _NET_WM_WINDOW_TYPE_DIALOG windows, as has been explained by the ICCCM[https://x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html] and the FreeDesktop[https://www.freedesktop.org/wiki/Specifications/wm-spec/] EWMH[https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#idm46400537374992] specifications for decades.
>> 
>> XScreenSaver can't prevent such improperly-mapped windows from appearing on screen, but it does slightly mitigate that by raising itself above them every few minutes. The real fix is for your window manager to not allow this to happen in the first place.
>> 
> I'm wondering whether there's something I could look into in terms of rules in my autostart, or I should be digging into my notification daemon and bar, or if this is something that could be solved in in HLWM's code.
> 
> Thank you very much for your time and work.
> 
> *Stay hydrated.
> **-Kitten (like a small cat)*
> 
> Sent with Proton Mail[https://proton.me/] secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20230207/59406007/attachment.htm>


More information about the hlwm mailing list