scene::Surface - Shouldn't input_bounds be a bounding box of the input_region?

[Daniel d'Andrada]

FYI: I'm modifying ubuntu-keyboard to fill out the input shape (which is 
how the client API calls it [1]) of its surface so that qtmir/unity8 
knows where in ubuntu-keyboard's fullscreen surface is the graphical 
on-screen kbd being drawn (in order to replace the hack we currently 
have, which uses a separate socket to exchange this info). It works well.

[1] - https://bugs.launchpad.net/mir/+bug/1588967

On 06/06/2016 08:14, Daniel van Vugt wrote:
> Best I can recall, that feature is incomplete. But also the vast 
> majority of apps and toolkits don't care that it's still incomplete.
>
> What we want is for it to be an actual region (union of rectangles) 
> and a client API to set the input region of a surface. So for example, 
> a non-rectangular surface may specify its shape and clicks that are 
> outside of that shape (but still inside the surface rectangle) pass 
> through to the surface below.
>
>
> On 04/06/16 13:38, Alan Griffiths wrote:
>> On 03/06/16 21:17, Daniel d'Andrada wrote:
>>> Hi,
>>>
>>> I was working under the assumption that, in mir::scene::Surface,
>>> input_bounds() was the bounding box of the input region [1]. But it
>>> was always returning the full surface size no matter what.
>>>
>>> Then, checking implementation, I saw that it simply returns the
>>> surface size. Is that the correct and intended definition of
>>> input_bounds (there's no documentation on it, so its definition
>>> follows from the implementation itself)? Wouldn't it be more useful
>>> and accurate if it were the bounding box I thought it was? Or is it
>>> just a bad by-product of having scene::Surface inherit from
>>> input::Surface, making input_bounds() a redundant property of the 
>>> former.
>>>
>>> - Daniel
>>>
>>> [1] by the way, why there's no input_region() getter in
>>> scene::Surface? qtmir would sure make good use of it. Now it has to
>>> rely on shell::WindowManager::modify_surface to get this information.
>>>
>>
>> Yes, this is broken. (In several ways.)
>>
>> Last time I discussed it with duflu I came away with the opinion that
>> fixing it wasn't trivial as there are competing, incompatible
>> assumptions around the code.
>>
>