| Summary: | netwm-spec: _NET_WM_STATE should be removed when window is withdrawn, but kwin clears it | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Thomas Sondergaard <thomas> |
| Component: | compatibility | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 5.8.5 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Thomas Sondergaard
2017-01-26 12:31:06 UTC
Btw Qt 5.6.1/5.7.0 works around this issue (QTBUG-55942). I tried to track down whether there are any changes in KWin related to that. The relevant code is in KWin::Client::releaseWindow: info->setState(0, info->state()); // Reset all state flags This code has not seen any changes in year. I tracked it down through two coding style changes and ended in a change "branches/work/kwin_composite becomes new trunk kwin" in 2007 where I'm no longer able to follow with git blame. But it's clear the code hasn't changed for a decade at least. So I looked at the implementation of NetWinInfo::setState. There I went back to the KDE 4.0 branch where this method only clears but does not delete the property. The oldest code I found is from 2007 as well and also didn't delete the property. The relevant code section has an interesting copyright header: Copyright (c) 2000 Troll Tech AS Qt implemented it that way in 2000. They didn't have a problem with their implementation for almost 2 decades. If KWin was not 100 % spec compliant in this point for > 15 years without any application or toolkit having a problem with it I must say that KWin's behavior is kind of a de-facto standard. The EWMH standard is unfortunately hardly implemented correctly by any window manager - in fact it's impossible to implement it correctly as it's contradicting. Overall I don't think this is an issue which we should fix. The risk of breaking another application is too high given that KWin behaved like that for such a long time. (In reply to Martin Flöser from comment #2) > I tried to track down whether there are any changes in KWin related to that. > The relevant code is in KWin::Client::releaseWindow: > > info->setState(0, info->state()); // Reset all state flags > > This code has not seen any changes in year. I tracked it down through two > coding style changes and ended in a change "branches/work/kwin_composite > becomes new trunk kwin" in 2007 where I'm no longer able to follow with git > blame. But it's clear the code hasn't changed for a decade at least. > > So I looked at the implementation of NetWinInfo::setState. There I went back > to the KDE 4.0 branch where this method only clears but does not delete the > property. The oldest code I found is from 2007 as well and also didn't > delete the property. The relevant code section has an interesting copyright > header: Copyright (c) 2000 Troll Tech AS > > Qt implemented it that way in 2000. They didn't have a problem with their > implementation for almost 2 decades. If KWin was not 100 % spec compliant in > this point for > 15 years without any application or toolkit having a > problem with it I must say that KWin's behavior is kind of a de-facto > standard. The EWMH standard is unfortunately hardly implemented correctly by > any window manager - in fact it's impossible to implement it correctly as > it's contradicting. > > Overall I don't think this is an issue which we should fix. The risk of > breaking another application is too high given that KWin behaved like that > for such a long time. A toolkit did have a problem with this - Qt. Hence the workaround I referred to in comment 1. > Overall I don't think this is an issue which we should fix. The risk of breaking another application is too high given that KWin behaved like that for such a long time. I don't think the risk is terribly big as other window managers follow the spec closer here. But it is a minor issue and Qt already has a workaround, so a wontfix is not a terrible loss for the world :-) > I don't think the risk is terribly big as other window managers follow the spec closer here.
The question is: why was it wrong in KWin? Given the age of the code it's quite likely that there were/are applications/toolkits not handling it correctly, so KWin had to do a workaround.
|