Merge lp:~smspillaz/unity/unity.maybe_fix_861143 into lp:unity
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Gord Allott | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 1686 | ||||
Proposed branch: | lp:~smspillaz/unity/unity.maybe_fix_861143 | ||||
Merge into: | lp:unity | ||||
Diff against target: |
282 lines (+95/-34) 6 files modified
plugins/unityshell/src/PanelMenuView.cpp (+36/-3) plugins/unityshell/src/PanelMenuView.h (+3/-0) plugins/unityshell/src/PluginAdapter.cpp (+43/-31) plugins/unityshell/src/PluginAdapter.h (+3/-0) plugins/unityshell/src/WindowManager.h (+2/-0) plugins/unityshell/src/unityshell.cpp (+8/-0) |
||||
To merge this branch: | bzr merge lp:~smspillaz/unity/unity.maybe_fix_861143 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Unity Team | Pending | ||
Review via email: mp+77786@code.launchpad.net |
Description of the change
Maybe fix LP#861143 (I can't reproduce it, but some debugging with Cimi showed what may have been going on)
Instead of explicitly undecorating windows when they are maximized, listen
for changes in decoration state on PropertyNotify events on the windows
themselves and respond to them, because we might get the maximization
event when the window is mapped before compiz has had a chance to decorate
the window.
Also cover the case where a window is withdrawn and then mapped maximized
again, where we wouldn't redecorate those windows.
In order to avoid cycling on our own undecoration requests, we set the
high bit on _MOTIF_WM_HINTS decoration field, if that high bit is
present and the window is otherwise undecorated, we should treat it
like it is still a decorated window and redecorate it when
it is restored. (Applications that explicitly undecorate the window
while this high bit is set are likely to clear the high bit and overwrite the
whole property, so we will be notified when this happens and can respond accordingly)
Here fixes the bug