Merge lp://qastaging/~compiz-team/compiz/compiz.fix_1165343 into lp://qastaging/compiz/0.9.10
| Status: | Superseded |
|---|---|
| Proposed branch: | lp://qastaging/~compiz-team/compiz/compiz.fix_1165343 |
| Merge into: | lp://qastaging/compiz/0.9.10 |
| Diff against target: |
642 lines (+178/-158) 9 files modified
plugins/decor/src/decor.cpp (+78/-38) plugins/decor/src/decor.h (+6/-0) plugins/place/src/constrain-to-workarea/include/constrain-to-workarea.h (+3/-6) plugins/place/src/constrain-to-workarea/src/constrain-to-workarea.cpp (+25/-49) plugins/place/src/constrain-to-workarea/tests/constrain-to-workarea/src/test-place-constrain-to-workarea.cpp (+4/-57) plugins/place/src/place.cpp (+3/-8) src/window/extents/src/windowextents.cpp (+10/-0) tests/manual/README.txt (+9/-0) tests/manual/plugins/decor.txt (+40/-0) |
| To merge this branch: | bzr merge lp://qastaging/~compiz-team/compiz/compiz.fix_1165343 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| PS Jenkins bot (community) | continuous-integration | Approve | |
| MC Return | Needs Fixing | ||
| Compiz Maintainers | Pending | ||
|
Review via email:
|
|||
This proposal has been superseded by a proposal from 2013-05-20.
Commit message
Change the behaviour of undecorating windows.
Previously when a window was undecorated, we would shift it back to an appropriate position according to its gravity member. That behaviour was problematic because in the StaticGravity case the window has to just stay in the same place. But then if you had a window with StaticGravity which then did get a decoration and later removed it, it would be placed as though it was decorated and appear to be in the wrong place.
The correct behaviour is to place all windows as though they have decorations, and then when decorations are removed, to move the window back to the corner as indicated in its gravity and then expand its size to cover the obscured regions no longer hidden because the decorations went away.
The spec is unfortunately not so clear what to do in this case. But KWin does it this way
and it seems to be the sanest way of doing it.
(LP: #1165343)
Description of the change
Change the behaviour of undecorating windows.
Previously when a window was undecorated, we would shift it back to an appropriate position
according to its gravity member. That behaviour was problematic because in the StaticGravity
case the window has to just stay in the same place. But then if you had a window with StaticGravity
which then did get a decoration and later removed it, it would be placed as though it was
decorated and appear to be in the wrong place.
The correct behaviour is to place all windows as though they have decorations, and then when
decorations are removed, to move the window back to the corner as indicated in its gravity
and then expand its size to cover the obscured regions no longer hidden because the decorations
went away.
The spec is unfortunately not so clear what to do in this case. But KWin does it this way
and it seems to be the sanest way of doing it.
(LP: #1165343)
| PS Jenkins bot (ps-jenkins) wrote | # |
| MC Return (mc-return) wrote | # |
| Sam Spilsbury (smspillaz) wrote | # |
| PS Jenkins bot (ps-jenkins) wrote | # |
| MC Return (mc-return) wrote | # |
| MC Return (mc-return) wrote | # |
| Sam Spilsbury (smspillaz) wrote | # |
| MC Return (mc-return) wrote | # |
| Sam Spilsbury (smspillaz) wrote | # |
| Sam Spilsbury (smspillaz) wrote | # |
| MC Return (mc-return) wrote | # |
| Sam Spilsbury (smspillaz) wrote | # |
| MC Return (mc-return) wrote | # |
| PS Jenkins bot (ps-jenkins) wrote | # |
PASSED: Continuous integration, rev:3660
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://