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

From: Daniel d'Andrada <[email-masked]>
Date: Fri, 3 Jun 2016 17:17:26 -0300

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.

---

From: Alan Griffiths <[email-masked]>
Date: Sat, 4 Jun 2016 18:38:31 +0100

On 03/06/16 21:17, Daniel d'Andrada wrote:
> 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.

---

From: Daniel van Vugt <[email-masked]>
Date: Mon, 6 Jun 2016 07:14:40 -0400

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.

---

From: Daniel d'Andrada <[email-masked]>
Date: Mon, 6 Jun 2016 09:07:54 -0300

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:
> 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