Clients reading their surface position on screen

[Andreas Pokorny]

Hi,


On Tue, Jul 22, 2014 at 1:42 AM, Gerry Boland <gerry.boland at canonical.com>
wrote:

> Hey folks,
> in working on QtCompositor, I stumbled across a problem ([1]).
> [...]
>
> 1. unity8 exposes a DBus API which
>      a) allows AP to ask "what are the coordinates of the surface with
>         PID x
>      b) emit signals when surface position changes
>    This isn't ideal, as it requires punching holes in client appArmor
> confinements just for testing, and would also require a lot of work in
> Autopilot to be able to listen to those DBus signals.
>
> 2. AP injects events directly into Qt/unity8
>    Requires unity8 to be in a "testing" mode. Qt would need lots of work
> for it to handle relative coordinates being injected.
>
> 3. Mir let the clients find their surface's screen position
>
> But I don't think the Mir team like that final idea (I'm not a fan either).
>

I would like to add a few things that might make this task more problematic.
But I think we can find pragmatic trade-offs and document eventual
limitations.
The compositor could decide to display a surface multiple times on screen.
Consider live previews when switching windows or in task bars. Deform the
surface
in a way that its placement can no longer accurately be described as a 4x4
matrix,
or even two coordinates.

So yes duflus surface_coord_to_screen_coord would solve more of that. Then
the server
can do the calculation - and also allow the compositor to pick one
placement of a surface
or have multiple results..

More limitations:
Since this is used for automated system tests - what happens when the given
location is occluded?
Should we care about the delay between request and response?

Are we doing the right thing here? The system test would then rely on the
positions
reported by applications to trigger an action within that application.

regards
Andreas Pokorny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20140722/9011f5b9/attachment.html>