SUMMARY I am trying to create a game overlay (something like gamebar in windows 10), and i need my overlay to stay reliably on top of the game window. so, it has the "keep above others" option. when i run a game in window mode, everything works well. but once i go into windowed fullscreen mode, and i focus the game window by clicking on it, my overlay or any app like firefox with "keep above others" enabled goes into the background. i don't know if this is intended behavior, but on windows, i don't have this issue and multiple overlays similar to mine work fine. for now, i just set the game option "keep below others" enabled, and now my overlay can stay on top. STEPS TO REPRODUCE 1. Open any lutris game in windowed fullscreen mode. 2. set any other app's window as "keep above others" 3. click on the game window to focus it and watch the other app's window go into background OBSERVED RESULT EXPECTED RESULT When the game is running in windowed fullscreen, the apps with "keep above others" option enabled must be visible and not go into background. if the game is in fullscreen, then maybe the apps should go into background? that's for the devs to decide. this is how it works on windows atleast. SOFTWARE/OS VERSIONS Windows: 10 macOS: Linux: 5.10 (available in About System) KDE Plasma Version: 5.22.4 KDE Frameworks Version: 5.85.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION https://bugs.kde.org/show_bug.cgi?id=430997 is similar, but its talking about fullscreen windows while i am talking about windowed fullscreen mode.
Yes, it is intentional as per: https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#STACKINGORDER As a KDE specific override you can copy what we do for "critical notifications" which is a KDE specific window type you can set your window to.
*** Bug 441413 has been marked as a duplicate of this bug. ***
*** Bug 430997 has been marked as a duplicate of this bug. ***
We should consider shipping KWin with a window rule to override this by default, since it's clearly something users expect, even if it violates the spec. But users don't care about the spec, they care about the end result. :) If we ship a window rule, then technically KWin itself is still following the spec, but users are availing themselves of a shipped-by-default local override for it. :)
just to add. i made a new issue https://bugs.kde.org/show_bug.cgi?id=442720 which is related to this. but more about pointer staying grabbed when i hover/click on the clearly top windows which are using transient_for or critical notification settings. mentioning just in case devs want to consider both the issues before coming to a decision :) about the spec, https://specifications.freedesktop.org/wm-spec/wm-spec-1.4.html#STACKINGORDER , I raised a similar issue with i3, and dev said that the stacking order is more of a recommendation and explicitly says that window managers are free to choose differently when it makes sense. https://github.com/i3/i3/issues/4478#issuecomment-900493830 so, keeping the "stay above others" windows on top of windowed fullscreen might technically not be breaking the spec. there's also critical notifications which already are going above not just windowed fullscreen, but fullscreen windows. for both issues, one of the main use cases is overlays for games, also recently firefox has a feature to "pop out" the video player part and drag it around.its called picture in picture feature. people might want to watch news/music videos/cat videos/game walkthroughs etc.. while playing a video game or some other fullscreen thing like terminal. allowing the PiP video be clickable is important as it will allow me to pause it.
Created attachment 141792 [details] PiP firefox video pop up above a game
*** Bug 445366 has been marked as a duplicate of this bug. ***
So it can be set already at user level or should we wait for you to implement it into Plasma?
You can do it at the user level today with KWin window rules. This bug report is about us shipping such a window rule for everyone by default.
Can you tell me how to do it at user level? I tried every window type for VLC but it isn't on top of fullscreen window. Can you tell me how to set windows type "critical notification" for VLC in Plasma 5?
I don't know, sorry.
As David said, this is an intentional behavior. Also, yes, the stacking order in the NETWM spec is a recommendation but the applications are written with that recommended stacking order in mind. So if we start changing that, we can break more things than we try to fix. If you want to force a window to be above fullscreen windows, you could create a window rule that forces "overlay" layer. It was introduced in 6.0. Picture-in-picture windows was one of the reasons why it was added.
What do you think about my idea of shipping a default window rule to do this? That way KWin itself isn't technically breaking the spec, but users get the behavior they're expecting.
(In reply to Nate Graham from comment #13) > What do you think about my idea of shipping a default window rule to do > this? That way KWin itself isn't technically breaking the spec, but users > get the behavior they're expecting. If I can add my opinion I think it will be sufficient. But I have to mention - GNOME has it already long time just in right-click menu on window decoration: https://askubuntu.com/a/1499131 which leads me to request it as default option in KDE too. :)
(In reply to Nate Graham from comment #13) > What do you think about my idea of shipping a default window rule to do > this? That way KWin itself isn't technically breaking the spec, but users > get the behavior they're expecting. I think it's unnecessary because we've already got a window rule to force windows to be on specific stack layers.
(In reply to Vlad Zahorodnii from comment #12) > As David said, this is an intentional behavior. > > Also, yes, the stacking order in the NETWM spec is a recommendation but the > applications are written with that recommended stacking order in mind. So if > we start changing that, we can break more things than we try to fix. I understand. As a workaround, I just added the no titlebar / frame rule to the game and set its size to almost full monitor resolution. That makes everything work well. I am confused about windowed fullscreen vs fullscreen at this point. It seems both of them are the same from the perspective of KDE? Fullscreen just adds the additional behavior that if the game lost focus, it minimizes itself. Anyway, there's also a another related bug at https://bugs.kde.org/show_bug.cgi?id=442720 regarding cursor staying grabbed by the game even if I try to click on the windows above it (firefox PiP player or notifications). I set the layer for the game "below" to make sure the others stay above. Notifications seem to go below the windowed fullscreen game (That behavior seems new. In the past, notifications still appeared above, even if non-clickable due to mouse grab). I am not even sure if that is a bug or just intended behavior. So, please review that too if you have some time :)
(In reply to Vlad Zahorodnii from comment #15) > (In reply to Nate Graham from comment #13) > > What do you think about my idea of shipping a default window rule to do > > this? That way KWin itself isn't technically breaking the spec, but users > > get the behavior they're expecting. > > I think it's unnecessary because we've already got a window rule to force > windows to be on specific stack layers. Are you saying we already ship a window rule out of the box that does this, and I missed it? Or are you saying that every affected user can go and manually create their own window rule to fix it for themselves?
Can a proposal be made to change the specification? Maybe add a _NET_WM_PEAK that would get treated as a window that even goes above a fullscreen window?