[06:25] <chesedo> i am trying to test a scope in an emulator to take a screenshot, but building gives the error `unity-js-scopes-tool: Command not found`
[06:26] <chesedo> the desktop build is successful
[06:27] <chesedo> the kit with the above error is i386 15.04
[07:02] <liuxg> does anyone know how to make a full screen app on ubuntu phone?
[08:28] <davidcalle> chesedo: the emulator doesn't have unity-js-scopes-tool. You need to install the click in it (via the Publish tab of the SDK). Alternatively, I don't mind taking a screenshot for you on my phone if you provide the click.
[08:29] <chesedo> davidcalle: thanks just figured that... am not trying to get the click running in the emulator
[08:29] <chesedo> davidcalle: will send you the click if i get stuck to much
[08:30] <davidcalle> chesedo: ok :)
[08:31] <chesedo> davidcalle: ty for the reply
[08:32] <chesedo> davidcalle: the error I currently have is "Timeout waiting for response from server" with emulator from the devel channel
[08:33] <chesedo> the emulator from the bq-stable channel had an error about custom something not supported at the moment
[08:35] <davidcalle> chesedo: right, this last one is because the sdk doesn't support running non-installed JS scopes directly to a phone/emulator, you need to install the click there first.
[08:35] <davidcalle> (chesedo, it will be supported in the future, still wip)
[08:35] <chesedo> ok, so how to install the click?
[08:36]  * chesedo thinks he might have read something about this and phablet-tools
[08:37] <davidcalle> chesedo: "Publish" tab on the left pane of the SDK. "Build and validate" -> Wait until validation passes -> "Install on device" -> Wait for install
[08:39] <chesedo> davidcalle: lol, missed the install button after building it. ty
[08:53] <liuxg> does anyone know how to get the QtQuick version on the Ubuntu phone?
[09:04] <chesedo> davidcalle: new error with install on device - Framework "ubuntu-sdk-15.04.4" not present on system
[09:05] <chesedo> that for both emulators
[09:06] <davidcalle> chesedo: alright, in the manifest.json file at the root of your project, change the framework to 15.04.3 (you must be using an more recent version of SDK packages than what's expected, which is fine! But phones don't know about it yet :) )
[09:10] <chesedo> davidcalle: ok, *.3 not present either, so am now trying earlier ones
[09:34] <chesedo> davidcalle: got that working. the emulator is now just not using the network from the host (which i understand should happen)... so it has no network connection
[09:36] <davidcalle> chesedo: you can try to fix this in the Devices tab, you can check for developer mode and network connection
[09:37] <chesedo> davidcalle: there it show network connection is off (and it is not clickable)
[09:37] <chesedo> developer mode is on
[09:38] <davidcalle> bzoltan_: zbenjamin : maybe you can help chesedo? ^
[09:38] <davidcalle> (SDK devs)
[09:38] <bzoltan_> chesedo:  is the wifi enabled on the device?
[09:39] <chesedo> bzoltan_: there is no toggle to enable it
[09:40] <chesedo> bzoltan_: it is an emulator (i386 from bq-stable channel)
[09:44] <bzoltan_> chesedo:  Ohh, emulator. That should use the network by default
[09:48] <chesedo> bzoltan_: that's how i understand it too, but does not seem to atm (browser has network error, store and scopes blank)
[09:55] <bzoltan_> chesedo:  you could adb shell into the emulator and look around.
[09:58] <chesedo> bzoltan_: ok, i guess the eth0 interface is the one that should have the connection
[10:43] <chesedo> davidcalle: can i pm you about making a screenshot for me
[10:44] <davidcalle> chesedo: sure!
[13:34] <labsin> Could someone give the Deezer Scope another shot? Is it working? (Giving results with and without a search) Someone with a deezer account would be even better. Would be very much appreciated.
[14:01] <davidcalle> labsin: I can give it a shot in a short moment
[14:02] <labsin> davidcalle: ok
[14:32] <popey> balloons: https://core-apps-jenkins.ubuntu.com/job/docviewer-app-autolanding/ - can we get the no caching option added to the build for docviewer? I had a look but couldn't see how to make it unique for that app...
[15:14] <davidcalle> lasbin, so, I've added my account, but I don't see it in System Settings -> Accounts
[15:17] <davidcalle> labsin: without a search, I see the login button, then an Artists category (top artists apparently, not from my account)
[15:18] <davidcalle> I can search without issues and get song previews
[15:34] <labsin> davidcalle: thank you. That's all I needed to know. I'll try at my work to get an emulator running to debug it. Hoped it would have worked without.
[16:59]  * popey pokes balloons 
[17:00] <popey> balloons: any chance we can get docviewer cmake parameter done?
[17:00] <ogra_> *bang*
[17:00] <popey> hah
[17:00] <balloons> popey, ohh, right.. You want uniquenss
[17:00] <balloons> that's not something we do, heh
[17:00] <popey> ugh
[17:00] <popey> can we pass additional parameters to the script that does the build?
[17:01] <balloons> We can do a one-off for it if we have to, but I'm guessing we can just have a think about how to do it generically
[17:01] <popey> like a CMAKE_OPTION?
[17:01] <balloons> right
[17:01] <balloons> that's my first thought
[17:01] <balloons> we need to do the same for unit tests for each app
[17:04] <balloons> so popey, just tell me how it needs to be built and we'll just change that job to do it, while we figure it out
[17:04] <popey> balloons: add "-DNO_CACHE=on" to the cmake line.
[17:04] <popey> that's it
[17:05] <balloons> I guess I can let you do it, heh. Just copy the script into the shell box, rather than calling it
[17:05] <balloons> ack
[17:05] <balloons> i'll have a look
[17:05] <popey> thanks.
[21:31] <aquarius> chrisccoulson, ping about Oxide. Specifically, my Readability app is broken with the latest OTA, and debugging it suggests that onLoadingChanged never fires with "false" when loading is complete, and onLoadingProgressChanged never fires at all. (I have not changed the code, so it's still using Oxide 1.0, which should not have been affected by an OTA release.)
[21:32] <aquarius> daker, you might know about this stuff. (I'd examine it in the devtools, but the devtools aren't working, afaict, despite me using http://www.kryogenix.org/days/2014/12/30/enabling-the-devtools-inspector-when-using-oxide-in-an-ubuntu-sdk-qml-app/ to turn them on.)
[21:33] <aquarius> (also xchat-gnome just crashed, to improve my mood further, but that's not the appdevs team's fault)
[21:36] <popey> aquarius: irssi ftw, #justsayin
[21:36]  * balloons hands aquarius smiling cookie
[21:37] <aquarius> I can't find any actual docs for the Oxide QML object itself, either; am I looking in the wrong place?
[22:09] <aquarius> (onLoadProgressChanged. Which I am now using, and which does work. Had to port the "is it loaded yet" stuff to that. So, this seems like a breaking change to me, which version numbering the components is specifically designed to prevent. Annoyed.)
[22:12] <chrisccoulson> hi aquarius
[22:12] <aquarius> hey chrisccoulson
[22:13] <aquarius> My Readability app broke; Oxide 1.0 used to fire the loading signal with true when one started loading a URL, and then fire it again with false when the URL finished loading. Now, it seems, it doesn't.
[22:13] <chrisccoulson> onLoadingStateChanged is what you want if you're monitoring WebView.loading. The old signal (onLoadingChanged) has always been broken - it's generated from the wrong place, and wasn't possible to fix as it was also used for delivering LoadEvents
[22:14] <aquarius> I have a little complaint and a big one. The little one is: that seems like annoying behaviour. But, y'know, fine, i can live with it; I'm all for making better API, as you obviously have done.
[22:14] <chrisccoulson> It's been deprecated for a while. The breakage is caused by a subtle ordering change in Chromium, which is why it was deprecated in the first place
[22:14] <aquarius> The big one is this: I am not using any newer Oxide. I had not changed the app at all.
[22:14] <aquarius> So, it should not have broken.
[22:15] <aquarius> I'm cool with API changing... but that means changing the version number too. Otherwise, what are version numbers even for?
[22:16] <chrisccoulson> Unfortunately, the API was always broken - the signal was generated from a completely different part of the navigation stack to WebView.loading. There were already cases when it was broken (particularly when cancelling loads)
[22:17] <aquarius> that ain't a reason in my opinion to break it worse ;)
[22:17] <aquarius> I get why it happened; I mean, I've been on the inside of this process too :)
[22:18] <chrisccoulson> There wasn't really a way for it not break like this, other than us not taking a newer Chromium
[22:18] <aquarius> but... that's a breaking change to a really obvious property. Anyone embedding Oxide at all basically would have needed it :(
[22:19] <chrisccoulson> It caught a few things out, despite the fact there's been a working API to replace it for over 18 months
[22:19] <aquarius> heh
[22:20] <aquarius> Question: where's the Oxide documentation? I couldn't (and still can't) find it, but that's likely because I'm rubbish at looking. But it's not listed in https://developer.ubuntu.com/api/qml/development/ afaict?
[22:21] <aquarius> There's an Ubuntu.Web object, but (a) I'm not using that, I'm just using com.canonical.Oxide, and (b) that object explicitly documents the loading property and doesn't mention that it's deprecated at all :(
[22:22] <aquarius> I'm trying to work out how I should have known this was going to happen so I could avoid it, because "re-test every app I've ever released, every six weeks" is not high on my priority list of stuff I wanna do :)
[22:22] <aquarius> and "permanently hang out on IRC and track platform development" is even lower on the list :-)
[22:26] <chrisccoulson> aquarius, documentation is still a bit lacking due to manpower issues
[22:26] <aquarius> :-(
[22:26] <chrisccoulson> That's a bit of an understatement really
[22:26] <aquarius> yeah. I understand the situation.
[22:26] <aquarius> However, this does not make it any easier to live with :)
[22:26] <chrisccoulson> WebView.loading isn't deprecated btw - it works ok, as long as you're using WebView.onLoadingStateChanged to listen for changes
[22:27] <aquarius> I still think the policy ought to be: nobody is allowed to release anything unless it has docs. The same as how you can't release stuff without tests, after Rick's Big Drive To Quality
[22:27] <chrisccoulson> I'd love a policy like that. Unfortunately, people keep asking for features and coming to me with bugs that always seem to be higher priority :/
[22:28] <aquarius> is OK; I am now using loadProgress anyway :)
[22:28] <aquarius> I could go to onLoadingStateChanged instead, but I've done a release now ;0
[22:28] <chrisccoulson> aquarius, what are you using it for anyway?
[22:29] <chrisccoulson> (loadProgress / loading)
[22:29] <aquarius> Readability loads a URL in an invisible webview, then injects the Readability bookmarklet JS into it; that then does (something) and ends up opening the page content at Readability.com
[22:30] <aquarius> and so at that point, once the page is showing, all nice and readable, I then make the webview visible.
[22:30] <aquarius> So I need to track "has the page loaded fully" so I can inject the JS, and then track "has the new page loaded fully" so I can know when to show the webview.
[22:32] <aquarius> So the underlying issue here, really, is: Oxide made a breaking change (for understandable reasons) and didn't bump the version number... and I assume that that's because version numbers don't really apply to Oxide because you always get "the latest version" because you can't or won't parallel-install multiple versions, for size reasons?
[22:32] <aquarius> so, all understandable, and I'm not sure I can see a *better* way out of this than what you did, but that doesn't make it any less frustrating :(
[22:35] <aquarius> (really, the solution here is: give you more resources to write documentation.)
[22:36] <chrisccoulson> Yeah :)
[22:36] <aquarius> wish I could make it happen for you, pal :)
[22:37] <chrisccoulson> Although, we still need to work out a way to notify app developers of changes that could potentially break apps
[22:37] <chrisccoulson> And there's plenty of those outside of the QML API (eg, web platform features being removed from blink)
[22:37] <aquarius> there is a better option, which is: don't break their apps. :)
[22:37] <aquarius> but I get that that may not be on the table for something like Oxide.
[22:39] <aquarius> but "sometimes we have to break the API" does not mesh at all well with "we do a release every month and a half", I gotta say
[22:40] <aquarius> I'm OK with the iOS approach of "yeah, you get to retest web stuff when we roll a new iOS to confirm it all still works", because they only release yearly (and have a long testing beta period beforehand)
[22:41] <aquarius> or the Ubuntu approach of "wow new stuff on your phone every five minutes, and we roll out bugfixes really fast"
[22:41] <aquarius> but they don't go well in combination :(
[22:43] <aquarius> perhaps a trivial doc patch to mention in the description of the loading property that one should use onLoadingStateChanged to watch for changes? that might help a little at least?
[22:43] <aquarius> I'd do it myself but I have no idea where docs live.
[22:43] <aquarius> so it'll take me hours to make the change :)
[22:48] <chrisccoulson> aquarius, we're not the only ones with this issue btw - the comments on https://codereview.chromium.org/1485973002/ are interesting
[22:48] <chrisccoulson> particularly https://codereview.chromium.org/1485973002/#msg62
[22:51] <aquarius> Heh. I'd disagree with that comment. I am fine adapting to changes in the APIs of HTML/CSS/JS etc inside a webview, but changes to the *embedding* API don't seem to me to be a thing which ought to rev as fast, at least partially because there are a bunch of things in place to help devs deal with this in JS -- first there were vendor prefixes, now there are flags to enable new stuff. But nobody ever breaks how
[22:51] <aquarius> , say, Array.filter() works and then says "well it's the web, you ought to be used to it by now".