Clients reading their surface position on screen

[Daniel van Vugt]

While events are being injected into evdev at the kernel level, you do 
have to know screen coordinates of the window in the least, so touches 
match up. That makes Mir's sharing the window position important.

We could take Mir out of the equation if:
   (a) The event injection moved up the stack; or
   (b) All windows tested reside at (0,0).

I'm not sure either of those are as practical as adding a single 
function to the Mir client API. Although I know we don't want it to be 
used in general.

And it's better to have full-stack testing than to not have it.


On 23/07/14 23:00, Robert Carr wrote:
> Chiming in....but will admit to not having done a super detailed analysis..
>
> I do have an objection to just exposing the global coordinate space.
> Without getting in to specifics (so this doesn't become a line item
> debate on those specifics), I think we can all agree that a global
> coordinate space potentially presents issues and difficulties. The
> simplest way to deal with these issues and difficulties is to chunk away
> the whole concept :p. I haven't said anything not tautological there,
> but I felt it needed stating as I feel in part of the discussion this is
> ignored. It's not just a matter of "making an API work".
>
> I don't think this has much to do with accessibility beyond a
> superficial level.
>
> Some quick comments on practical solutions to the problem:
>
> I'm a little skeptical of the idea that testing the full input stack in
> autopilot application tests is necessary or is a significant contributor
> to quality, I think it certainly confuses test scope which has it's own
> consequences. My preferred solutions in order:
>
> 1. Do it all inside of Qt. Why not?
> 2. inject_event(client, event) testing API. This doesn't bother me much.
> 3. query_window_position API (this is neccessarily racy btw...)
>
>