[02:58] <AkivaAvraham> Anyone ever run autopilot tests on a device or emulator?
[03:06] <veebers> AkivaAvraham: autopilot is run everyday on Ubuntu Touch devices. It should work with the emulator, but haven't tried myself recently. Are you experiencing issues?
[03:07] <AkivaAvraham> veebers, well I don't have a device, and I need to know the command neccessary to execute tests from a commandline.
[03:07] <AkivaAvraham> veebers, https://code.launchpad.net/~akiva/qtcreator-plugin-autopilot/trunk
[03:16] <veebers> AkivaAvraham: I'm not sure about the emulator sorry, but we use phablet-test-run to run the tests
[03:20] <AkivaAvraham> veebers, okay but question
[03:21] <AkivaAvraham> veebers, is phablet-test-run ran in phablet-shell?
[03:22] <veebers> AkivaAvraham: hmm, my memory is a little rusty in this sense, but I'm pretty sure it makes sure that the noted packages are installed then runs the autopilot command. All this done with a series of 'adb shell' commands.
[03:22] <veebers> but I might be wrong
[03:30] <veebers> AkivaAvraham: sorry that I can't be more help. In a couple of hours more people will be online that could extend what I've said
[04:20] <AkivaAvraham> !ping
[04:20] <AkivaAvraham> veebers, you don't have a device, do you?
[04:22] <veebers> AkivaAvraham: nominally I do, but not right now with me sorry
[05:17] <AkivaAvraham> bzoltan_, The plugin is almost done, however I just need to know what commands are needed to run tests on devices. Namely, I need to know whether I have to ssh into the device using phablet shell. I don't have a device unfortunately.
[05:22] <bzoltan_> AkivaAvraham: So the AP tests of the active project is imported automagically?
[05:23] <AkivaAvraham> bzoltan_, yes
[05:23] <bzoltan_> AkivaAvraham:  Awesome. Let me see that one first.
[05:23] <AkivaAvraham> bzoltan_, okay. Do you want a video?
[05:23] <AkivaAvraham> or the lp?
[05:24] <bzoltan_> AkivaAvraham:  The on device execution might be tricky. The idea is that we use the QtCreator's internal logic.
[05:24] <bzoltan_> AkivaAvraham: preferable lp: please
[05:24] <AkivaAvraham> bzoltan_, okay one sec
[05:24] <AkivaAvraham> https://code.launchpad.net/~akiva/qtcreator-plugin-autopilot/trunk
[05:24] <AkivaAvraham> bzoltan_, ^
[05:25] <bzoltan_> AkivaAvraham:  How is the list updated? I mean if I add new tests ... how they will show up in the list? After build?
[05:25] <AkivaAvraham> bzoltan_, onProjectChanged signal
[05:25] <bzoltan_> AkivaAvraham:  nice
[05:26] <bzoltan_> AkivaAvraham:  I will jump on it with zbenjamin when he joins and give you some feedback.
[05:26] <AkivaAvraham> bzoltan_, I guess I could add an update mechanism; good idea
[05:27] <AkivaAvraham> bzoltan_, look forward to it. Some of the code will be cleaned up; I'm just waiting until I implement device running.
[05:28] <AkivaAvraham> Running the test on the device is easy if it can be done from a regular terminal... as said though; no device so I am out of luck.
[05:33] <bzoltan_> AkivaAvraham:  The emulator should at your disposal
[05:33] <bzoltan_> should be
[05:33] <AkivaAvraham> bzoltan_, it is; does that count as a device?
[05:33] <bzoltan_> AkivaAvraham:  yes, it does
[05:34] <AkivaAvraham> bzoltan_, okay, and if I am in a shell, and the emulator is running, am I running tests using adb or phablet-shell?
[05:34] <bzoltan_> AkivaAvraham:  with phablet-test-run
[05:34] <AkivaAvraham> or am I running tests from my desktop, using a tool that tells the device to run the device.
[05:34] <AkivaAvraham> run the test*
[05:34] <AkivaAvraham> okay
[05:36] <bzoltan_> AkivaAvraham:  you will need to install few autopilot packages in the emulator
[05:36] <AkivaAvraham> bzoltan_, oh okay
[05:37] <AkivaAvraham> sudo apt-get install autopilot3?
[06:09] <bzoltan_> AkivaAvraham: yeps
[06:09] <AkivaAvraham> okay
[07:49] <dholbach> good morning
[09:51] <gventuri> popey: hi. do you reckon it would be possible to arrange a handover with the weather app? We have some new designs ready
[09:55] <popey> gventuri: yeah, I will poke the guys again
[09:56] <gventuri> popey: thanks
[10:08] <JamesTait> Good morning all; happy Monday, and happy Tin Can Day! :-D
[10:26] <AkivaAvraham> !ping
[10:46] <zbenjamin> nik90: ping
[11:32] <AkivaAvraham> pang
[11:46] <mzanetti> rpadovani: popey: next update: http://notyetthere.org/data/com.ubuntu.developer.mzanetti.machines-vs-machines_0.1.3_armhf.click
[11:46] <mzanetti> file size down to 22MB (from the 135 last week) :D
[11:47] <rpadovani> \o/
[11:47] <zbenjamin> aquarius_: do you lan to also ship native components with ucs?
[11:47] <aquarius_> zbenjamin, yep.
[11:48] <aquarius_> that's what makes it most interesting.
[11:48] <zbenjamin> how will that work?
[11:48] <aquarius_> when you submit a component, it contains the binary bit of it compiled for x86, amd64, and arm.
[11:49] <zbenjamin> aquarius_: we are thinking about teaching qmake about ucs
[11:49] <aquarius_> Nope.
[11:49] <aquarius_> well, maybe
[11:49] <aquarius_> A pure qml project does not use qmake
[11:49] <aquarius_> I do not want people writing pure qml projects to have to start *using* qmake.
[11:49] <zbenjamin> aquarius_: we are changing that
[11:50] <zbenjamin> aquarius_: since our pure qml projects come with more than just running qml files, it also needs to "make install" and "update translations"
[11:50] <aquarius_> I think that's a wrong thing to do. When I'm writing a pure QML project, which is most of the time and should be most of the time for most app authors, I do not want to have to think about or care about or even see any compilation stuff. It's both hard and annoying. :)
[11:50] <zbenjamin> using qmlproject for more than prototyping is discouraged even by Qt upstream
[11:51] <aquarius_> That's because Qt upstream think that everybody should be writing C++ projects and using QML for nothing more than UI.
[11:51] <zbenjamin> aquarius_: well when you use QtC most of that is automatic anyway. Right click project -> add file works with qmake projects
[11:52] <zbenjamin> and if you write a qml project without QtC you do not care about projectfiles anyway
[11:52] <zbenjamin> the problem with qmlproject is that we need so many ugly hacks
[11:52] <aquarius_> If you make compilation invisible, and make projects always build fat packages which are compiled for every arch in one package, then I think it's a good idea. Historically, that's been seen as less important, because it's perceived as OK for people compiling code to have to care about architectures, because they're C++ people. That's precisely absolutely the mindset that ucs is trying to fix.
[11:53] <aquarius_> I am very, very firmly of the opinion that I should be able to write nothing but QML, and if I need something that QML doesn't do, I "ucs install whatever" to get a thing which does do it -- and there are no "shadow builds", no architecture stuff, and it builds one single click package.
[11:54] <aquarius_> if that's doable with the stuff you're thinking about, then I am an eager supporter or your work.
[11:54] <aquarius_> *of your work
[11:54] <zbenjamin> aquarius_: yep the pure qml qmake project comes with "all" as architecture
[11:55] <aquarius_> right. I've already put some stuff in ucs which adds the downloaded-binary-component folders to the qmake setup
[11:56] <aquarius_> but having Ubuntu SDK automatically take care of that would, of course, be even nicer.
[11:56] <AkivaAvraham> zbenjamin, bzoltan_ will I be able to get feedback within the next few hours? Or should I join your folks tomorrow?
[11:56] <bzoltan_> AkivaAvraham:  I think tomorrow would be more realistic
[11:57] <AkivaAvraham> bzoltan_, until then my friends
[11:57] <AkivaAvraham> o/
[11:57] <bzoltan_> AkivaAvraham:  I am struggling with the localized chroots right now
[11:57] <bzoltan_> AkivaAvraham:  take care
[11:57] <AkivaAvraham> bzoltan_, did you try yelling at them?
[11:57] <aquarius_> zbenjamin, I'm happy to discuss this stuff in more detail.
[11:57] <bzoltan_> AkivaAvraham:  that is what I am doing ...all the time
[11:57] <AkivaAvraham> And they arent listening? Dang
[11:58]  * bzoltan_ once fixed a bug by looking at it angry
[11:58] <ogra_> you probably need to yell in the right language if it is a localization prob
[11:58] <AkivaAvraham> You could also try spitting on them, or making jokes about its mother.
[11:58] <bzoltan_> ogra_: you do not want to hear angry Hungarian :D
[11:58] <ogra_> :)
[11:59] <zbenjamin> aquarius_:  i wonder if it makes sense to make it possible to pull the source instead of the binaries  for C++ based projects
[11:59] <aquarius_> zbenjamin, I... basically don't care about C++ based projects. I'm sure that pulling the source there is the right thing to do.
[11:59] <aquarius_> But someone writing a C++-based project already has that as an option -- they can go grab the source from Launchpad for a component, and use it.
[12:00] <aquarius_> Someone writing a QML-based project does not have it as an option precisely because they do not understand compilation and should not have to.
[12:01] <aquarius_> ucs is, in my mind, primarily aimed at people who want to write in QML (which I think should be most app authors) but need the occasional-but-common API that QML doesn't provide -- write to a file, get the path to your home dir, etc.
[12:01] <aquarius_> so you "ucs install sil/GetHomeDir" and then import ubuntu_component_store.sil.HomeDir 1.0 in your QML, and carry on writing QML. No compilation required.
[12:02] <zbenjamin> ok
[12:02] <aquarius_> Now, if that ucs command actually quietly downloads the source and adds it to your Run setup, so that the source gets compiled with your project *and you don't notice*, then I'm fine with it.
[12:02] <aquarius_> If adding a component as source alters the way you work with a pure QML project, then I don't want to do it.
[12:03] <aquarius_> It is not at all clear to me that the best way to solve this problem is "make everyone deal with qmake so it's hard all the time", though. :)
[12:07] <aquarius> In particular, I do not see at all why "make install" is required for a pure QML app.
[12:08] <aquarius> Part of the issue here is that everyone who is building the tools to make apps is a C++ person and therefore sees doing things the compile way as being the right thing to do.
[13:08] <om26er_> artmello, Hi! re: https://code.launchpad.net/~artmello/gallery-app/gallery-app-handle_gif_files/+merge/244934
[13:08] <om26er_> artmello, are the .gif supposed to animate as well ?
[13:10] <artmello> om26er_: no, only showing the files
[13:10] <om26er_> ack
[13:13] <om26er_> artmello, How do I test fix for bug 1382109 ?
[13:13] <om26er_> there seems to be no steps in the bug report and the description is not clear enough.
[13:19] <artmello> om26er_: http://paste.ubuntu.com/9784954/
[13:19] <artmello> om26er_: something like that
[13:38] <om26er_> artmello, Hi!
[13:38] <om26er_> artmello, I found this bug on image 202: https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1412442
[13:39] <om26er_> not related to silo 14 though.
[13:41] <artmello> om26er_: I think that could be the same issue nerochiaro reported here #1412432
[13:43] <nerochiaro> artmello: om26er_: same issue, i am looking into it. please mark one of the bugs as duplicate
[13:43] <om26er_> nerochiaro, my bugs have the steps so I'll marks yours duplicate. sounds fine ?
[13:48] <nerochiaro> om26er_: ok
[13:48] <om26er_> artmello, there are no new tests for the new changes, is there a reason for that ?
[13:50] <artmello> om26er_: about the moving to events view, no no specific reason
[13:53] <mivoligo> mzanetti: hi
[13:54] <om26er_> artmello, bug 1382109 needs to have some kind of automated test. Writing an autopilot test should not be too much effort for this.
[14:01] <artmello> om26er_: ok, will work on that
[14:04] <mzanetti> mivoligo: hey ho
[14:04] <mivoligo> mzanetti: I'm done with these ending images
[14:05] <mivoligo> mzanetti: where should I put them?
[14:06] <mzanetti> mivoligo: into the levelpack
[14:06] <mzanetti> mivoligo: just put them top-level into the machines-vs-machines folder
[14:07] <mzanetti> next to the levelpack.json
[14:07] <mivoligo> ok
[14:08] <mivoligo> mzanetti: I'm not entirely happy with them tbh, but their not that bad :)
[14:08] <mzanetti> mivoligo: will have a look at them shortly
[14:09] <mzanetti> mivoligo: ah, got feedback from the testers that the tower popup (to upgrade, destroy etc) should be semi-transparent
[14:09] <mzanetti> will try that to see how it looks
[14:10] <mzanetti> biab
[14:10]  * mivoligo is googling biab
[14:15] <dholbach> hey beuno
[14:15] <beuno> oh-oh
[14:15] <dholbach> so... regarding the appname.devname move....
[14:16] <dholbach> basically we just ask zbenjamin and bzoltan_ to backport qtcreator-plugin-ubuntu and we're done and can move on to documenting things?
[14:16] <dholbach> click-reviewers-tools is already backported AFAIK
[14:16] <bzoltan_> dholbach:  yes
[14:17] <dholbach> bzoltan_, were you planning to backport 1408644 to the sdk release ppa?
[14:17] <beuno> dholbach, yeap
[14:18] <dholbach> ok, c-r-t is confirmed to be backported
[14:18] <bzoltan_> dholbach: yes
[14:19] <dholbach> hum, I can't find it in the commit logs
[14:21] <dholbach> https://bazaar.launchpad.net/~ubuntu-sdk-team/qtcreator-plugin-ubuntu/trunk/revision/321 mentions bug 1400741
[14:21] <dholbach> ok, looks like that was a mistake
[14:22] <dholbach> bzoltan_, zbenjamin: do you already know when you're going to do q-p-u backports again?
[14:22] <bzoltan_> dholbach: I was planning to do one this week. Around Thursday.
[14:22] <dholbach> great
[14:22] <dholbach> bzoltan_, https://bugs.launchpad.net/developer-ubuntu-com/+bug/1408644
[14:23] <bzoltan_> dholbach:  is that enough, or do you need it earlier
[14:23] <dholbach> beuno, ^?
[14:23] <beuno> well, this is in place in production
[14:23] <beuno> the sooner its out there, the less confusion
[14:24] <dholbach> right right
[14:25] <dholbach> beuno, does myapps load for you right now?
[14:25] <beuno> no
[14:25] <beuno> it's down
[14:26] <bzoltan_> beuno: we have other changes bundled with this, so I rather keep the safe backporting process :)
[14:41] <dholbach> beuno, ah, is it back up again?
[14:42] <beuno> dholbach, it is now, yes
[14:46] <dholbach> beuno, hum, can app names include "-"?
[14:47] <beuno> dholbach, yes, but I think it's currently being rejected, bug is WIP
[14:47] <dholbach> ok...
[14:48] <dholbach> beuno, what happens if you change your personal namespace?
[14:48] <dholbach> I just went from com.ubuntu.developer.dholbach to dholbach
[14:48] <dholbach> will this mean that users who already installed some of my apps won't upgrade to new versions?
[14:48] <beuno> dholbach, new uploads go to that
[14:48] <beuno> old uploads are unchanged
[14:49] <dholbach> I'm not sure I understand... what does this mean for users?
[14:49] <aquarius> beuno, am I right in thinking that nobody can use a namespace of "sil" but me, because that's my Launchpad ID?
[14:50] <beuno> aquarius, correct
[14:50] <aquarius> k
[14:50] <beuno> aquarius, well, not enforced yet, but can be enforces on demand
[14:50] <beuno> :)
[14:50] <aquarius> demand.
[14:50] <aquarius> :-)
[14:50] <beuno> dholbach, it means no change
[14:50] <beuno> dholbach, old apps use the same namespace
[14:50] <dholbach> ah ok
[14:50] <dholbach> gotcha
[14:50] <aquarius> I should note that I still think that the namespace rename is a mostly daft idea :)
[14:52] <aquarius> because squatting on namespaces is a lot easier now.
[14:52] <beuno> aquarius, it is, it's also typable!
[14:52] <aquarius> knowing to type org.kryogenix.riddling is, I admit, massively irritating
[14:52] <aquarius> but I won't know anybody's developer name *either*, so I still have to look things up.
[14:53] <aquarius> oh look here's a game by Martin Albisetti, its package name is therefore... beuno.helloworld? What's a "beuno"?
[14:53] <dholbach> aquarius, helloworld.beuno
[14:53] <aquarius> ah, that's slightly better, then :)
[14:53] <dholbach> aquarius, it all makes sense now, right? :)
[14:54] <aquarius> I look forward to the fight when someone registers "electronicarts", or indeed "canonical", as their developer namespace.
[14:54] <beuno> aquarius, we will enforce squatting agressively
[14:54] <beuno> so you'll loose all your users
[14:55] <aquarius> so if the multi-million-dollar SIL Incorporated decide to make Ubuntu apps, they lose to me, right?
[14:55] <aquarius> even though they have a trademark on the name and I don't.
[14:55] <aquarius> this is the problem with single-word namespaces :)
[14:56] <beuno> aquarius, trademarks win, of course
[14:56] <beuno> we have a plan to be able to rename apps on server and client, coordinated
[14:56]  * dholbach knew aquarius was a trojan horse all along
[14:56] <beuno> transparent to users
[14:56] <beuno> in the valid cases
[14:56] <aquarius> unless "we enforce squatting aggressively" means "if someone has a trademark over a single word which is also your name, you don't get to use your own name, and that's just tough because, well, we wanted one single word and ignored advice from a passing handsome ginger bloke that it was a bad idea" :)
[14:57] <beuno> aquarius, we discussed the pros and cons
[14:57] <beuno> usability won
[14:57] <beuno> it doesn't matter on the phone
[14:57] <beuno> it super matters in CLI
[14:57] <aquarius> usability *to snappy users*.
[14:57] <beuno> yes, on the phone, nobody sees namespaces
[14:57] <beuno> so it doesn't matter at all
[14:57] <aquarius> what happens to apps which lose their namespace after they've been published?
[14:58] <beuno> if it was malicious, you loose your userbase
[14:58] <aquarius> specifically: an app which loses its namespace also loses its appid, and so push notifications stop working.
[14:58] <beuno> if it wasn't, the app namespace gets renamed, the users don't see any changes
[14:58] <beuno> you shouldn't hardcode appid's, they should be grabbed from the ENV
[14:59] <beuno> namespaces are changed on new uploads
[14:59] <aquarius> what?
[14:59] <beuno> so you get to do it in a coordinated way
[14:59] <beuno> also, we'll introduce UUIDs
[14:59] <aquarius> so my push server will break? :(
[14:59] <beuno> which will likely be a better candidate for push to use
[14:59] <beuno> also a transparent change
[14:59] <aquarius> it's not transparent... the server needs to include it in the message...!
[15:00] <aquarius> and a server can't know whether a user has upgraded the app or not, yet.
[15:00] <beuno> right, UUIDs will have to be in place
[15:00] <Elleo> aquarius: not sure if you've noticed already, but the fix for the dataPath/cachePath stuff has been released :)
[15:00] <beuno> before renames happen
[15:01] <beuno> so the order will likely be, first UUID rollout
[15:01] <beuno> switch push to that
[15:01] <beuno> then, renames
[15:01] <aquarius> beuno, push notifications work today. Are you suggesting that they will change?
[15:01] <aquarius> before the phone is released?
[15:01] <aquarius> which is, like, three weeks? :)
[15:01] <aquarius> Elleo, wooo!
[15:01] <beuno> aquarius, after, for sure
[15:02] <beuno> push should be able to be changed without changing the apps
[15:02] <beuno> to route by UUID instead of appid
[15:02] <aquarius> don't see the use of UUIDs here, either. I send a message to (user token, appid) at the moment; what's the benefit of generating a uuid instead of the appid?
[15:03] <aquarius> that just takes a meaningful chunk of data and makes it one more meaningless chunk that I have to store for everybody. :(
[15:03] <beuno> the backend could convert to appids
[15:03] <beuno> sorry, uuids
[15:03] <beuno> so you give it an appid
[15:03] <beuno> and it converts it to a uuid
[15:03] <beuno> btw, squatting is no different today
[15:04] <beuno> you can have com.microsoft
[15:04] <beuno> or com.ubuntu.developer.microsoft
[15:04] <beuno> and they can enforce trademark
[15:04] <beuno> same issue applies
[15:05] <aquarius> Ya, but I can't demonstrate that I *should* be allowed that, over MS themselves. But there is more than one company with a given name. Global economy. Domain names solve that problem. Single-word names do not.
[15:06] <beuno> domain owners also change
[15:06] <beuno> )
[15:06] <beuno> ;)
[15:06] <beuno> stupid ; key is broken
[15:07] <aquarius> when you say "on new uploads", does that include new uploads *of existing apps*?
[15:07] <beuno> no, new apps
[15:07] <aquarius> so if I upload a new version of, say, readability, it will become readability.sil rather than org.kryogenix.readability?
[15:07] <aquarius> ah, that's good at least. :)
[15:07] <beuno> new uploads of existing apps can use the same namespace
[15:07] <beuno> everything here revolves around no end-user disruption
[15:11] <aquarius> anyway, I have registered my complaints, so no worries. :)
[15:12] <beuno> aquarius, noted on the 22-volume collection of sil's complaints about software not working as expected
[15:16]  * aquarius grins
[15:16] <aquarius> I prefer to think of it as "constructive feedback". :)
[15:17] <beuno> aquarius, I'll submit that to the editor
[15:23] <yakaar> hello everybody !! I've some questions about the different apps in ubuntu touch store : is there some secrity apps like textsecure or compatible or to encrypt calls or emails?
[15:27] <yakaar> because I couldn't find out any precise information about what apps are available and I would like to buy the ubuntu touch mobile which would come out on february
[15:28] <gventuri> popey: when is the weekly hangout for the Calculator team?
[15:30] <popey> gventuri: thursday
[16:02] <alci> I get "error: No targets specified and no makefile found.  Stop." when trying to build a click package. My template was "App with simple UI and localization"...
[16:03] <alci> I think there is a package I have to install in the emulator (or in the kit), but I can't remeber what...
[16:20] <sturmflut-work> "Flood It" now has 32 downloads from the store, and "Qt3D cylinder" stands at 82 :)
[16:22] <mzanetti> beuno: hey, I just read the mail about the new appid format. when is this going to happen?
[16:24] <mzanetti> beuno: just to let you know that it will at least break unity8's launcher and probably something in qtmir too
[16:26] <sturmflut-work> popey: Do you know any details about the "Ubuntu Developer Innovation Contest" by China Mobile and Canonical? It started a month ago and I expected a flood of chinese university students hitting the IRC channels or the mailing lists
[16:28] <beuno> mzanetti, it's already in place
[16:28] <beuno> nothing should break
[16:28] <beuno> new apps get a new unique string
[16:28] <beuno> old apps still use the same
[16:28] <mzanetti> beuno: we have code that relies on the "_" in there
[16:28] <mzanetti> e.g. calls split("_") on the appId etc
[16:29] <beuno> mzanetti, why would the _ change?
[16:29] <mzanetti> isn't it gone?
[16:29] <beuno> _ is added after the namespace
[16:29] <beuno> for the version number
[16:29] <beuno> no?
[16:29] <mzanetti> yeah, but before there were two _
[16:29] <mzanetti> like com.foo.bar.app_app_1.0
[16:29] <beuno> namespaces right now, don't have _'s
[16:29] <mzanetti> now it's app.bar_1.0, correcT?
[16:30] <beuno> just .'s
[16:30] <mzanetti> yeah... we do split on the first too I think
[16:30] <beuno> the appID generation should stay the same
[16:30] <mzanetti> beuno: is there an app in the store using this which I can test?
[16:31] <beuno> mzanetti, sure, mine, "hello-world"
[16:31] <beuno> hello icon
[16:31] <beuno> er, yellow icon
[16:33] <mzanetti> beuno: not as bad as I expected... just breaks a little
[16:34] <mzanetti> beuno: if you pin it to the launcher it won't parse the desktop file correctly any more
[16:34] <mzanetti> ie. wrong name
[16:34] <beuno> mzanetti, glad you brought it up
[16:34] <beuno> can you file the bug?
[16:34] <mzanetti> beuno: next time please tell us before if you're changing things like this :)
[16:35] <beuno> mzanetti, I talked to a lot of people before, I guess I didn't talk to enought!
[16:35] <beuno> sorry
[16:35] <mzanetti> beuno: :) the unity8 team just heard about it first time today
[16:36] <beuno> mzanetti, but it launches on the phone
[16:36] <beuno> so I'm a bit puzzled why it works on the phone and not the desktop
[16:37] <mzanetti> well, on the phone it's slightly buggy too. I think the reason why you can still run those apps is because it uses the code path for legacy apps
[16:37] <mzanetti> i.e. not click apps
[16:37] <mzanetti> which don't have the _ in there
[16:37] <mzanetti> beuno: so does this mean we have to support 3 app id formats now?
[16:38] <mzanetti> legacy, click (old) and click (new) ?
[16:38] <sturmflut-work> beuno: What confused me the most was that the Qt Creator plugin shipped with 15.04 already made use of the new appid format before the e-mail regarding the change came in. I had just created a new project and was about to file a bug against the Ubuntu SDK because I thought Qt Creator generated the wrong appid
[16:38] <beuno> mzanetti, 2 formats, yes. What 3rd?
[16:38] <beuno> sturmflut-work, right, those guys did some work ahead of time
[16:38] <mzanetti> beuno: dialer-app, com.ubuntu.developer.foo_foo_0.1, and foo.bar_0.1
[16:40] <beuno> mzanetti, yes
[16:40] <mzanetti> meh
[16:41] <mzanetti> greyback: fyi ^^
[18:57] <rickspencer3> elopio, I want to run autopilot tests from a script in the tests directory, but ...
[18:57] <rickspencer3> autopilot run ./autopilot/fairedescourses/
[18:57] <rickspencer3> doesn't work, autopilot says it can't find any tests
[18:57] <rickspencer3> if I cd into the autopilot directory, then
[18:57] <rickspencer3> autopilot run fairedescourses/
[18:57] <rickspencer3> works
[18:57] <rickspencer3> thoughts?
[19:06] <brendand> rickspencer3, actually what autopilot does is search the current directory for a module with the name specified
[19:06] <rickspencer3> brendand, ok, I added "cd autopilot" to me shell script :)
[19:07] <brendand> rickspencer3, in more detail - it needs a python import path, not a file system path
[19:07] <brendand> rickspencer3, like 'camera_app.tests.test_capture.TestCapture.test_hint_after_first_picture'
[19:17] <rickspencer3> brendand, I wrote a script to speed up testing with a u1db
[19:17] <rickspencer3> http://bazaar.launchpad.net/~rick-rickspencer3/+junk/fairesdescourses/view/head:/tests/U1DbTestSetup.py
[19:21] <brendand> rickspencer3, nice
[19:22] <rickspencer3> brendand, https://plus.google.com/109101768243927790674/posts/6KWZLNhsYZo
[19:29] <rickspencer3> are there instructions for making a click package out of an existing cordova app?
[20:01] <qtros> balloons we need you!
[20:06] <rpadovani> Project Ara will be released Feb 6th, as Ubuntu Phone. PLOT TWIST: Project Ara will be the first Ubuntu Phone!
[20:16] <aquarius> rickspencer3, https://developer.ubuntu.com/en/apps/html-5/guides/cordova-guide/
[20:17] <rickspencer3> hi aquarius
[20:17] <rickspencer3> aquarius, any interest into making another awesome Ubuntu phone video?
[20:17] <rickspencer3> one where you show folks all the different gestures?
[20:17] <aquarius> rickspencer3, hm. Could do, I suppose. The one I did was specifically to prove a point to Bryan, but lots of other people seemed to like it. :)
[20:18] <rickspencer3> aquarius, indeed, it was some of the best "marketing" for the phone I've seen
[20:18] <rickspencer3> I'd love to have a video to point to people to that shows some of the gestures
[20:18] <rickspencer3> a nice professional but friendly looking one
[20:19] <aquarius> I'm not sure I *know* all the gestures? I mean, there's swipe-left for the launcher, swipe-right for previous app, long-swipe-right for the app switcher, swipe-down (and left/right) for the status menus. In theory there'd be swipe-up for the bottom edge but I don't know any app that actually does anything interesting with that, yet.
[20:19] <rickspencer3> aquarius, the hard one for folks is the short swipe from the right edge, versus the long swipe
[20:20] <rickspencer3> people have trouble discovering the difference, and get confused
[20:20] <aquarius> I can imagine. I make that error myself; not swiping far enough.
[20:20] <aquarius> Oh, and long-swipe-left for the Dash.
[20:20] <rickspencer3> indeed
[20:20] <rickspencer3> :)
[20:20] <rickspencer3> aquarius, those cordova docs are exactly what I needed
[20:21] <aquarius> it does not help that I am fairly conditioned for swipe-left meaning "go back" from iOS Safari; I swipe left to go back in the browser and instead get the Dash. (I make the same mistake in Chrome, where swipe-left means "next tab".
[20:21] <aquarius> but, sure, I can do a video of that.
[20:30] <rickspencer3> thanks aquarius, what a guy :)
[21:41] <mivoligo> mzanetti: seen the pictures?
[21:42] <mzanetti> mivoligo: not yet, sorry
[21:42] <mivoligo> mzanetti: no problem :)
[21:48] <mzanetti> mivoligo: hey, bad news
[21:49] <mzanetti> gotta drop support for ubuntu 14.04
[21:49] <mzanetti> in order to have it fullscreen on the phone
[21:49] <mivoligo> mzanetti: ok, I think we almost done anyway
[21:50] <mivoligo> mzanetti: I'll test it in the virtualbox then
[21:50] <mzanetti> mivoligo: so to run it, can edit machines-vs-machines.qml and just change one import from 2.2 to 2.0
[21:50] <mzanetti> it'll fail the fullscreen call but that's not a problem on the desktop
[21:50] <mzanetti> all the rest should still be fine
[21:51] <mivoligo> ah, ok, I did that yesterday I think :)
[21:52] <aquarius> mzanetti, can you detect whether the fullscreen call is available and use it if so, rather than just requiring too-new libraries?
[21:52] <mzanetti> aquarius: I probably could somehow
[21:52] <mzanetti> but there aren't any phones with 14.04
[21:52] <aquarius> ya, but fullscreen stuff *ought* to work on desktop ;)
[21:52] <mzanetti> yes, but not with QML only
[21:53] <mzanetti> i could add a main.cpp and do the setFullscreen() call there, that would work
[21:53] <mzanetti> but in order to just use qmlscene I need to import QtQuick.Window 2.2
[21:54] <mzanetti> and given it was discouraged by the sdk to have a main.cpp I thought I'd play nice and dropped it
[21:54] <mzanetti> :)
[21:54] <aquarius> hm
[21:54] <aquarius> that's annoying
[21:55] <mzanetti> well, next template will have a main.cpp again (apparently it has other advantages too)
[21:55] <aquarius> normally I'd say to use a Loader but I don't know if that even *works* with a core QtQuick lib ;)
[21:55] <mzanetti> so when I update to the newer template I can fix it
[21:55] <mzanetti> use a Loader?
[21:56] <aquarius> https://bugreports.qt.io/browse/QTBUG-16854
[21:56] <mzanetti> yeah... would work I guess
[21:57] <aquarius> using a Loader is a pain in the ringpiece, I admit, but it'd be nice to not deny the app to desktop users, all of whom will still be on 14.04 a year from now :)
[21:57] <mzanetti> if someone helps out with packaging it for the desktop I'd fix it :D
[21:57] <mzanetti> but can't be bothered to maintain a .deb :D
[21:58] <aquarius> goodness, no
[21:58] <aquarius> but a year from now you'll be able to install click packages on the desktop.
[21:58] <Purebe|Work> Anyone know if there is any difference between running a program in the background and opening it via double click?
[21:58] <aquarius> there is no "packaging for the desktop", 'cos converrrrrrrrrrrrrgence ;)
[21:58] <mzanetti> aquarius: but then you can also have the import QtQuick.Window 2.2 :)
[21:58] <aquarius> mzanetti, hm.
[21:58] <aquarius> bloke makes a point. :)
[21:59] <aquarius> Purebe|Work, are you clicking on the executable for the app?
[21:59] <Purebe|Work> aquarius, yes
[21:59] <Purebe|Work> It runs fine, it's just if I open it ~20 times manually everything is good - but if I launch it ~20 times in the background the window eventually messes up
[21:59] <aquarius> Purebe|Work, then there should be no difference when doing that, as far as I'm aware; the file manager doesn't launch things in a special way. (I assume this is with an app you've downloaded to your home folder?)
[22:00] <Purebe|Work> It's an app I'm developing
[22:00] <Purebe|Work> nasty bug
[22:00] <aquarius> that's weird, then
[22:00] <aquarius> what does "messes up" mean, here?
[22:00] <Purebe|Work> it quits rendering
[22:00] <Purebe|Work> so you just see what is essentially a screenshot of the state the desktop was in when it runs
[22:01] <Purebe|Work> the underlying code still works, and, eventually it restarts itself as it's meant to - but once this happens it stays messed up this way
[22:01] <Purebe|Work> until I manually shut it down
[22:01] <aquarius> mzanetti, I suppose you're right, then :) I just don't like stuff dropping 14.04 because (a) I'm still on it and (b) every time somebody does that it makes it more likely that everyone forgets to backport stuff to 14.04 and the promise that we won't require people to run dev OSes just to get apps goes away a bit. :)
[22:01] <aquarius> Purebe|Work, that's weird. What's it written with?
[22:01] <Purebe|Work> Qt
[22:01] <Purebe|Work> 4.7
[22:02] <Purebe|Work> It uses the ALWAYS_ON_TOP_HINT
[22:02] <aquarius> it sounds like a Qt rendering issue; you may have more luck asking on the Qt channels, because they'll know more about how to turn on various debug things so you can see what's going on with rendering... but there are some smart Qt people here too, sometimes :)
[22:02] <Purebe|Work> to be honest, I just figured out it was a rendering issue :D
[22:02] <Purebe|Work> progress
[22:03] <Purebe|Work> for the past ~week almost I thought it was something else
[22:03] <Purebe|Work> but, thanks for the suggestion - I will ask over there
[22:03] <aquarius> is it literally graphics rendering -- that is, can you still click on buttons in the app (well, where the buttons are, even if you can't see them) and have the click do what it should, or does the app ignore clicks as well?
[22:04] <Purebe|Work> there are no buttons
[22:04] <Purebe|Work> but, it responds to ESC
[22:04] <Purebe|Work> and logic continues
[22:04] <aquarius> sounds like a graphics issue, perhaps. It might be worth getting someone else with a different graphics card to test it in case you're tickling some sort of Xorg/driver bug...
[22:05] <Purebe|Work> that isn't a bad idea at all, and lucky me I have several machines right here to test with
[22:05] <Purebe|Work> thanks
[22:05] <aquarius> no worries.
[22:10] <mzanetti> aquarius: tried the loader thing
[22:10] <mzanetti> problem is: if the Window is not the top level item, it actually creates a subwindow
[22:10] <aquarius> is it entirely composed of fail ? :)
[22:10] <aquarius> haha! really?
[22:10] <aquarius> that's rubbish then :)
[22:10] <mzanetti> yeah, sure... that's what it is supposed to do... so not the Window's fault
[22:10] <mzanetti> but kills the loader workaround for this case
[22:11] <mzanetti> so it's either a main.cpp to load it, or dropping 14.04 support
[22:11] <aquarius> what QML *actually wants* is conditional imports, like Python has. But Qt upstream hide under a bed every time it gets suggested and wave a sign which says "you should all be using C++ anyway"
[22:11] <aquarius> drop 14.04 support, then. That's fair.
[22:11] <aquarius> and if anyone complains, tell 'em it's upstream's fault ;)
[22:19] <mivoligo> are there any plans to backport all that new stuff to 14.04 in the future?
[22:19] <mivoligo> ppa or something?
[22:33] <mivoligo> mzanetti: I'll be back tomorrow. Let me know if I should redo those images :)
[22:33] <mzanetti> mivoligo: I think there is already a ppa
[22:34] <mzanetti> mivoligo: will add the images to the game now
[22:35] <mivoligo> mzanetti: ok, see you tomorrow :)
[22:35] <mzanetti> o/
[23:29] <ahoneybun> I'm following the appdev class doc and when I click on a article it moves to show "Content" but it does not really load the content of the article
[23:29] <ahoneybun> mhall119, ^