=== salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [07:21] mzanetti, did Germany explode yesterday? [07:32] Saviq: http://www.youtube.com/watch?v=IynteMtSBxo&app=desktop [07:34] Saviq: it was raining quite heavily. so it wasn't too bad [07:36] mzanetti, yup, that one's gone viral ;) [07:45] mzanetti, pushed a commit or two to https://code.launchpad.net/~saviq/unity8/refactor-scopeitem/+merge/225745 [07:48] mzanetti: hehe :) [07:49] Mirv: oh hi! welcome back [07:49] mzanetti: o hai! thanks! [07:50] mzanetti, in lieu of Cimi, could you have a look at the last commits in https://code.launchpad.net/~saviq/unity8/refactor-carousel-activation/+merge/225743, too? 1029+ [07:50] ok [07:50] thanks [08:01] Saviq: but I thought Cimi would be around for today still? [08:01] mzanetti, yeah I'm not actually clear on when he's away... [08:03] there's still 4 unreviewed launcher branches :/ [08:04] * Saviq needs to reboot the modem... [08:13] mzanetti, thanks, btw, I talked to John yesterday, filed a design bug: https://bugs.launchpad.net/ubuntu-ux/+bug/1339413 [08:13] Ubuntu bug 1339413 in unity8 (Ubuntu) "Emblems for apps that are not pinned to launcher don't show up" [Undecided,New] [08:14] mzanetti, wdyt? [08:14] need to test [08:14] Saviq, confirming that my yesterday's issues in 018 are fixed [08:14] oh... right [08:14] Saviq: well... yeah... if there is no such icon in the launcher, yes [08:14] mzanetti, that's why I said it's a design bug [08:15] Saviq: and what is the question? [08:15] mzanetti, what do you think, is all :) [08:15] I think it makes sense... do I need to do that this week still (before freeze etc) [08:15] ? [08:15] mzanetti, not at all [08:15] ok... [08:15] mzanetti, it's a design question first [08:16] so yeah... imo it makes sense to add such things to the launcher [08:16] mzanetti, I wasn't even asking what do you think about impl it ;) [08:16] mhr3, great [08:16] mhr3, running through the test plan now [08:17] Saviq: btw... yesterday I noticed that we have 250 open bugs in unity8 where at least 50 them are either fixed or not valid any more... [08:17] mzanetti, yeah, if only we had time to triage [08:17] tried to collect the ones that will be fixed by QtComp at least [08:18] mzanetti, it'll probably be a (pre-)London exercise to clear it up [08:18] yeah, that seems sensible... well, I'll put some clean up of that on my low prio todo list too [08:18] maybe I can help a bit with it [08:18] mzanetti, sure, I didn't say necessarily *I* was gonna do it ;) [08:18] :D [08:19] me neither [08:19] mzanetti, we just need someone who pisses me off :D [08:19] any takers? [08:19] * mzanetti hides [08:19] Saviq: sorry man, i'm busy with the dash overview ;) [08:20] ;) [08:31] we don't have the paper folded background anymore or never had it? [08:31] * tsdgeos is fuzzy [08:31] tsdgeos, we still do :) [08:31] just not on the desktop? [08:31] don't see it there [08:31] tsdgeos, yes, there too [08:32] lol [08:32] i was running tryDash *_* [08:32] tsdgeos, yeah thought so ;) [08:50] mzanetti, oh noes, there's autopilot tests relying on the search indicator [08:51] Saviq: hmm... ok. let me fix that [08:51] Saviq: btw. I'd say temp scopes are missing a busy indicator for the time where data isn't fetched yet [08:52] Saviq: same when changing a department [08:52] mzanetti, they always did [08:52] mzanetti, except on landscape [08:52] yeah, I know... but it wasn't that much of a problem until now [08:52] mzanetti, but agreed, we should find a better place for it than the search entry [08:52] should I file a bug about it? [08:53] mzanetti, yeah, do, unity8 + ubuntu-ux [08:53] ack [08:53] mzanetti, other ap tests fail because they expect a single PageHeader [08:53] mzanetti, 5 failures in total [08:54] ok... 5 is ok. will fix [08:54] mzanetti, I'll kick ci on new-header to get a baseline [08:54] ok [08:56] https://bugs.launchpad.net/ubuntu-ux/+bug/1339595 [08:56] Ubuntu bug 1339595 in Unity 8 "scopes are missing an ActivityIndicator while they fetch data from the network" [Undecided,New] [10:20] Saviq: are we supporting search in dash overview? [10:20] for RTM i mean [10:20] tsdgeos, we said yes [10:20] ok [10:21] and suddenly there's a back button in search [10:22] we don't have that in dash do we? [10:22] maybe in new dash? [10:23] i mean new header [10:23] tsdgeos, yeah we do now [10:23] ah nice [10:24] tsdgeos, it'll land soonish [10:24] tsdgeos, but you should have it already if you based off of scope-customs [10:24] yep [10:24] cool [10:28] Saviq: hmmmm [10:28] Saviq: we have something called scopeStyle in qml/Components [10:28] doesn't really seem "abstracted" [10:32] tsdgeos, where? [10:32] PageHeader.qml [10:32] property var scopeStyle: null [10:33] tsdgeos, well, yeah, I just added it [10:33] sure [10:33] i mean i realized [10:33] tsdgeos, PageHeader is scope-specific in any case, probably should just move to Dash// [10:33] having something with scope in the name in there is a bit weird [10:33] or that :D [10:33] tsdgeos, or we might abstract it again and then wrap it in ScopePageHeader or something [10:34] tsdgeos, but agreed, needs resolving [10:34] tsdgeos, since we use it in HUD as well... [10:35] just call it style [10:35] and be done with it :D [10:37] Hey guys. I have a device that is currently locked up on the welcome screen. I've got 3 crashes in var/crash one of which is Qt5 the other 2 are indicators. Is there anything of use I can get for you that might lower down the issue some? [10:43] mzanetti: ping [10:48] tsdgeos: pong [10:49] mzanetti: the newheader seems to have a gray line on the top [10:49] is that on purpose or by mistake? [10:49] * mzanetti looks [10:50] mzanetti: http://i.imgur.com/WrMJOfz.png this is a header with y: 10 [10:51] tsdgeos: hmm, no, its not on purpose [10:51] it's harder to notice on the dash [10:51] since it's there all the time [10:51] and similar in color to the background [10:51] yeah [10:51] tsdgeos, your "Done" button is outside the window, kudos! [10:51] ;) [10:51] but in the overview it shows [10:52] Saviq: lol [10:53] tsdgeos: can you press the search button in here? [10:53] mzanetti: yes, why? [10:53] tsdgeos: to see if the search header has the grey line on top too, or if the one we see in here is attached at the bottom of the search header [10:53] ah [10:53] it "travels" down [10:54] is there a new one coming in at the top? [10:57] nope [11:00] tsdgeos: hmm... ok... I did tell the PageHeadStyle to no paint a separator [11:00] tsdgeos: currently investigating in AP tests. I can investigate in this after that [11:00] mzanetti: sure, no hurry, it's just a minor visual thing [11:01] ack === MacSlow is now known as MacSlow|lunch === pete-woods is now known as pete-woods-lunch === alan_g is now known as alan_g|lunch === MacSlow|lunch is now known as MacSlow [12:38] mzanetti, t'is me again, how's autopilot? [12:46] damn, ran out of disk space, now my user account corrupted [12:46] Saviq, something missing in 018? [12:46] mhr3, mzanetti's fixing ap tests [12:46] mhr3, should land real soon [12:46] doing the final run [12:46] greyback, uh oh [12:46] individually all the failing ones are passing now === alan_g|lunch is now known as alan_g [12:50] k, thx [12:53] mhr3, do we support opening scopes through departments? [12:53] Saviq, no [12:53] mhr3, and it was never discussed was it? [12:54] someone did have the idea, we didn't like it [12:54] one's certain, UX for it would suck [12:54] indeed [12:54] I'd get so confused when this would happen [12:55] Saviq: Would there be a chance to get this in the work pipeline sooner than later :)? https://bugs.launchpad.net/unity8/+bug/1326470 (notably, I'm interested in the "default uncollapsed state when there is only one category" really) [12:55] Ubuntu bug 1326470 in unity8 (Ubuntu) "Scope author should be able to set the number of collapsed results to show" [Undecided,Confirmed] [12:55] Saviq: we got that from here btw: https://docs.google.com/a/canonical.com/document/d/1engc5TPtQC9iI8zziMxx9DLVY74b4bvsnPvGBVb95YI/edit [12:55] dudes, one at a time [12:56] Saviq, oh and can we get also [another random item] ;P [12:56] i wasn't asking for something this time though :) [12:57] ;) [12:57] * karni stands in the queue [12:57] ha! [12:59] mhr3, are you sanitizing collapsed-rows? [13:02] Saviq, you mean clamping to 1-2? [13:02] no [13:03] Saviq, i was actually looking at that piece of code when doing the see more, there's an issue - if the scope sets it to 0, shell will consider it unset and use 2 [13:09] mhr3, that's fine, I'll fix shell [13:10] Saviq, you probably want to fix that in the grid-see-more branch [13:10] mhr3, nice bump ;) [13:10] Saviq, and maybe fix the other issues with it? :) === pete-woods-lunch is now known as pete-woods [13:22] Saviq: I've fixed the 5 ap tests that were failing [13:22] however, now I had others fail (unrelated to the pageheader change) [13:30] mzanetti, which ones? [13:30] Saviq: lifecycle [13:31] mzanetti, one it's flaky [13:31] Saviq: Assert(Greeter.created, True) [13:31] mzanetti, btw, testing speed-up: [13:31] while true; do sleep 1; status unity8 | grep -q killed && pkill unity8; done [13:31] on the device [13:31] huh? [13:32] mzanetti, it will convince unity8 to exit when upstart's asked it [13:32] mzanetti, so it doesn't take a full minute to go away... === _salem is now known as salem_ [13:35] mzanetti, just push your fixes to the branch please [13:37] which ones? [13:42] mzanetti, you did already [13:42] mzanetti, I meant the ap ones [13:43] yeah, for the PageHeader [13:43] didn't really investigate in the lifecycle ones === larsu_ is now known as larsu === Zhenech_ is now known as Zhenech [14:00] mzanetti, you really need to prefix my name if you want a response from me, won't notice otherwise ;) [14:05] I know :P [14:19] mzanetti, so... clip corners... did you consider putting the icon in the clipper, rotate the clipper and unrotate the icon? [14:21] mzanetti, also, wonder if the clipping should happen when dragging a clipped icon, too? [14:22] Saviq: not sure I understand the first question [14:22] vesar: your opinion on Saviq's second question? ^^ [14:23] mzanetti, instead of the mask, you could put the icon in an Item { clip: true; rotate: 45 } or so [14:23] ah.... yeah, that'd probably work too [14:23] mzanetti, should be faster than another texture lookup [14:23] thik so? [14:24] Saviq: think so? [14:24] I don't know tbh [14:24] mzanetti, yeah, texture lookup you need one per pixel, whereas with clipping you just clip away with geometry [14:25] mzanetti, obviously depends on how it's really implemented, but if you think about it... [14:25] hmm, well, can change it if you think its better... [14:25] mzanetti, I was told texture lookups are quite expensive (hence blur is difficult) [14:25] mzanetti, would be a bit easier to understand IMO, too [14:25] Saviq: not sure why blur would do a texture lookup [14:26] mzanetti, huh? [14:26] oh right.. [14:26] mzanetti, it needs to consider $however_many pixels around the current one [14:26] yeah, but... that's like evaluating 1024 pixels per pixel [14:26] Saviq: this one is just 1:! [14:26] 1:1 [14:27] mzanetti, still [14:27] but sure, I don't mind changing it... Not sure why I didn't have the simple idea myself :D [14:27] probably because I wanted to learn how to do it with a shader [14:27] mzanetti, it's not actually that bad, when blurring you're only doing horizontal and vertical, not around [14:28] mzanetti, so it's like a dozen lookups or so [14:28] mhm... makes sense [14:28] depending on the blur size [14:28] and the blur mode too [14:28] mzanetti, sure [14:29] mzanetti, http://sunsetlakesoftware.com/2013/10/21/optimizing-gaussian-blurs-mobile-gpu is a good read [14:29] cool. thats interesting [14:29] ok... will change it to just do a regular clip then [14:30] Saviq: I'll track down vesar on the other question [14:30] mzanetti,about the second question. yeah I noticed that when testing the branch and asked Esti (who created the visual) because I felt is should clip also when moved around. But her opinion was that it's ok like that. So not clipping when dragging. This because the the metaphor with the clipping corner is launcher background material covering the icon. Those two to be united. So when it's dragged away it's ok not to clip. [14:31] mzanetti, sorry for the messy lengthy answer. But basically it's been noted and run through with visual guys and can be left as it is. cool with that? [14:31] vesar, yeah, when dragged away... problem is it happens as you long-press, too :| [14:31] vesar: it wasn't messy. [14:32] vesar, so when just getting to the quicklist, the corner goes "blink" [14:32] but that's kinda ok looking at it from Esti's view [14:32] as you basically start the drag, that would indicate you got it out of the launcher [14:33] if you then release it, it'll go back in [14:33] Saviq, mzanetti. Oh ok I see. No we don't want any blinking when longpressed. [14:33] mzanetti, well, you should have to drag it "out" from under the material then ;) [14:33] but when icon detaches from the background then it's ok not to clip anymore [14:33] mzanetti, so we'd need a dragging threshold probably [14:34] vesar: we'll lose any indication of "you can drag now" [14:34] mzanetti, so you only move the icon away when you pass a 1GU or something [14:34] that's what's happening already [14:34] hmm, that [14:34] mzanetti, not with the corner it's not? [14:34] detaching from it's original position is the key. So when ever the drag to organize threshold is exceeded and the quicklist hides and item starts to move with your finger. [14:36] mzanetti, Savic, just checked the current implementation and it's actually not as I remembered it. [14:36] vesar: what I mean is: if you longpress, the quicklist pops up. That indicates: "You triggered the longpress action. Now use the quicklist or not" [14:36] vesar: but it doesn't indicate in any way that "Oh, and btw, you can also drag it now" [14:38] mzanetti, well we don't really have any indication that you can drag it now. But I see where you're coming from. That by unclipping the corner we would indicate that you can drag it now too. right? [14:38] vesar: it had one with the old highlight [14:38] vesar: but we removed that. so the clipping corner would somewhat do that [14:38] vesar: removing that we don't have anything left in that regard [14:40] mzanetti, to be honest now that I'm testing it with the latest build I cannot see any highlight indication. [14:41] vesar: no. we dropped that with the new border glow/shadow [14:41] mzanetti, ok I do see it. But anyone not knowing its existence doesnät [14:41] doesn't [14:41] yeah well.. [14:42] mzanetti, but I don't have the new highlight in this build do I [14:42] that should be landed already, yes [14:43] mzanetti, should it? [14:43] mzanetti, I'm having the old version then. dark highlight at the top of the icon and bright at the bottom [14:43] mzanetti, the first launcher things are only in silo now [14:43] mzanetti, and I was reviewing the rest today [14:43] Oh, I thought 2 or sow where already through [14:44] Saviq, mzanetti: at least the icon spacing change has landed [14:44] mzanetti, hmm maybe, there were so many! [14:44] right, the new item glow didn't land yet [14:45] nope, I just reviewed it today [14:45] spacing's the only thing that landed [14:45] well anyways. vesar when should the clipping of the corner happen? [14:46] on longpress or on drag start (when the space where it was shrinks) [14:46] err. go away [14:47] mzanetti, Saviq: the shrinking seems to happen only later. Just a sec I formulate it properly [14:48] yes, the shrinking happens when you dragged more than 1 grid unit [14:48] mzanetti, no. try it. [14:49] vesar: oh right... that's when the quicklist hides again [14:49] I meant that [14:49] mzanetti, yes and that's the time when the icon becomes whole again. [14:50] ok [14:50] mzanetti, other icons desaturate, quicklist disappears, icon unclips (user enters organizing mode) [14:50] mzanetti, And don't worry about the highlight we used to have. I don't think we need that anyway. [14:51] ok [14:54] Saviq: asking here as it might help others, so i need to use "send" on apport-cli when i experience crashing to process the crash files & it'll give me a url to folow to complete the lp bug [14:54] kgunn, yup [14:54] but does apport "know" if the files are related ? [14:55] or do you have to clean out the old ones ? [14:55] kgunn, no, separate bug per .crash [14:55] and does it just pick the most recent... [14:55] ah [14:55] kgunn, you can only have a single .crash file per process [14:55] kgunn, and it will only get replaced after you uploaded them (apport puts a .uploaded file next to it) [14:55] Saviq: yeah, but sometimes they're related [14:56] kgunn, or remove it, of course [14:56] kgunn, yeah, just cross-mention the other bugs, nothing better than that at the moment [14:56] got it [14:56] in the description or comments [14:57] Saviq: meh... no, the clipping with an item doesn't work [14:57] Saviq: because it clips after the rotation tranformation [14:58] mzanetti, well, not if you add the rotation transformation on the clipper? [14:58] instead of on the icon? [14:58] mzanetti, I'm not saying, just asking, really [14:59] Saviq: yeah. but then I need to counter-correct the values everywhere [14:59] unless I wrap it once again I guess [14:59] right [14:59] that might be best still... [15:18] Saviq: this freaks me out... if I move and rotate, I can't just invert that again, it'll be somewhere else [15:19] I could probably make it work stil, but then there's the 180 degree rotation of the whole launcher coming [15:19] mzanetti, lol, ok, leave it be [15:19] ping mzanetti: do you have some time to talk about your comments on https://code.launchpad.net/~om26er/unity8/launcher_integration_test/+merge/226087 ? [15:19] elopio: sure [15:20] Saviq: heya, is favoriting scopes planned soon? I imagine it was likely waiting on the new-header stuff? === gatox is now known as gatox_lunch [15:21] mhr3: Saviq: where do i get the backgrounds for the scopes in the scopes overview from? [15:22] mzanetti: all your comments are on the prerequisite of that branch, that's mine: https://code.launchpad.net/~elopio/unity8/test_open_app_from_launcher/+merge/225112 [15:22] mhr3: Saviq: it has to be part of the scope, but a new role? [15:22] or what? [15:23] elopio: ah ok... I just came by this omer's branch today and missed the prerequisite [15:23] tsdgeos, in customizations? [15:23] elopio: so still, I don't think we should add all those launcher tests this way [15:23] mzanetti: yes, the diff is weird showing all the things he didn't add them. So don't worry about that. [15:23] elopio: I do understand we want a test that checks if the emulator can find the launcher [15:23] elopio: but I don't agree with having 6 tests just dragging the launcher in and out [15:23] elopio: after all we have about 20 qmltests that verify that [15:24] mzanetti: so, the tests are there not to check the functionality. The check the functionality too, but we need them because otherwise you can break the helpers that we will be using on the UX tests. [15:24] elopio: and one AP test adds > 30 seconds to unity's test suite [15:24] mhr3: ok, suggested name for the thing? [15:24] tsdgeos, wait [15:25] tsdgeos, you need to hardcode the background in the overview [15:25] mzanetti: I know, and I understand. You have those features already covered. But I see no other way to keep the autopilot helperes always working. [15:25] mhr3: Saviq: and we probably also need a way for people to override the font color in dash overview? [15:25] Saviq: ?¿ [15:25] elopio: well, if you really think you need to test all the functions, then please add 1 test that tests the launcher functions, not 2 tests for each function [15:25] tsdgeos, we won't support images as backgrounds, just plain color [15:25] tsdgeos, no, why font color override in dash overview? [15:25] elopio: its enough if one test fails saying "Launcher emulators broken" [15:25] mzanetti: I do the helpers test driven, so I have a teset for every code path. [15:25] Saviq: so color + logo + font color override [15:26] Saviq: we use exactly the same ones we use for the regular scope? [15:26] logo is going to be weird [15:26] since in scope is horizontal and in here is vertical [15:26] elopio: well, I guess that's one of the places where theory and practice differ [15:26] tsdgeos, waaait [15:26] * tsdgeos is waiting :D [15:26] elopio: in terms of usefulness I mean [15:26] tsdgeos, where do you want to put that logo? [15:26] Saviq: in the middle of the card like stuff shows [15:26] tsdgeos, that's just art from the scope [15:27] tsdgeos, nothing special [15:27] tsdgeos, it's the scopes scope that will submit you that [15:27] hmmmmm [15:27] mzanetti: well, it's useful for you when you don't have to wait one extra minute while running your autopilot suite. [15:27] daamit :| [15:27] oh right [15:27] mzanetti: but it's more useful for us when we can pinpoint directly what's the cause of a failed autopilot test [15:27] Saviq: what? [15:28] elopio: can you? [15:28] I don't think so [15:28] we can just reach that point making small tests, each one for a single code path. [15:28] elopio: well... let me put it that way. It took me 6 hours today to debug 5 AP tests [15:29] elopio: And while I understand we need some of them, I don't agree with having 6 that just drag the launcher in and out [15:29] mzanetti: that's bad. Tell me which autopilot tests are so hard to debug, and I can try to improve them. [15:29] elopio: all of them. it takes 32 minutes to find out which ones don't work [15:29] before you can even start working [15:30] mzanetti: that's a necessary evil. We can improve that with paralellization and improving the CI lab, but a high level suite will not take less than 10 minutes, ever. [15:31] That's a long time to get feedback. But if you were to run those same tests manually, it would take you 1 hour and you will miss many details. [15:31] mzanetti: so, don't get me wrong. I understand you here, you invested a lot on a suite with a fast feedback [15:32] tsdgeos, nothing related, ap still not passing here [15:32] mzanetti: that's really cool. But unity also needs to get testability helperes to let us check the quality of the image without doing it manually. [15:32] my fault [15:32] :| [15:33] with this three branches I'm proposing, we will be able to check that all the apps pined on the launcher work. [15:33] elopio: yeah, but still not adding 5 minutes to our test suite just to test the helpers (note: this is not even the high level test you're talking about yet). there must be another way [15:33] and that all the apps preinstalled on the phone can be launched through the click scope. That will save us a lot of time of manual testing. [15:34] hi I'm able to swipe to open and open launcher but tapping on anything (launcher, apps icons) doesn't launch, wonder how I can help to debug [15:34] mzanetti: I'm open to try a different way. [15:34] top not showing anything unusual [15:34] elopio: I still think there should be just one test for the launcher helpers... [15:34] mzanetti: but with the scope changes, the only thing that let us keep running the click scopes tests was that I added tests for the helpers. [15:35] elopio: sure... its ok to have some helpers... but the very best example is the last test: [15:35] tsdgeos probably hates me because of this :) but without the tests you would have changed all the code without noticing that you broke the testability helpers. [15:35] elopio: you don't need to check if cklicking outside the screen does not work [15:36] that's 34 seconds wasted every time one of us runs the suite [15:36] mzanetti: what test are you talking about [15:36] ? [15:36] elopio: test_click_dash_icon_with_launcher_closed_must_raise_exception(self): [15:37] mzanetti: well, that's precisely the king of things we have learned to do not to spend 5 hours debugging a test. [15:37] many many times we try to click something that is not there, just to find a weird autopilot low level exception saying: not found. [15:38] that's an important feature of the helpers. When you try to do something and your preconditions are not met, it must tell you that. [15:38] adding a test for that is the only way to make sure that the exception will always be raised for that case. [15:39] I could use mocks for that one, making it a test that doesn't start unity if you prefer a less cleaner but faster test. [15:40] it will live on your code base, so it's your decision what kind of test do you prefer to maintain. [15:40] elopio: why are you even exporting low level stuff like drag_launcher, etc? shouldn't a higher level test suite just call open_app_from_launcher(index) and that's it? [15:40] but completely removing a test for one code path of the helpers is bad for us. We will not be able to rely on that helper. [15:41] so basically you just export that one function, have 2 test for that and that's it... if the launcher fails to drag in, our qmltests will catch that before [15:42] mzanetti: for that suite of tests launches all the apps from the launcher, yes, only click dash icon is necessary. [15:43] but rick asked for an additional test to make sure that the launcher will be usable always, and for that we need to do things like open the dash, open the keyboar, open the indicators page [15:44] mzanetti: you qml test will not catch errors on the autopilot helpers, like not swiping long enough, or swiping more than what you needed [15:44] elopio: I think what rick asked for in that particular case should be done as a qmltest in tst_Shell.qml [15:44] mzanetti: it won't catch when the assumptions of the autopilot helpers are not met [15:44] elopio: but your one test that does launch_app_from_launcher() would catch that [15:44] and that's enough, we don't need 3 that catch that [15:44] and it won't catch when you change all the underlying code and update the qml tests, as happened with the scopes changes. [15:46] mzanetti: if you put a test for the integration of the launcher with the osk, you would be pulling an additional dependecy to u8. [15:46] elopio: yes, it would catch that [15:46] mzanetti: lets put an example. There's an open_launcher autopilot helper, that swipes from x1 to x2. [15:46] elopio: not really [15:46] lets say that launcher doesn't have a test [15:47] and designers tell you you have to do the launcher twice as fat. [15:47] you update the qml code, you get qml test failures, you update the qml tests, and you are back to green. [15:47] elopio: I never said you shouldn't have any tests for you r helpers [15:47] how are you going to notice that there's an autopilot test that needs to be updated? [15:47] elopio: but I think your helpers are too low level, and hence you require too many tests [15:48] alesage, it's something going haywire with Qt's event propagation, suddenly only touch events work (and not touch-converted-to-mouse) [15:48]