Merge lp://qastaging/~mc-return/compiz/compiz.merge-fix771448-desktop-wall-edge-flipping-broken into lp://qastaging/compiz/0.9.10

I figured the screen edge update stuff would be controversial when I added it a few years ago.

The reason why its there is because the screen edge detection windows had an annoying tendency to block input on, eg, panels. That was really, really, annoying.

Instead of removing them, I'd suggest trying to say if you can make it work with that code.

The way it's meant to work as I understand it is that when a window is being dragged, the screen edges will be dynamically re-enabled. Although it was really complicated to get right now I remember, because we had to detect when a grab happened and then figure out whether or not the edges should be enabled because of XDnD grabs being external to our own.

I might branch this off myself tonight and see if I can come up with something a bit better, as it was quite complicated.

So what I'm thinking is that we can probably remove the mousepoll + edge update stuff and do something like this:

1. On grab, turn all edges on (eg, toggleEdges)
2. Listen for xdndEnter and xdndLeave events
3. When an edge action is triggered, if we don't have "pointer" edge flipping enabled then:
   a. If "edge flip move" is enabled check if:
      1. There has been a grabbed window and
      2. Its grabbed for moving
   b. If "edge flip dnd" is enabled check if:
      1. We currently have the xdndEnter event for an edge.

This might require some core changes too - to check if an edge was entered for a DnD event.

> I figured the screen edge update stuff would be controversial when I added it
> a few years ago.
>
> The reason why its there is because the screen edge detection windows had an
> annoying tendency to block input on, eg, panels. That was really, really,
> annoying.
>
Well, there are no regressions here, maybe there once were.

> Instead of removing them, I'd suggest trying to say if you can make it work
> with that code.
>
Why ?
It is not needed here -> look at rotate cube, where the edge flipping works
perfectly as well, completely without the plugin trying to take over core's work.

> The way it's meant to work as I understand it is that when a window is being
> dragged, the screen edges will be dynamically re-enabled. Although it was
> really complicated to get right now I remember, because we had to detect when
> a grab happened and then figure out whether or not the edges should be enabled
> because of XDnD grabs being external to our own.
>
I really do not see a reason to overcomplicate stuff in this case.

> I might branch this off myself tonight and see if I can come up with something
> a bit better, as it was quite complicated.

Sure, but I recommend to not reinvent the wheel for this, rather take some other
bug and fix it ;)

> So what I'm thinking is that we can probably remove the mousepoll + edge
> update stuff and do something like this:
>
> 1. On grab, turn all edges on (eg, toggleEdges)
> 2. Listen for xdndEnter and xdndLeave events
> 3. When an edge action is triggered, if we don't have "pointer" edge flipping
> enabled then:
> a. If "edge flip move" is enabled check if:
> 1. There has been a grabbed window and
> 2. Its grabbed for moving
> b. If "edge flip dnd" is enabled check if:
> 1. We currently have the xdndEnter event for an edge.
>
> This might require some core changes too - to check if an edge was entered for
> a DnD event.

I really see no reason for this -> I have a multimonitor system and all edge-flip
cube stuff is always working here...

If you want to fix a thing regarding the screen edges, please-please-please fix
this one:

bug #1011167

At least testing on my end shows that xdnd edge flipping is not working with this branch. Which is why I wanted to have a further look into it because I know the issues there were quite complicated.

Give me a little bit of time with this.

As for LP: #110167 - I commented on the bug report.

Actually, I can't reproduce any of the issues you've mentioned in this branch on trunk. Edge flipping works fine in wall regardless.

But in any case I still think that the requirement to do mouse polling and a screen edge detection workaround is a bit of a kludge. So I'll see if I can come up with something better.

> At least testing on my end shows that xdnd edge flipping is not working with
> this branch. Which is why I wanted to have a further look into it because I
> know the issues there were quite complicated.
>
That is really strange -> it is working perfectly here, I even tried 2x2 configurations.
I can use the pointer to flip and I can move windows around the 4 desktops, which was
not working before.

Damn - you are right -> DnD of icons does not seem to work, but note that this branch also
seems to fix: bug #858845

> Give me a little bit of time with this.
>
Sure. I will pause working on wall then...

> Actually, I can't reproduce any of the issues you've mentioned in this branch
> on trunk. Edge flipping works fine in wall regardless.
>
I do not think that I am hallucinating, 26 other people marked the bug as affecting them ;)

Well, bug #1172881 was the reason I started looking into this issue, as I usually
have the cube running to rotate to my desktops and Compiz does not allow me to
use wall and cube together (bug #1173256).

When I started looking into it I noticed that it is a duplicate of bug #771448,
which affects 26 other people, was reported as regression on 2011-04-26 and has over 100 heat.
So I thought it is an issue worth looking into and when I discovered the strange,
duplicated core code in there, I remembered bug #858845, which I never could reproduce locally,
because wall was always disabled here, because... (see above)

Bug #858845 affects 136 other people, was reported on 2011-09-25.
Those people also seem credible to me...

> But in any case I still think that the requirement to do mouse polling and a
> screen edge detection workaround is a bit of a kludge. So I'll see if I can
> come up with something better.

As long as it is efficient, does not create regressions and works I'm fine with that solution also of course.

My suggestion: Let us simply get this in first, then your corrections afterwards...

I've adjusted the commit message...

Can you merge this with lp:compiz again after your other merges land?

Excellent.