Merge lp:~vanvugt/compiz/fix-1089811 into lp:compiz/0.9.9

Proposed by Daniel van Vugt
Status: Merged
Approved by: Sam Spilsbury
Approved revision: 3530
Merged at revision: 3530
Proposed branch: lp:~vanvugt/compiz/fix-1089811
Merge into: lp:compiz/0.9.9
Diff against target: 22 lines (+3/-2)
1 file modified
src/window.cpp (+3/-2)
To merge this branch: bzr merge lp:~vanvugt/compiz/fix-1089811
Reviewer Review Type Date Requested Status
PS Jenkins bot (community) continuous-integration Approve
Sam Spilsbury Approve
Andrea Azzarone Pending
Daniel van Vugt Pending
Review via email: mp+139847@code.launchpad.net

This proposal supersedes a proposal from 2012-12-13.

Commit message

Ensure that when a window is fake-minimized by Unity that we don't still
reserve its input region, or else it will behave like a dead zone on the
screen. (LP: #1089811)

Description of the change

Much better than reverting r3513 which triggered the bug (but is not the root cause).

To post a comment you must log in.
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

And yes, we still want priv->region non-empty or else the window becomes transparent during the minimize animation.

Revision history for this message
Andrea Azzarone (azzar1) wrote : Posted in a previous version of this proposal

Works here.

review: Approve
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Hmm, this irks me somewhat. It will have some interesting side effects, like if the input shape region changes while the window is minimized. It also represents some behavioural coupling that I'd like to avoid.

The one thing I can think of is that I believe the nBounding < 1 and nInput < 1 checks were only put in place in the case of shape support being missing (hence, region and inputRegion would be empty). As such, those checks should really be removed and the assignments should only happen if we actually queried the shape:

So:

bool queriedShape = false;

if (screen->XShape ())
{
    ... Query Shape

    queriedShape = true;
}

r.x = -geom.border ();
...

if (!queriedShape)
{
    boundingShaperects = &r;
    nBounding = 1;
    inputShapeRects = &r;
    nInput = 1;
}

priv->region += ....

if (!queriedShape)
{
    if (!boundingShapeRects)
        XFree ...
}

review: Needs Information
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

Yeah, just had a chat with duflu on IRC, lets not merge this until we've discussed it further.

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

Yeah something like that sounds even more correct. I'll do it tomorrow if no one else does.

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote : Posted in a previous version of this proposal
review: Approve (continuous-integration)
Revision history for this message
Michael Terry (mterry) wrote : Posted in a previous version of this proposal

Sounds like this could use a test too, especially since it already regressed once.

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

On Thu, Dec 13, 2012 at 10:36 PM, Michael Terry
<email address hidden> wrote:
> Sounds like this could use a test too, especially since it already regressed once.

Well, a test for this wouldn't be all that useful. The problem was
with integration all the way from unity to compiz, getting that under
test would just be insane.

Testing it by itself would just test that the code does what it does.

> --
> https://code.launchpad.net/~vanvugt/compiz/fix-1089811/+merge/139652
> You are reviewing the proposed merge of lp:~vanvugt/compiz/fix-1089811 into lp:compiz.

--
Sam Spilsbury

Revision history for this message
Michael Terry (mterry) wrote : Posted in a previous version of this proposal

We have integration tests, right? Maybe a unity autopilot test for this case?

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

On Thu, Dec 13, 2012 at 10:51 PM, Michael Terry
<email address hidden> wrote:
> We have integration tests, right? Maybe a unity autopilot test for this case?

AP might be appropriate.

> --
> https://code.launchpad.net/~vanvugt/compiz/fix-1089811/+merge/139652
> You are reviewing the proposed merge of lp:~vanvugt/compiz/fix-1089811 into lp:compiz.

--
Sam Spilsbury

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

Reviewing Sam's concerns again:
  1. "if the input shape region changes while the window is minimized". Yes this will be a potential (albeit unlikely and rare) problem. And again only a problem when using Unity :(
  2. Code clean up. As usual I would like to avoid cleaning up code as part of a bug fix. They should be separate activities if possible.

OK, well I don't have a good answer to #1 right now. Only two simple solutions come to mind:
  (a) Approve andyrock's revert of r3513. It will cause a regression of LP: #1087193 but that's a minor issue compared to bug 1089811.
  (b) Fix Unity, by deleting the offending code: UnityWindow::[un]minimize[d]()

Until we can do (b), I think I will chose (a).

review: Disapprove
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Posted in a previous version of this proposal

On Fri, Dec 14, 2012 at 2:08 PM, Daniel van Vugt
<email address hidden> wrote:
> Review: Disapprove
>
> Reviewing Sam's concerns again:
> 1. "if the input shape region changes while the window is minimized". Yes this will be a potential (albeit unlikely and rare) problem. And again only a problem when using Unity :(
> 2. Code clean up. As usual I would like to avoid cleaning up code as part of a bug fix. They should be separate activities if possible.
>
> OK, well I don't have a good answer to #1 right now. Only two simple solutions come to mind:
> (a) Approve andyrock's revert of r3513. It will cause a regression of LP: #1087193 but that's a minor issue compared to bug 1089811.
> (b) Fix Unity, by deleting the offending code: UnityWindow::[un]minimize[d]()

OK, if you want to lose minimized previews in the switcher...

What's wrong with changing the check for (if nBounding < 1) ... if (nInput < 1)

>
> Until we can do (b), I think I will chose (a).
> --
> https://code.launchpad.net/~vanvugt/compiz/fix-1089811/+merge/139652
> You are reviewing the proposed merge of lp:~vanvugt/compiz/fix-1089811 into lp:compiz.

--
Sam Spilsbury

Revision history for this message
Daniel van Vugt (vanvugt) wrote : Posted in a previous version of this proposal

Abstain. I might have missed something and will check Sam's approach again.

review: Abstain
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Fixed differently this time.

Talking to Sam, he confirms that Unity sets both regions to empty if a window is fake minimized. However in this case we need to fall back to a simple region for the bounding shape to ensure the minimize animation is visible. Conversely we need to avoid falling back to any input shape so as to avoid the dead zone bug 1089811.

Revision history for this message
Sam Spilsbury (smspillaz) wrote :

Yep, for now.

I've got a branch that removes settings ShapeBounding in unity too, so then we can do this properly later.

review: Approve
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Approve (continuous-integration)

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'src/window.cpp'
2--- src/window.cpp 2012-12-13 08:39:22 +0000
3+++ src/window.cpp 2012-12-14 07:56:30 +0000
4@@ -905,7 +905,8 @@
5
6 priv->region = priv->inputRegion = emptyRegion;
7
8- if (screen->XShape ())
9+ bool useXShape = screen->XShape ();
10+ if (useXShape)
11 {
12 int order;
13
14@@ -929,7 +930,7 @@
15 nBounding = 1;
16 }
17
18- if (nInput < 1)
19+ if (!useXShape)
20 {
21 inputShapeRects = &r;
22 nInput = 1;

Subscribers

People subscribed via source and target branches