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...)
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
