On December 29th, 2012, 6:52 p.m., Martin Gräßlin wrote:
is it superseeded by 108008?
To fix the bug, yes.
It's still pointless action on this occasion (we eg. re/unmaximize a client that gets removed the very next moment anyway)
- Thomas
On December 29th, 2012, 2:55 p.m., Thomas Lübking wrote:
|
Review request for kwin and Martin Gräßlin.
By Thomas Lübking.
Updated Dec. 29, 2012, 2:55 p.m.
Description
summarized.
the problem here is that ::releaseWindow calls finishCompositing() before workspace()->removeClient(this, Allowed) where the tabgroup restores the former state, causing slots on NULL effectwindows being invoked and the effect is not prepared for that.
Other options would be to
a) check the effect window everytime before emitting a slot...
b) fully untab the window before emitting the clientRemoved signal (but that's pointless)
c) explicitly disconnecting EffectsHandlerImpl from Client/Toplevel in eg. EffectsHandlerImpl::slotWindowClosed()
I actually think (c) is more reasonable but skipping pointless action won't harm either and has faar more narrow impact (so not sure whether we should disconnect the client in slotWindowClosed() - doesn't seem critical either, though)
|
Testing
Nope, i don't wobble nor maximize ;-)
|
Diffs
- kwin/client.h (e8ae850)
- kwin/client.cpp (b555c11)
- kwin/workspace.cpp (b9e137d)
View Diff
|