[PATCH] shell: moving drag surface refine

[Bill Spitzak]

Kristian Høgsberg wrote:
> On Fri, Jul 27, 2012 at 02:58:50AM -0700, juan.j.zhao at linux.intel.com wrote:
>> From: Juan Zhao <juan.j.zhao at linux.intel.com>
>>
>> When applications not directly based on toytoolkit, like simple-egl, efl
>> applications is grabbed and moved, they may be moved to the place under
>> the panel. Then they could not be grabbed again.
>> Don't allow the pointer's bounding box move across the desktop's viewport.
> 
> This is good, but it doesn't work for multiple monitors.  I think we
> need a different strategy for supporting multiple outputs.  The
> outputs are rectangles laid out in the global coordinate system
> (output->x/y and output->current->width/height).  Here's what I think
> should work: we add a new shell->active_region to weston_compositor,
> and pixman_region32_union all the outputs into that union and then
> subtract all the panel rectangles.  It won't change very often so we
> can just keep that in desktop_shell and update it on monitor hotplug
> or resolution changes.
> 
> To see if we can move a surface, we intersect the bounding box for the
> surface with shell->active_region and look at the boxes in the
> intersection.  If all boxes are below a minimum width we cancel the
> horizontal movement (set dx = es->geometry.x).  If all boxes are below
> a certain height we cancel the vertical movement.
> 
> It's a slightly different heuristics than the bounding box you
> implemented below, but I think it works better.  The bounding box
> approach will restrict motion event though there may be plenty of
> surface left on the screen to grab later.  The region intersect
> approach just makes sure there's always a minimum amount of surface on
> the screen.
> 
> Kristian

I don't think the surface boundaries enter into this at all. All that is 
required is that a very small square around the cursor be prevented from 
being moved off-screen or behind a panel. This square should be what is 
intersected with the non-obscured area.

In addition it may be a lot easier for the shell to just offer a "is 
this rectangle visible" call, rather than having it update a region. 
They are both running in the same process. I would use regions only to 
communicate information asynchronously between client/server.