Hi,
On Tue, Jul 22, 2014 at 1:42 AM, Gerry Boland <gerry.bol...@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
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
