| === barry` is now known as barry_ | ||
| === barry_ is now known as barry | ||
| balloons | elopio, can you have a quick look and chat about switching from'from ubuntuuitoolkit import emulators as toolkit_emulators' to using the custom_proxy_objects? https://code.launchpad.net/~nskaggs/reminders-app/switch-emulators-to-proxy-object/+merge/226706 | 16:51 |
|---|---|---|
| elopio | balloons: in one second. | 16:52 |
| elopio | balloons: you don't need to import _custom_proxy_objects | 16:57 |
| elopio | actually, you should not import the private methods. | 16:57 |
| elopio | *modules | 16:57 |
| balloons | elopio, yes this is really a quick hack, and I realize I'm not doing it right | 16:57 |
| balloons | so I just pushed and figured I'd ask :-) | 16:57 |
| elopio | all the objects are exported in ubuntuuitoolkit, so you can do ubuntuuitoolit.UbuntuUIToolkitCustomProxyObjectBase | 16:57 |
| elopio | balloons: import ubuntuuitoolkit | 16:58 |
| elopio | and replay all toolkit_emulators for ubuntuuitoolkit. | 16:58 |
| elopio | that's it. And thanks for the updates. | 16:58 |
| balloons | elopio, well apparently we found out today all the apps that have the deprecation warning are running under python2, as phablet-test-run sees it as an error and falls back to py2 | 16:59 |
| elopio | balloons: yes, on reminders there's a workaround for that | 16:59 |
| balloons | a fix is being pushed, but I thought I should just clean them all up | 16:59 |
| elopio | and fginther fixed it on phablet tools, but it needs to land. | 16:59 |
| balloons | elopio, well xnox is also looking at it atm.. | 17:00 |
| elopio | balloons, xnox: https://bugs.launchpad.net/ubuntu/+source/phablet-tools/+bug/1327325 | 17:01 |
| ubot5 | Ubuntu bug 1327325 in phablet-tools (Ubuntu) "phablet-test-run will fail if the python3 import prints something to std" [High,Confirmed] | 17:01 |
| balloons | elopio, yep already seen it :-) | 17:01 |
| elopio | ok, I thought xnox was doing the fix again. | 17:01 |
| elopio | oh, yes, he did an alternate fix. | 17:03 |
| elopio | xnox: https://code.launchpad.net/~fginther/phablet-tools/fix-ptr-python3-import-check/+merge/222391 | 17:03 |
| elopio | you even approved it :) | 17:03 |
| xnox | elopio: right yeah, that one was better. | 17:03 |
| xnox | why did it not land yet? | 17:03 |
| * xnox dputs it into the archive. | 17:03 | |
| elopio | xnox: don't know. | 17:03 |
| balloons | ok elopio, so I swapped to as you suggested. however, the other side of the question is I'm still seeing the warning. I was trying to figure out why | 17:07 |
| fginther | xnox, elopio, confusion over the process and not realizing that it had not landed until elopio brought it up again about a week ago :-( | 17:07 |
| elopio | balloons: that's because I'm stupid | 17:07 |
| fginther | (confusion on my part that is) | 17:07 |
| elopio | and ubuntuitoolkit imports emulators, so it will always be thrown. | 17:08 |
| elopio | I need to fix that. | 17:08 |
| balloons | elopio, that was what I was seeing, just wanted a sanity check | 17:08 |
| xnox | fginther: finishing test build and will dput in a sec. | 17:09 |
| balloons | elopio, mind if I try fixing it? | 17:09 |
| balloons | or can you do it quickly? | 17:09 |
| elopio | balloons: not at all. I would appreciate it a lot. | 17:09 |
| balloons | kk.. I'll add it to the list and try and clean everything up | 17:10 |
| elopio | balloons: I think it would be just removing the import emulators from ubuntuitoolkit. | 17:10 |
| elopio | but I'm not sure, so it might be quick but need to confirm. And I didn't have that on my TODO for this week, so feel free to do it. | 17:10 |
| balloons | right, if it's quick I'll propose the mp today, if not it'll go on the list | 17:11 |
| elopio | balloons: an alternate solution if that doesn't work is to swallow the warning when importing it from the __init__.py. | 17:11 |
| balloons | elopio, mm.. ok ack | 17:11 |
| elopio | ping thomi, veebers | 22:30 |
| elopio | we have a big bad problem with the versions of QML components. | 22:30 |
| veebers | elopio: hey how's it gong? | 22:30 |
| veebers | oh | 22:30 |
| thomi | sup elopio? | 22:30 |
| thomi | elopio: I saw the bug | 22:31 |
| thomi | elopio: and directed veebers to it as well | 22:31 |
| veebers | I'm looking at it now | 22:31 |
| elopio | the thing is that when they make a new version of Button, autopilot will see Button11 as the class name | 22:31 |
| elopio | so with a new version of the toolkit, we can break all the existing autopilot tests. | 22:31 |
| elopio | I'm not sure what's a good solution for that. I'm not even sure what's possible and what is not. | 22:32 |
| thomi | elopio: yeah, that's not so cool | 22:32 |
| thomi | elopio: I suspect it'll need some digging in autopilot-qt | 22:32 |
| thomi | elopio: it'd be great to get a reproducer though | 22:32 |
| thomi | the bug report is kind of vague | 22:32 |
| thomi | elopio: can you (or someone else) please prepare a tarball that contains everything we need to reproduce? | 22:33 |
| veebers | thomi, elopio: Yeah I agree, it'll probably need some digging into libauotpilot-qt. elopio can you provide an easy way to reproduce | 22:33 |
| veebers | heh :-) | 22:33 |
| thomi | I'm about 90% more likely to look at it then | 22:33 |
| thomi | wot he sed | 22:33 |
| veebers | elopio: I won't be able to look at it today, not sure if thomi is available sooner. But we'll look at it as soon as we can | 22:33 |
| veebers | thomi: :-) | 22:33 |
| thomi | ... once there's a reproducer there | 22:34 |
| veebers | right | 22:35 |
| elopio | thomi, veebers: if you inspect the clock with autopilot vis you will see a Page10. Would that be enough? | 22:36 |
| thomi | elopio: not really | 22:36 |
| veebers | elopio: a sample test script would be much better | 22:36 |
| thomi | elopio: a *small* example | 22:36 |
| thomi | max 10 lines | 22:36 |
| elopio | I'll try to get one. | 22:36 |
| thomi | the clock has so many components it's impossible to find the rigth one in autopilot-qt | 22:36 |
| elopio | thomi, veebers: I've attached the examples to the bug: | 22:41 |
| elopio | https://bugs.launchpad.net/autopilot-qt/+bug/1341671 | 22:41 |
| ubot5 | Ubuntu bug 1341671 in Autopilot Qt Support "Versioned QML classes are no longer recognized by their public type name" [Undecided,New] | 22:41 |
| thomi | elopio: which file do I run with qmlscene? | 22:42 |
| elopio | thomi: qmlscene -testability name_of_file.qml | 22:44 |
| thomi | elopio: right, but which one | 22:46 |
| elopio | oh, sorry. | 22:46 |
| elopio | thomi: both. We currently have the problem with pages. | 22:47 |
| elopio | so any app using a Page will either show page10 or page11. | 22:47 |
| elopio | but as we almost never use pages directly, it wasn't bad. | 22:47 |
| elopio | now they will do the same with Button, which will be a huge pain. | 22:47 |
| elopio | the first one will show you how it will look for current apps | 22:48 |
| elopio | the second one for the apps when they update the version. | 22:48 |
| thomi | elopio: OK, so you expect the 'Page' component to show up as 'Page', right? | 22:49 |
| elopio | thomi: I'm not sure what to expect. | 22:50 |
| elopio | as a new version might add features, it would be useful to be able to match it by version. Have a helper for Page10 and an different one for Page11. | 22:50 |
| thomi | elopio: well, I can't fix this if you don't tell me what you want :) | 22:50 |
| elopio | but it sucks that old apps will have to update. | 22:50 |
| thomi | right now we present the Qml type name without much change | 22:51 |
| elopio | thomi: what I was going to propose to you and veebers was a meeting with the toolkit guys tomorrow, to find a strategy for new versions. | 22:51 |
| thomi | ugh | 22:52 |
| elopio | thomi: and what I would love to see is being able to match many qml types to a single python class. Something a little better to what we have with the validate dbus method. | 22:52 |
| elopio | but I'm not sure if that's a good strategy to go forward. | 22:52 |
| elopio | we will need a custom proxy object for Button, for example. And that's something you didn't want before. | 22:53 |
| veebers | elopio: not to use versions? ;-) | 22:53 |
| elopio | veebers: yes, make my life easier should be the first option :D | 22:53 |
| veebers | heh | 22:54 |
| thomi | elopio: ack, it's been on my mind for a while | 22:55 |
| thomi | elopio: actually - that's the soluton! | 22:56 |
| thomi | man... I could kiss you right now :D | 22:56 |
| elopio | for the current problems, I think I would be happy with something like this: | 22:56 |
| elopio | class Button(base_proxy): | 22:56 |
| elopio | qml_types = ['Button', 'Button10', 'Button11'] | 22:56 |
| elopio | thomi: no kisses please :) I accept hugs, but not too often. | 22:56 |
| thomi | elopio: well, it'd be similar | 22:57 |
| thomi | elopio: what timeframe is this needed for? I cna throw together a proposal and get you a copy by tomorrow I think | 22:57 |
| thomi | best guess for implementation time right now is about 3 days... | 22:58 |
| thomi | if I do it | 22:58 |
| elopio | thomi: I think we can delay the release of the new button version, but not for long as the deadlines are already passed | 22:58 |
| elopio | but we have never been able to release a toolkit in less than a week, so 3 days sounds perfect. | 22:58 |
| thomi | elopio: writing a spec now. WIll you be around in 30 minutes to read a first draft? | 23:36 |
| elopio | thomi: I will. | 23:37 |
| thomi | ok, will ping you | 23:37 |
| elopio | thomi: you should probably know of all the issues I've been having with the validate_dbus, so we don't hit them again with your proposal. | 23:38 |
| thomi | elopio: I'm aware of some of them anyway, and this will fix that | 23:38 |
| thomi | elopio: feel free to follow along: https://docs.google.com/a/canonical.com/document/d/1dLdjvRbrILs3314dBM7sKazHDJgeFe3i2E5Rk5pJHTM/edit# | 23:38 |
| elopio | thomi: awesome. You can have one kiss. | 23:38 |
| thomi | hmmm | 23:41 |
| thomi | elopio: so you want one unified class called 'Button' that will work for both Button10 and Button11, right? | 23:47 |
| elopio | thomi: yes. | 23:47 |
| thomi | elopio: and the test author doesn't know which one it is? | 23:48 |
| thomi | so, this isn't what you want: | 23:48 |
| thomi | select_single(Button, version=10) | 23:48 |
| elopio | thomi: hum, I haven't thought about that one, but doesn't seem useful for our current case. | 23:49 |
| thomi | so, the one limitation I can't get past right now is that xpathselect has no way to say "select an object whose name starts with 'Button'", or "select an object whose name is one of 'Button10', 'Button11', etc. | 23:50 |
| thomi | although that wouldn't be the hardest thing to add. | 23:50 |
| elopio | thomi: but if you do it matching a substring, it would also match something like ButtonFOO. | 23:51 |
| thomi | elopio: yeah, I think I prefer the second variant | 23:52 |
| elopio | thomi: yes, that's the only want I need. | 23:52 |
| thomi | it would mean that custom proxy classes would need to be updated every time you bumped the version number | 23:52 |
| thomi | but TBH that's probably a good thing. | 23:52 |
| elopio | thomi: that's would mean that we need a custom proxy class on the toolkit per every component that it provides. | 23:53 |
| elopio | for me that's good | 23:53 |
| thomi | elopio: hmmm, yes, it would | 23:53 |
| elopio | but you said it was bad for components like button which will not provide any methods. | 23:53 |
| thomi | that's ok? | 23:53 |
| thomi | yeah, it's a bit icky | 23:53 |
| elopio | well, it makes my life a lot easier. That way I can provide a certified set of helpers, and just concentrate on keeping them working... | 23:54 |
| elopio | if people use something different and it breaks, it would not be my fault. | 23:55 |
| thomi | understood | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!