| === barry` is now known as barry_ | ||
| === barry_ is now known as barry | ||
| greyback | o/ | 16:49 |
|---|---|---|
| elopio | hey greyback. I've tried the tests, and I see the problem. | 17:46 |
| elopio | and I don't see a good solution. | 17:46 |
| greyback | then we need a bad solution ;) | 17:46 |
| elopio | greyback: lets say we hack the autopilot input so when we click, it will do y + panel height | 17:47 |
| elopio | then, I won't be able to click the panel. | 17:47 |
| greyback | elopio: then tests for fullscreen apps will be broken | 17:48 |
| elopio | there are tests where we need to use the panel and the app. | 17:48 |
| elopio | greyback: that too. | 17:48 |
| greyback | right, we can't hard-code it globally | 17:48 |
| greyback | so need to fix the globalRect to return the correct value | 17:49 |
| elopio | that, or on each click of each app test, check if we are running under mir and if so, increase the y value. | 17:50 |
| elopio | for each click, for each test, for each app, that's too much. | 17:51 |
| greyback | except if app fullscreen | 17:51 |
| greyback | it's still hacky | 17:51 |
| greyback | how about testing on tablet and sidestage, where sides stage app is over to the right of the screen | 17:51 |
| greyback | we can do a hack for now, but this is a problem that has to be solved ultimately | 17:51 |
| elopio | yes | 17:52 |
| elopio | greyback: how hard is to make Mir behave as X does? is that not an option? | 17:53 |
| greyback | elopio: Mir & X are quite different. Apps do not know their position on screen. Only unity8 does | 17:54 |
| greyback | (mir being a library that unity8 uses) | 17:54 |
| elopio | greyback: but if you can change whether the app draws over the panel or not, can't you update the x and y properly? | 17:56 |
| elopio | or maybe, I don't know, paint an invisible panel inside the app that's the same size as the top bar, so all the coordinates still make sense? | 17:56 |
| elopio | hum, I suppose you went all over those options already. | 17:57 |
| greyback | "invisible panel inside the app" is what is happening with Mir right now | 17:57 |
| greyback | and we removed that, it's a hack | 17:58 |
| elopio | ah, that's why it used to work. | 17:58 |
| greyback | yep. It was a waste of memory and caused visual glitches | 17:59 |
| elopio | greyback: Here is the only place where I think we have some chance: | 18:03 |
| elopio | http://bazaar.launchpad.net/~autopilot/autopilot-qt/trunk/view/head:/driver/introspection.cpp#L164 | 18:03 |
| greyback | elopio: Is it dynamic? As in, if you're testing an app and part of the test is to reposition the app's window, will it reflect that? | 18:32 |
| elopio | greyback: it should, yes. | 18:32 |
| elopio | at least on X that works. | 18:33 |
| greyback | elopio: that's not a safe comparison :) Mir != X in many ways | 18:33 |
| elopio | greyback: I know. What I'm saying is that if it doesn't work on Mir, we need to fix it. | 18:35 |
| elopio | we need it to work on both. | 18:35 |
| greyback | elopio: sure | 18:35 |
| elopio | but to answer your question: yes, everytime we call globalRect, it's refreshed. | 18:36 |
| greyback | ok cool | 18:42 |
| greyback | thomi: hey, when you've had your morning coffee, can we have a chat? I need your advice | 19:47 |
| greyback | and help probably | 19:47 |
| thomi | greyback: heh, sure - we can chat now if you like | 19:47 |
| greyback | thomi: ok cool. So we've been working on a thing called QtCompositor, which changes how Mir renders stuff to screen | 19:48 |
| greyback | part of those changes is problematic to autopilot | 19:49 |
| thomi | uh oh | 19:49 |
| greyback | with the old (current) architecture, every application got a fullscreen surface, and it deliberately kept an invisible border at the top, so the app contents would not be covered by the panel | 19:49 |
| greyback | the new (qtcomp) arch, the application gets a surface of the exact size it needs, and that surface positioned under the panel | 19:50 |
| thomi | ok | 19:50 |
| greyback | it seems that AP tests for Mir are injecting input events via uevent. Those events must be in screen coordinates. | 19:51 |
| thomi | yes, they should be | 19:51 |
| greyback | when the app had a fullscreen surface, the surface coordinates = screen coordinates | 19:51 |
| thomi | ahhh | 19:51 |
| greyback | but now with qt comp, that is no longer the case | 19:51 |
| thomi | I see where you're going with this :) | 19:52 |
| greyback | :) | 19:52 |
| thomi | so, in libautopilot-qt, we ask Qt to translate each widget's coordinates to screen-space | 19:52 |
| thomi | and report those back to the autopilot test | 19:52 |
| thomi | so In the past, Qt knew enough to be able to do that translation | 19:52 |
| thomi | let me find the code real quick, one second | 19:53 |
| greyback | yeah, X let Qt find the current screen position of the window. However Mir does _not_ | 19:53 |
| barry | thomi: hi. i wasn't very helpful about those 64 datetimes :/ | 19:53 |
| thomi | greyback: https://bazaar.launchpad.net/~autopilot/autopilot-qt/trunk/view/head:/driver/introspection.cpp#L171 | 19:54 |
| thomi | barry: I'll take a look in a moment and get back to you - you'll be online in 30 minutes or so? | 19:54 |
| barry | thomi: yep | 19:54 |
| greyback | thomi: with qtcomp, the only thing which knows the current surface position is unity8 | 19:55 |
| thomi | greyback: so if we can't do that, this is potentially a very large problem | 19:55 |
| thomi | hmmm | 19:55 |
| greyback | thomi: what I can do is expose that information out of unity8 somehow, either via AP helper, or dbus at the worst. | 19:56 |
| greyback | but that ofc means AP depends on unity8 | 19:56 |
| thomi | well, we can make it depend on unity8 on the phablet devices only for now | 19:56 |
| thomi | and we really need to be able to get that information without having to put u8 into testability mode | 19:57 |
| thomi | which means some sort of separate IPC, and dbus seems appropriate | 19:57 |
| greyback | ack | 19:57 |
| thomi | so this is a bit of an engineering problem from our side, but I'm sure it's solvable | 19:57 |
| thomi | hmmmk | 19:57 |
| thomi | The easiest way to do it would be to detect that we're on mir in autopilot-qt and do the dbus call there | 19:58 |
| thomi | so autopilot itself wouldn't have to change | 19:58 |
| greyback | ok | 19:58 |
| thomi | and once we're doing that, we may as well store the surface coordinates in the app somehow | 19:59 |
| thomi | however, that means making sure all apps can access the new u8 dbus interface (apparmour etc) | 19:59 |
| greyback | how to identify a surface? appid would be unique, but is that info available? | 19:59 |
| thomi | hmmm, not AFAIK, not in autopiot-qt anyway | 19:59 |
| thomi | greyback: could you use the caller from the dbus call? | 20:00 |
| greyback | thomi: possibly yes | 20:00 |
| thomi | so the u8 interface would simply be "tell me my surface geometry" | 20:00 |
| greyback | makes sense | 20:00 |
| thomi | greyback: does the surface geometry ever change? | 20:01 |
| thomi | Presumably it will when the app moves from the side stage to the main stage | 20:01 |
| greyback | thomi: it can | 20:01 |
| greyback | yep | 20:01 |
| greyback | also device rotation will resize the app surface (moving the panel) | 20:01 |
| thomi | ok, so ideally we'd like a dbus signal for when that happens so we don't need to make this dbus call every time | 20:01 |
| thomi | ..for when either of those things happens :) | 20:01 |
| thomi | like 'geometry_changed(new_geom)' | 20:02 |
| greyback | but how to identify that surface? | 20:02 |
| thomi | ahhh | 20:02 |
| thomi | hmmm | 20:02 |
| thomi | ugh | 20:02 |
| greyback | tbh the app knows when its surface has resized | 20:02 |
| greyback | it doesn't need dbus to tell it that | 20:03 |
| greyback | but repositioned... | 20:03 |
| thomi | hmmmm | 20:03 |
| thomi | but I'm not convinced that autopilot-qt knows that | 20:03 |
| thomi | so, taking a step back here, there is another option | 20:03 |
| thomi | which is to inject input events directly into the Qt event loop directly from autopilot-qt | 20:04 |
| greyback | AP-qt should be able to connect to the widthChanged and heightChanged signals on the QQUickView/Window | 20:04 |
| thomi | hmmmm | 20:07 |
| thomi | ap-qt has a rather limited view of the application tree. It can be tricky to find the specific node we want | 20:07 |
| thomi | ugh | 20:08 |
| greyback | thomi: re inject-into-qt, it has a similar issue, those are just relatively positioned input events, Qt will not know then need to be transformed to the coord space of the surface | 20:08 |
| thomi | yeah | 20:08 |
| thomi | hmmmm | 20:09 |
| thomi | ok, so what about if we got the geometry information from autopilot itself | 20:10 |
| thomi | we could then pass u8 the app id | 20:10 |
| thomi | crap, we can't monitor signals from AP at the moment | 20:11 |
| greyback | thomi: pid is unique and something we could use to identify surfaces | 20:11 |
| thomi | ok, we have that too | 20:11 |
| greyback | can send signals: surface with pid x has a geometry change | 20:11 |
| thomi | so the problem doing it from the AP client side is that we can't monitor dbus signals from the test | 20:12 |
| greyback | no? oh | 20:12 |
| thomi | because we don't have an event loop running, since the test runner is all synchronous calls | 20:12 |
| thomi | and python-dbus won't run an event loop in a thread :( | 20:12 |
| greyback | sux | 20:12 |
| thomi | we could hack something together with multiprocessing, but... that'd be awful | 20:13 |
| thomi | greyback: It seems to me like the best option here is to expose the surface geometry information to Qt in such a way that the 'mapToGlobal' call continues to work | 20:15 |
| thomi | greyback: to my mind, we're braking the contract between Qt and whatever sits above it if we don't supply that information any more | 20:15 |
| thomi | and, while I'd be happy hacking around it at a lower level, it seems like there's going to be some implementation issues no matter how we do it | 20:16 |
| thomi | I don't know anything about that interface, but is it not possible to do the work required there, so that method call continues to do the right thing? | 20:16 |
| balloons | hey thomi, we should chat about when you get some time https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1328600 | 20:16 |
| greyback | thomi: I can't say I'm a big fan of that. I don't see why an app really needs to know its position on screen. But I'll put it to the Mir guys | 20:17 |
| thomi | greyback: well, the point isn't so much whether it needs to know or not | 20:17 |
| thomi | greyback: the point is that the API exists - there's a contract between Qt and the platform it runs on, and you're breaking that | 20:18 |
| thomi | balloons: ok, there's a queue for my attention at the moment, I'll add you to it :) | 20:18 |
| thomi | greyback: but like I say, I have no idea how much work that is. If it's less than 2 weeks development time, it's likely to be the fastest solution IMO | 20:19 |
| thomi | 'cos any effort that involves refactoring autopilot / autopilot-qt is going to be rather slow and tedious | 20:19 |
| greyback | thomi: again I disagree, a pre-existing client API should not define the features of Mir. | 20:19 |
| greyback | but I'll see if the Mir team are happy to expose this info | 20:20 |
| thomi | greyback: I agree that it should not, but in this case it does. Autopilot won't be the only app that makes use of that Qt method, sooner or later something else will break | 20:20 |
| thomi | ideally that method would be part of a Qt platform module, or similar | 20:20 |
| thomi | so different platforms can define how much they expose | 20:20 |
| thomi | but as it is, being a method on QWidget, you kind of have a responsibility to provide it, or you're breaking API | 20:21 |
| thomi | greyback: anyway, talk to the mir guys, and see what they say. I wonder if you could CC me in on that email please? | 20:21 |
| greyback | that api call is backed by the qt platform api, but whether it is implemented is up to the implementer. I think that mapToGlobal is badly documented tbh | 20:22 |
| thomi | ok, well, depending on the amount of work, it may be the shortest path to a solution | 20:22 |
| thomi | unless we can think of something better | 20:22 |
| thomi | or you have a few extra developer-hours to patch autopilot-qt :) | 20:23 |
| thomi | balloons: barry, are you guys available for a quick hangout? | 20:27 |
| barry | thomi: yep, in 2m | 20:27 |
| balloons | sure ^^ | 20:27 |
| balloons | well.. hmm.. I might be voice only, my bw is tapped hard right now | 20:28 |
| thomi | I never understand how I have better internet in Dunedin, NZ than most people seem to in the states | 20:29 |
| thomi | are you guys still running on telegrams or something? | 20:30 |
| barry | i'm voice-only 'cause i'm not wearing pants | 20:30 |
| barry | thomi: i'm on | 20:30 |
| thomi | https://plus.google.com/hangouts/_/g5odhpdf2zamosefl75lvqyrp4a?authuser=1&hl=en | 20:31 |
| thomi | balloons: | 20:32 |
| thomi | ^^' | 20:32 |
| balloons | hopefully there isn't horrible lag :-) I can hear you | 20:32 |
| barry | https://docs.python.org/3/library/datetime.html#datetime.datetime.replace | 20:44 |
| barry | aware = naive.replace(tz=localtz) | 20:45 |
| barry | aware = naive.replace(tzinfo=localtz) | 20:45 |
| thomi | greyback: please also CC veebers in the email with the mir guys, since he'll be coordinating our side | 20:49 |
| greyback | ack | 20:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!