https://bugs.kde.org/show_bug.cgi?id=375581
--- Comment #3 from Thomas Sondergaard <tho...@sondergaard.cc> --- (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 :-) -- You are receiving this mail because: You are watching all bug changes.
