| Summary: | windows with "keep above others" option don't stay above windows in "windowed fullscreen" mode. | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | redartofcode |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | CC: | kde, nate, petr.kejval6, the.rhorn, toadfield, varlesh |
| Priority: | LO | Keywords: | usability |
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | PiP firefox video pop up above a game | ||
|
Description
redartofcode
2021-08-17 09:14:59 UTC
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? |