[03:34] ping veebers, how are you? [03:40] elopio: hey yeah I am, how's things on the new team? [03:41] veebers: it's good. A little lonely at this time. [03:41] I miss working with you on my late night. [03:43] elopio: heh yeah I can attest to the loneliness, missed working with you too [03:46] elopio: what's the haps? [03:48] veebers: not much. Preparing dinner, and about to call it a day. [03:50] elopio: nice, you might be happy to know that I'm working on a branch that will push autopilot to 1.6 as it removes the object registry, all uses of CPOs will be explicit [03:50] although, not sure how much that impacts you nowadays [03:51] veebers: cool! I read your email with the proposal and it's awesome. [03:51] it won't affect my job much, but as soon as things settle down, I hope I can get back to contribute tests to the community apps. [03:53] ah I see, well forget that I mentioned it :-) [03:54] elopio: was there something I can help you with or you just keen to catch up? (which is fine, I'm just on the edge of my seat thinking "What's broken that he wants me to fix") :-) [03:59] veebers: no, just saying hi. === chihchun_afk is now known as chihchun [04:07] elopio: awesome :-) Make sure you stay in touch (I'll do the same) [05:47] elopio: are you still around perchance? (although I suspect you've called it a day) [05:50] veebers: doing some last runs. How can I help you? [05:53] elopio: hey I'm working a a UUITK branch to make the autopilot tests work with the experimental 1.6 version, I'm wanting to get your opinion on the changes that are happening (i.e. am I missing something, will this impact authors in a more destructive way). [05:54] elopio: I'm not expecting you to do more than a cursory glance at the branch [05:54] I don't expect you to do my work for me :-) [05:54] veebers: throw me the branch. [05:55] elopio: one sec, pushing [05:56] elopio: branch: https://code.launchpad.net/~canonical-platform-qa/ubuntu-ui-toolkit/update-for-upcoming-autopilot-1.6/ [05:57] elopio: I'll fire up a MP so it's easier to look at the changes [05:58] elopio: https://code.launchpad.net/~canonical-platform-qa/ubuntu-ui-toolkit/update-for-upcoming-autopilot-1.6/+merge/262045 [05:59] veebers: you have to propose against staging. [06:00] elopio: oh? rats, ok let me delete that MP [06:01] elopio: this one? ~ubuntu-sdk-team/ubuntu-ui-toolkit/staging [06:01] veebers: yes. [06:01] elopio: ok, 2nd time lucky: https://code.launchpad.net/~canonical-platform-qa/ubuntu-ui-toolkit/update-for-upcoming-autopilot-1.6/+merge/262046 [06:15] elopio: ugh, I see there is a translation included there I'll get rid of it [06:15] elopio: also you may notice that the inclusion of this branch gets rid of the 'workarounds' in that diff that I haven't removed yet: https://code.launchpad.net/~veebers/autopilot/1.6-OR-removal_from-proxy-object/+merge/262049 [06:17] veebers: what will happen here if the parent is not a QQuickFlickable? parent = QQuickFlickable.from_proxy_object(parent) [06:19] elopio: yeah this gave me dome thought. As long as nothing QQuickFlickable is called on that object (i.e. tries to select an element that it doesn't contain) nothing will go wrong [06:19] there is no validation made etc. It doesn't check the path or 'validate_dbus'. _but_ it's early days and this could be changed perhaps [06:20] (hence why I'm running it past you) [06:21] veebers: I find it weird. At first I thought it would be nice for it to raise an exception, and we can just catch it in here. [06:21] but this code passes even if we are using a class that extends QQuickFlickable, so the exception won't work. [06:22] hum, but then this can potentially break some things. The definition of is_flickable is not linked to the class name. We return true if it has the properties that a flickable would have. [06:23] elopio: yeah, it's what got me pondering, as we're changing how it all works, originally autopilot kept track of what it might be and magically applied a CPO (generally correctly) but removing the object registry means that there is no link from app -> selected_class etc. [06:24] veebers: yes. I think it's ok. In the future we might need to add a flickable_class argument, so the method supports flickables that are not of type QQuickFlickable. [06:25] veebers: 1176 + return self.select_single(AppHeader, objectName='MainView_Header') [06:25] with this, there are some apps that have a header that's not AppHeader. I think your change is good, as the correct thing to do is to overwrite the method [06:26] but you might have to update some tests in some apps. [06:27] veebers: this I don't understand: [06:27] 1222 + def setUp(self, mainview_class=MainView): [06:27] how can you call a setUp with an argument? [06:28] ah, you are calling it from super(). [06:28] elopio: like: super().setUp(MyArg)? [06:29] :-) [06:29] that's weird, because then you are not able to run a test that doesn't overwrite the setUp. [06:29] generally, I set that kind of arguments as class or instance variables. [06:31] veebers: this looks good. I think it will take some time for me to get used to this new style, but it's a lot clearer. [06:31] elopio: hmm, you could have a point there. I think I originally had it as a class var, that can be changed (haven't had it properly reviewed yet :-)) [06:32] elopio: yeah there will need to be a large mind shift as things work _really_ differently to what they used to [06:32] I hope it's for the better, but I'm looking to minimise that impact and get some feedback from devs about it. Its not going to be released overnight :-\ [06:33] veebers: if you get the whole toolkit suite to work with small changes like this, you are definitely on the right track. [06:34] veebers: kalikiana and timp will be able to give you some useful feedback too. [06:35] elopio: awesome thanks! I'll get the toolkit suite finished (see if it throws me any curve balls) and get the autopilot documentation up to spec to (i.e. porting guide) [06:35] veebers: ok, thanks for this. [06:35] I'm glad I picked the toolkit, I had been toying with the idea of from_proxy_object, and now I think it's a good idea, esp in the context of what it's doing in the toolkit tests [06:35] elopio: nw, thanks for taking the time for looking at it, I know it's not your thing anymore and you have other things to take care of [06:36] veebers: np, I still care about this. And it didn't take a long time, you have it all pretty much solved. [06:37] elopio: sweet, right I need to get dinner before my partner kills me ^_^ [06:37] and I need to get some sleep. [06:37] see you tomorrow. [06:37] sleep well elopio o/ === vrruiz_ is now known as rvr === chihchun is now known as chihchun_afk === pgraner-dr is now known as pgraner [13:23] can someone who works on autopilot please confirm https://launchpad.net/bugs/1465667 ? [13:23] Launchpad bug 1465667 in Autopilot "autopilot ignores class-level conditional skip() decorator" [Undecided,New] [14:07] oSoMoN, you may have to use testtools.skipIf [14:07] oSoMoN, at least that seems to wfm === chihchun_afk is now known as chihchun [14:09] unittest should support it: https://docs.python.org/3/library/unittest.html#skipping-tests-and-expected-failures [14:10] yeah, that’s what I thought too [14:10] but oSoMoN I do seem to remember having the same trouble [14:11] balloons, it might be a bug in testtools, it's not exactly polite in its interaction with unittest [14:13] brendand, a nice way to say it.. polite :-) [19:57] boo! [20:47] dkessel, you scared me! [20:47] :-) === chihchun is now known as chihchun_afk [20:59] howdy svij [21:01] One hour later? Don't think so balloons ;) [21:02] dkessel, hah [22:35] svij, for whenever you read this, I made the updates to calc you needed. There's helpers now so you should be able to finish your test. Pull trunk