On Fri, Aug 15, 2014 at 10:23 PM, Michał Sawicz wrote:
> Only reason I suggested the idea is that restarting unity8 would be a new
>> thing for all app tests, and maybe sending a dbus signal would be less
>> disruptive? But if Thomi things restarting is ok, then I'm happy.
>>
>
> We're already re
W dniu 15.08.2014 o 09:32, Gerry Boland pisze:
Only reason I suggested the idea is that restarting unity8 would be a new thing
for all app tests, and maybe sending a dbus signal would be less disruptive?
But if Thomi things restarting is ok, then I'm happy.
We're already restarting unity with
On 15/08/14 08:27, Christopher James Halse Rogers wrote:
>
>
> On Fri, Aug 15, 2014 at 5:21 PM, Gerry Boland
> wrote:
> > On 15/08/14 08:17, Christopher James Halse Rogers wrote:
> >> On Fri, Aug 15, 2014 at 5:14 PM, Gerry Boland
> >> wrote:
> >> > On 15/08/14 00:56, Christopher James Halse Ro
On Fri, Aug 15, 2014 at 5:21 PM, Gerry Boland
wrote:
On 15/08/14 08:17, Christopher James Halse Rogers wrote:
On Fri, Aug 15, 2014 at 5:14 PM, Gerry Boland
wrote:
> On 15/08/14 00:56, Christopher James Halse Rogers wrote:
>> On Fri, Aug 15, 2014 at 9:32 AM, Gerry Boland
>> wrote:
>
On 15/08/14 08:17, Christopher James Halse Rogers wrote:
> On Fri, Aug 15, 2014 at 5:14 PM, Gerry Boland
> wrote:
> > On 15/08/14 00:56, Christopher James Halse Rogers wrote:
> >> On Fri, Aug 15, 2014 at 9:32 AM, Gerry Boland
> >> wrote:
> >> > On 14/08/14 00:31, Christopher James Halse Rogers
On Fri, Aug 15, 2014 at 5:14 PM, Gerry Boland
wrote:
On 15/08/14 00:56, Christopher James Halse Rogers wrote:
On Fri, Aug 15, 2014 at 9:32 AM, Gerry Boland
wrote:
> On 14/08/14 00:31, Christopher James Halse Rogers wrote:
>> Ok. I think we've explored all the relevant options
>>
>> If
On 15/08/14 00:56, Christopher James Halse Rogers wrote:
> On Fri, Aug 15, 2014 at 9:32 AM, Gerry Boland
> wrote:
> > On 14/08/14 00:31, Christopher James Halse Rogers wrote:
> >> Ok. I think we've explored all the relevant options
> >>
> >> If I implemented
> >>
> >> mir_debug_surface_coord_to
On Fri, Aug 15, 2014 at 9:32 AM, Gerry Boland
wrote:
On 14/08/14 00:31, Christopher James Halse Rogers wrote:
Ok. I think we've explored all the relevant options
If I implemented
mir_debug_surface_coord_to_screen(MirSurface, int x, int y, int*
outx,
int* outy)
in libmirclient-debug an
On 14/08/14 00:31, Christopher James Halse Rogers wrote:
> Ok. I think we've explored all the relevant options
>
> If I implemented
>
> mir_debug_surface_coord_to_screen(MirSurface, int x, int y, int* outx,
> int* outy)
>
> in libmirclient-debug and hooked it up to a --debug flag, who would
> ob
On Thu, Aug 14, 2014 at 6:28 PM, Daniel van Vugt
wrote:
I think a MirBool is enough. Although if anyone does implement the Qt
function later then that one doesn't have such luxury. You would have
to return some invalid Point for Qt.
Which is one reason why we absolutely should not implement t
I think a MirBool is enough. Although if anyone does implement the Qt
function later then that one doesn't have such luxury. You would have to
return some invalid Point for Qt.
On 14/08/14 16:25, Alan Griffiths wrote:
On 14/08/14 00:31, Christopher James Halse Rogers wrote:
mir_debug_surfa
On 14/08/14 00:31, Christopher James Halse Rogers wrote:
>
>
> mir_debug_surface_coord_to_screen(MirSurface, int x, int y, int* outx,
> int* outy)
>
> in libmirclient-debug and hooked it up to a --debug flag, who would
> object, and what would those objections be?
Returning a bool (or an enum?) t
Urgh. I know you *can* implement it, I'm just strenuously opposed to it
being implemented :).
We absolutely should not implement QWidget::mapToGlobal :)
On Thu, Aug 14, 2014 at 11:59 AM, Daniel van Vugt
wrote:
The function Chris mentions would indeed allow us to implement the Qt
function and
The function Chris mentions would indeed allow us to implement the Qt
function and make it "just work" [QWidget::mapToGlobal()].
Go nuts, Chris :)
On 14/08/14 07:51, Thomi Richards wrote:
On Thu, Aug 14, 2014 at 11:31 AM, Christopher James Halse Rogers
mailto:ch...@cooperteam.net>> wrote:
On Thu, Aug 14, 2014 at 11:31 AM, Christopher James Halse Rogers <
ch...@cooperteam.net> wrote:
> in libmirclient-debug and hooked it up to a --debug flag, who would
> object, and what would those objections be?
Not an objection, but I'd want someone to make a MP against autopilot-qt if
this pro
On Thu, Aug 14, 2014 at 1:12 AM, Gerry Boland
wrote:
> This was option 1 in the original email, and disliked greatly by Thomi.
> It requires AP punching open appArmor rules between clients & unity8
> when running tests. DBus has much greater latency. Also would require
> notion of surface ID, whi
Ok. I think we've explored all the relevant options
If I implemented
mir_debug_surface_coord_to_screen(MirSurface, int x, int y, int* outx,
int* outy)
in libmirclient-debug and hooked it up to a --debug flag, who would
object, and what would those objections be?
--
Mir-devel mailing list
On 13/08/14 10:12, Gerry Boland wrote:
On 13/08/14 13:59, Daniel d'Andrada wrote:
I've yet another suggestion:
unity8 provides a D-Bus API for autopilot to ask "hey, what's the
position/transformation of surface X?". Then AP would apply that
transformation to a surface local coordinate and send
On 13/08/14 13:59, Daniel d'Andrada wrote:
> I've yet another suggestion:
>
> unity8 provides a D-Bus API for autopilot to ask "hey, what's the
> position/transformation of surface X?". Then AP would apply that
> transformation to a surface local coordinate and send the resulting
> global coordina
On 11/08/14 14:09, Gerry Boland wrote:
[...]
Thoughts?
-Gerry
I've yet another suggestion:
unity8 provides a D-Bus API for autopilot to ask "hey, what's the
position/transformation of surface X?". Then AP would apply that
transformation to a surface local coordinate and send the resulting
al Message-
From: "Gerry Boland"
Sent: 12/08/2014 18:40
To: "Christopher James Halse Rogers"
Cc: "mir-devel@lists.ubuntu.com"
Subject: Re: Clients reading their surface position on screen
On 12/08/14 03:33, Christopher James Halse Rogers wrote:
> On Tue, Aug
On 12/08/14 03:33, Christopher James Halse Rogers wrote:
> On Tue, Aug 12, 2014 at 3:09 AM, Gerry Boland
> wrote:
> > Personally I don't like the idea of clients being able to ask for their
> > on-screen position - really there's only a couple of valid use-cases,
> > which are very special. All ap
On Tue, Aug 12, 2014 at 1:13 PM, Daniel van Vugt
wrote:
I think it's mathematically pedantic to say the function does not
exist.
The *best kind* of pedantry!
Acknowledging that such a function would theoretically return a set;
one, multiple or none coordinates (offscreen or occluded), we
I think it's mathematically pedantic to say the function does not exist.
Acknowledging that such a function would theoretically return a set;
one, multiple or none coordinates (offscreen or occluded), we can dumb
it down to the simple case that's important -- give one or zero results:
// Retur
On Tue, Aug 12, 2014 at 12:33 PM, Daniel van Vugt
wrote:
There is a 5th option which would satisfy more (not all) of the
people mentioned:
5. Shell mediates if a client has permission to ask for surface
coordinates. The API is restricted by default. The API _does_not_
return the top-left cor
On Tue, Aug 12, 2014 at 3:09 AM, Gerry Boland
wrote:
Hey folks,
this discussion fizzled out and a conclusion wasn't clear to me. I've
taken the liberty to summarize where the discussion got so far.
The options considered possible (1. was dismissed):
2. AP injects events directly into Qt/unity
There is a 5th option which would satisfy more (not all) of the people
mentioned:
5. Shell mediates if a client has permission to ask for surface
coordinates. The API is restricted by default. The API _does_not_ return
the top-left corner of the surface. Instead it maps a local surface
coordi
Hey folks,
this discussion fizzled out and a conclusion wasn't clear to me. I've
taken the liberty to summarize where the discussion got so far.
The options considered possible (1. was dismissed):
2. AP injects events directly into Qt/unity8
Requires unity8 to be in a "testing" mode. Qt would
On Thu, Jul 24, 2014 at 4:36 PM, Daniel van Vugt
wrote:
Yeah that's problem (2) mentioned below. And not really a problem.
Autopilot only wants to know one point where it can click a button.
The outcome is unaffected if the surface is rendered in multiple
different locations. Just click _one_
Yeah that's problem (2) mentioned below. And not really a problem.
Autopilot only wants to know one point where it can click a button. The
outcome is unaffected if the surface is rendered in multiple different
locations. Just click _one_ copy of the button for the same result.
On 24/07/14 14
On Thu, Jul 24, 2014 at 4:01 PM, Daniel van Vugt
wrote:
Just remember to map points like the Qt interface does:
Point screen_coord = mir_surface_coord_to_screen(surface,
client_coord);
So we are covered for arbitrary 3D transformations (don't assume
windows are on screen as rectangles).
Just remember to map points like the Qt interface does:
Point screen_coord = mir_surface_coord_to_screen(surface, client_coord);
So we are covered for arbitrary 3D transformations (don't assume windows
are on screen as rectangles).
That only leaves two problems which are not really problems:
On Thu, Jul 24, 2014 at 12:03 PM, Daniel van Vugt
wrote:
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
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;
On Thu, Jul 24, 2014 at 3:00 AM, Robert Carr
wrote:
> 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 pre
Chiming inbut 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 p
On Wed, Jul 23, 2014 at 5:05 AM, Christopher James Halse Rogers
wrote:
> On Wed, Jul 23, 2014 at 7:11 AM, Thomi Richards
> wrote:
> …
>>
>>
>> This may, or may not all be true, but none of it helps solve the problem
>> :)
>>
>>
>> I think this conversation is drifting away from the original point
On Tue, Jul 22, 2014 at 11:11 PM, Thomi Richards
wrote:
> Hi,
>
> On Tue, Jul 22, 2014 at 8:01 PM, Thomas Voß
> wrote:
>>
>> so reading Gerry's initial mail, it seems to me that autopilot does
>> not actually want to deal with absolute screen coordinates (and take
>> on the burden of figuring out
On Wed, Jul 23, 2014 at 7:11 AM, Thomi Richards
wrote:
…
This may, or may not all be true, but none of it helps solve the
problem :)
I think this conversation is drifting away from the original point.
Are there any strong objections to making the existing Qt API "just
work" on mir?
Fun
I think we can make QWidget::mapToGlobal() work pretty easily. It just
requires a new function in libmirclient under the hood first.
That's such a simple task, we should just do it. If it's helpful to
accessibility then great. But I expect accessibility to require more
work later.
On 23/07/
On Tue, Jul 22, 2014 at 05:52:42PM EST, Christopher James Halse Rogers wrote:
> >Qt's accessibility framework also needs to be able to present this
> >information via at-spi to accessibility tools such as Orca.(1) This is
> >probably something that is more to do with Qt internals working with Mir,
Hi,
On Tue, Jul 22, 2014 at 8:01 PM, Thomas Voß
wrote:
> so reading Gerry's initial mail, it seems to me that autopilot does
> not actually want to deal with absolute screen coordinates (and take
> on the burden of figuring out multi-monitor, multi-dpi cases on its
> own) but instead wants to sa
Hey all,
so reading Gerry's initial mail, it seems to me that autopilot does
not actually want to deal with absolute screen coordinates (and take
on the burden of figuring out multi-monitor, multi-dpi cases on its
own) but instead wants to say: Please Mr. Mir, for this surface with
ID id, send an
If accessibility and Autopilot can live with a point (centre of a
widget) rather than needing an accurate region then we can just deal in
one point per widget. And that keeps anpok's dream alive of perfect
input mapping in 3D shells :)
On 22/07/14 15:52, Christopher James Halse Rogers wrote:
On Tue, Jul 22, 2014 at 11:23 AM, Luke Yelavich
wrote:
On Tue, Jul 22, 2014 at 09:42:42AM EST, Gerry Boland wrote:
Hey folks,
in working on QtCompositor, I stumbled across a problem ([1]).
Autopilot needs to know the position of items in an application
(buttons, etc) in screen coordinat
Hi,
On Tue, Jul 22, 2014 at 1:42 AM, Gerry Boland
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 w
On Tue, Jul 22, 2014 at 10:04 AM, Thomi Richards
wrote:
Hi,
I commented on the bug, but I may as well comment here:
On Tue, Jul 22, 2014 at 11:42 AM, Gerry Boland
wrote:
3. Mir let the clients find their surface's screen position
I'm pushing for this solution, for a variety of reasons.
"making *life* maximally simple"
On 22/07/14 09:26, Daniel van Vugt wrote:
What we could do is map point-to-point so as to be ready for correctly
supporting arbitrary 3D transformations of the surfaces being touched,
but let the shell itself make the assumption that it only ever displays
things
What we could do is map point-to-point so as to be ready for correctly
supporting arbitrary 3D transformations of the surfaces being touched,
but let the shell itself make the assumption that it only ever displays
things as flat. Thus we can:
Point top_left = mir_surface_coord_to_screen_coo
On Tue, Jul 22, 2014 at 09:42:42AM EST, Gerry Boland wrote:
> Hey folks,
> in working on QtCompositor, I stumbled across a problem ([1]).
>
> Autopilot needs to know the position of items in an application
> (buttons, etc) in screen coordinates - not surface. It needs that as it
> generates inputs
Sounds like a reasonable request.
As a matter of purity Mir has tried to hide compositor information like
screen position from clients, which is otherwise a good idea.
Until now we've dithered between two approaches:
(a) Support arbitrary 3D transformations but only support input
correctly
Hi,
I commented on the bug, but I may as well comment here:
On Tue, Jul 22, 2014 at 11:42 AM, Gerry Boland
wrote:
> 3. Mir let the clients find their surface's screen position
I'm pushing for this solution, for a variety of reasons. The main one is
that the QWidget::mapToGlobal call is what
Hey folks,
in working on QtCompositor, I stumbled across a problem ([1]).
Autopilot needs to know the position of items in an application
(buttons, etc) in screen coordinates - not surface. It needs that as it
generates inputs via uevent, which are defined in screen coordinates.
To calculate abso
53 matches
Mail list logo
