Window management - Semi-maximized windows have 1px borders drawn on adjacent workspaces
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Ayatana Design |
Medium
|
John Lea | ||
| Compiz |
Medium
|
Sami Jaktholm | ||
| Compiz Core |
Medium
|
Sam Spilsbury | ||
| compiz (Ubuntu) |
Medium
|
Unassigned |
Bug Description
Semi-maximized windows have 1px borders drawn on adjacent workspaces. It's harder to see when you're running Unity, but you can see it in 12.04.
TESTCASE:
1. Open a terminal on a left-most workspace.
2. Horizontally maximize the window by right-clicking on the maximize button.
3. Go to the workspace to the right and you will see the terminal's 1px border is drawn under the launcher.
DESIGN:
There are two possible fixes, and I'm not sure which one is preferred:
1. Ensure the borders remain on the current workspace it's maximized on; or
2. Ensure semi-maximized windows don't have borders on the maximized edges (more difficult).
-------
DESIGN SAYS:
Ensure all the borders of all windows remain on the current workspace (e.g. borders should not spill on to adjacent workspace)
Related branches
- PS Jenkins bot: Approve (continuous-integration) on 2013-07-22
- Sam Spilsbury: Approve on 2013-07-22
- MC Return: Needs Information on 2013-07-21
-
Diff: 214 lines (+32/-54)2 files modifiedplugins/decor/src/decor.cpp (+3/-3)
plugins/decor/tests/acceptance/xorg-gtest/compiz_decor_acceptance_tests.cpp (+29/-51)
Changed in compiz (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Low |
Changed in compiz-core: | |
status: | Triaged → Confirmed |
Changed in compiz-core: | |
assignee: | nobody → Sam Spilsbury (smspillaz) |
description: | updated |
Changed in ayatana-design: | |
assignee: | nobody → John Lea (johnlea) |
importance: | Undecided → Medium |
status: | New → Triaged |
tags: | added: udp |
summary: |
- Semi-maximized windows have 1px borders drawn on adjacent workspaces + Window management - Semi-maximized windows have 1px borders drawn on + adjacent workspaces |
tags: | added: multimonitor |
description: | updated |
Changed in compiz: | |
assignee: | nobody → Sam Spilsbury (smspillaz) |
importance: | Undecided → Low |
status: | New → Confirmed |
Changed in compiz: | |
milestone: | none → 0.9.8.0 |
Changed in compiz-core: | |
milestone: | 0.9.8.0 → none |
Changed in compiz: | |
status: | Confirmed → Triaged |
Changed in compiz-core: | |
status: | Confirmed → Triaged |
Changed in ayatana-design: | |
status: | Triaged → Fix Committed |
Doug McMahon (mc3man) wrote : | #1 |
Daniel van Vugt (vanvugt) wrote : | #2 |
No, the bug still occurs for me on a fully updated 12.10 system.
Changed in compiz: | |
milestone: | 0.9.8.0 → 0.9.8.1 |
Changed in compiz: | |
milestone: | 0.9.8.2 → 0.9.8.4 |
Changed in compiz: | |
milestone: | 0.9.8.4 → 0.9.9.0 |
Changed in compiz: | |
importance: | Low → Medium |
Changed in compiz-core: | |
importance: | Low → Medium |
Changed in compiz (Ubuntu): | |
importance: | Low → Medium |
Sami Jaktholm (sjakthol) wrote : | #3 |
I did some digging about this issue and discovered that if a window is semi maximized, CompWindow::border is set to values of maximized window borders (left 0px, right 0px) but the normal border (left 1px, right 1px) is still drawn around semi-maximized windows.
So, if a window is semi-maximized, compiz will calculate the window geometry without leaving the extra pixel for the borders. Consequently the borders occupy the next available pixels, which happen to be in a different workspaces.
Changed in compiz: | |
milestone: | 0.9.9.0 → 0.9.9.2 |
Changed in compiz: | |
milestone: | 0.9.9.2 → 0.9.10.0 |
Changed in compiz: | |
status: | Triaged → In Progress |
assignee: | Sam Spilsbury (smspillaz) → Sami Jaktholm (sjakthol) |
Changed in compiz: | |
milestone: | 0.9.10.0 → 0.9.10.2 |
PS Jenkins bot (ps-jenkins) wrote : | #4 |
Fix committed into lp:compiz at revision 3775, scheduled for release in compiz, milestone 0.9.10.0
Changed in compiz: | |
status: | In Progress → Fix Committed |
Changed in compiz: | |
milestone: | 0.9.10.2 → 0.9.11.0 |
Changed in compiz: | |
milestone: | 0.9.11.0 → 0.9.10.2 |
Launchpad Janitor (janitor) wrote : | #5 |
This bug was fixed in the package compiz - 1:0.9.10+
---------------
compiz (1:0.9.
[ Sam Spilsbury ]
* Bump version to 0.9.10
[ Łukasz 'sil2100' Zemczak ]
* Remove debian/
- Running the support test from compiz has bad side effects, from now
on we run it from Xsession.d
* Automatic snapshot from revision 3644
[ Iven Hsu ]
* Opacify: Only dim the windows above the active window.(LP:
#1189374). (LP: #1189374)
* KWD: Fix compile errors with KDE 4.11. The KWin developers made
kdecoration
http://
(LP: #1193792). (LP: #1193792)
[ Nikolay Martynov ]
* When static switcher is enabled and has an option to show
application icon turned on the icons are expected to be ~1/3 of a
thumbnail (48px). Instead they are displayed in 512px size and
completely cover everything. This change addresses this issue. See
LP #1173914. (LP: #1173914, #1186426)
[ BryanFRitt ]
* Fixed the non-working Annotate 'Clear' Button. Moved this option's
CCSM position upwards to keep the button shortcuts together. (LP:
#1202907). (LP: #1202907)
[ Mehrdad Afshari ]
* Added "move window to previous monitor" feature to compiz Put
plugin. (LP: #1178581)
[ Hu Kang ]
* gtk-window-
min, max) buttons on the title bar is pressed. (LP: #1101648)
* Remove redundant src/logmessage/
#1067246). (LP: #1067246)
[ Steve Langasek ]
* Fix for bug #763148 (with added test cases): when the desktop is
resized, windows should stay on their original workspace. (LP:
#763148)
[ Brandon Schaefer ]
* Unrevert 3728, fix failing tests. 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.
(LP: #1165343). 1. Completely remove decorOffsetMove and other
related code from decor.cpp. Put the logic to handle the
window->input () - window->border () placement offset inside of
setWindowFr
offset from its original non-decorated position to the new
decorated position, rather than having to guess between
decoration sizes. 2. Make saveGeometry and restoreGeometry work
relative to window->border () a...
Changed in compiz (Ubuntu): | |
status: | Triaged → Fix Released |
Changed in compiz: | |
milestone: | 0.9.10.2 → none |
status: | Fix Committed → Fix Released |
I believe the bug itself, (not design), was fixed a while ago
ref - Bug 1002606