[07:06] <dholbach> good morning
[07:30] <davidcalle> bzoltan_, ping
[07:30] <bzoltan_> davidcalle: yo
[07:30] <davidcalle> bzoltan_, hey, very nice post on duc blog!
[07:31] <davidcalle> bzoltan_, I'm wondering why there is no sdk-ide package for wily in the PPA, is it something we can expect soon-ish?
[07:31] <bzoltan_> davidcalle:  thanks :) have you tried the new SDK?
[07:31] <bzoltan_> davidcalle:  so you want the wily edition?
[07:32] <bzoltan_> davidcalle:  I can do that for you today ...
[07:32] <davidcalle> bzoltan_, no rush, will there be an issue with the vivid package on wily?
[07:34] <didrocks> zsombi_: hey! I have a probably stupid question on QML and transitions
[07:34] <didrocks> zsombi_: http://doc.qt.io/qt-5/qtquick-modelviewsdata-modelview.html#using-transitions sounds promising to tell that you can have "removal" animation even on Flow or Grid when you remove an item from a model
[07:35] <didrocks> zsombi_: however, reading http://doc.qt.io/qt-5/qml-qtquick-flow.html, I only see add and move animation hooks, no removal
[07:35] <didrocks> I'm probably missing something very obvious
[07:36] <zsombi_> didrocks: yes, there's no removal animation on Flow
[07:36] <didrocks> ah, so that doc is a lie? :)
[07:36] <didrocks> (like the cake ;))
[07:36] <zsombi_> at least according to the doc
[07:37] <zsombi_> let me check the component
[07:37] <didrocks> yeah, I was thinking reading from http://doc.qt.io/qt-5/qtquick-modelviewsdata-modelview.html#using-transitions that there were a generic thing for it, but couldn't find any example
[07:37] <bzoltan_> davidcalle:  I am creating the wily packages and dput them in a sec
[07:38] <bzoltan_> davidcalle:  there could be compatibility issues yes ... you know gcc
[07:39] <zsombi_> didrocks: indeed, the QQuickPositionerBase has no remove
[07:39] <davidcalle> bzoltan_, thanks, also kudos for using the opportunity to rename to ubuntu-sdk-ide :)
[07:40] <didrocks> zsombi_: ok, thanks for checking! I should maybe open a bug against Qt for the other doc to tell it's not available on each components using a model. Thanks!
[07:40] <bzoltan_> davidcalle: LOL :) that was a long pending issue
[07:40] <zsombi_> didrocks: sure!
[09:16] <TheNumb> o/
[09:28] <popey> bzoltan_: does your email which includes "sudo apt-get install ubuntu-sdk-ide ubuntu-sdk-api-tools ubuntu-sdk-api-15.04-armhf ubuntu-sdk-api-15.04-i386" - presume I'm on amd64 machine? (given the names of those packages) ?
[09:30] <popey> bzoltan_: also - [M#qRE: Unable to locate package ubuntu-sdk-ide
[09:30] <popey> http://paste.ubuntu.com/12251947/ bzoltan_
[09:36] <davidcalle> popey, wily?
[09:38] <CaptainHeavy> ogra_: just posted a review for your KiwiIRC app, hopefully that should give you a few more downloads :)
[09:38] <popey> davidcalle: yes
[09:38] <davidcalle> popey, building -> https://launchpad.net/~ubuntu-sdk-team/+archive/ubuntu/tools-development/+build/7869878
[09:38] <popey> hah
[09:38] <ogra_> CaptainHeavy, wheee ! thanks !
[09:38] <CaptainHeavy> ogra_: no problem, thanks for building the app in the first place!
[09:38] <popey> everyone is running wily, surely! :)
[09:38] <ogra_> popey, probably they switched from ide to sata, try ubuntu-sdk-sata :P
[09:39] <davidcalle> wily + xenial overlay
[09:40] <popey> hah
[10:16] <bzoltan_> popey:  No, I put extra effort to support rare people who are on i386
[10:18] <bzoltan_> popey: and I assume that you are on wily. So the wily IDE package is being published right now ... so please wait for few ten minutes
[11:35] <nik90> bzoltan_: wow I didnt notice that Qtcreator we used was stuck at 3.1. Happy to read about the next-generation SDK. aquarius will be really happy to hear about this.
[11:39] <bzoltan_> nik90: aquarius: Yes, this forwarda and backward porting was limiting us a lot.  I hope that this solution will help.
[11:41] <aquarius> I properly am happy to hear about it
[11:41] <aquarius> being able to test phone apps on my 14.04 desktop will make my life a lot, lot easier :)
[11:43] <nik90> aquarius: so this 500 MB package will contain the entire Ubuntu Toolkit APIs, Qt Libraries necessary for app development. Would we be able to run it on the desktop to test it since from the blog post I read it provides the armhf 15.04 chroot.
[11:43] <nik90> bah...that was supposed to be addressed to bzoltan_ ^^
[11:44] <bzoltan_> nik90: aquarius: to avoid misunderstanding :) the latest SDK runtime will come later to the LTS ... the UITK is already sneaked in ... if you look around the /usr/ubuntu-sdk-ide
[11:46] <nik90> ah ok
[12:29] <aquarius> bzoltan_, how will I know when it's beyond testing and ready to be used? Will this stuff all end up in the normal ubuntu sdk ppa?
[12:32] <bzoltan_> aquarius:  yes, that is the plan. You will know if you follow the phone ML. Right now it is testing time...
[12:32] <bzoltan_> For example i am pushing an update right now as the first itteration was not installing perfectly in some case
[12:32] <aquarius> bzoltan_, cool. I have enough to do testing the apps I build without testing the infrastructure as well, but I'll be a happy user of it once it's stable :)
[12:33] <bzoltan_> aquarius:  I mean it is rock stable ... the IDE code is way much better then the one from the PPA
[12:34] <aquarius> ahem. "the first itteration was not installing perfectly in some case" and " it is rock stable" are directly contradictory ;)
[12:37] <aquarius> but it's cool, whatever happens -- really looking forward to being able to run apps on my lts desktop!
[12:38] <bzoltan_> aquarius: two different beast ... the IDE package is complete and stable. it is the API package what can act up ... but that is just the chroot, can be disposed or recreated manually
[13:24] <didrocks> kenvandine: hey! So, I'm using the ContentStore uri (I set the scope). This one isn't set before getting a transfer done (and the m_store being set)
[13:24] <didrocks> kenvandine: as I have a databinding setting the uri to another object, I'm getting: Accessing ContentStore uri with NULL internal store
[13:24] <didrocks> is there any way I can know if an internal store have been instantiated? (or even better, getting the .uri even before, as this just depends on the scope that is set, isn't it?)
[13:25] <kenvandine> i don't think uri should be able to be null
[13:25] <kenvandine> that should be set when instantiated
[13:25] <kenvandine> oh... you're binding to it
[13:26] <kenvandine> so the binding gets null before it's instantiated
[13:26] <didrocks> exactly!
[13:26] <kenvandine> i don't think there's anything you can do about that
[13:26] <kenvandine> it'll get set as soon as it's instantiated
[13:26] <kenvandine> it just makes noise in the logs :/
[13:26] <kenvandine> but that's a qml thing
[13:27] <kenvandine> if you find away around that, i'd love to hear it :)
[13:27] <didrocks> yeah, I was wondering how to reduce this
[13:27] <kenvandine> we have quite a few places in system-settings that suffers from this
[13:27] <didrocks> kenvandine: I don't understand conceptually why you need a transfer to be instantiated to get the uri, doesn't it just depends on the scope?
[13:27] <kenvandine> not the transfer
[13:27] <kenvandine> the ContentStore
[13:27] <kenvandine> has to be instantiated
[13:27] <didrocks> I have:
[13:27] <didrocks>     ContentStore {
[13:27] <didrocks>         id: appContentStore
[13:27] <didrocks>         scope: ContentScope.App
[13:27] <didrocks>     }
[13:28] <didrocks> appContentStore.uri returnts that warning
[13:28] <kenvandine> in the binding
[13:28] <didrocks> before I initiate a transfer with it
[13:28] <didrocks> yeah, but ContentStore is instantiated, isn't i?
[13:28] <didrocks> it*
[13:28] <kenvandine> because you are accessing it before it's instantiated
[13:28] <kenvandine> not necessarily at startup
[13:28] <kenvandine> it is
[13:28] <didrocks> oh
[13:28] <kenvandine> but briefly it isn't :)
[13:28] <didrocks> you think it's even before that
[13:28] <kenvandine> yeah
[13:28] <kenvandine> it happens a lot in qml
[13:29] <didrocks> and appContentStore isn't null, just not init()
[13:29] <kenvandine> right
[13:29] <didrocks> I think I got it
[13:29] <didrocks> ok, so in pure-qml I have some "ready" flags for this
[13:29] <kenvandine> so if you print appContentStore.uri in Component.onCompleted
[13:29] <kenvandine> you'll get it
[13:29] <didrocks> I doubt you want to implement that in c++ :p
[13:29] <didrocks> yep
[13:29] <didrocks> let me check
[13:30] <didrocks> hum
[13:30] <didrocks> doesn't seem to be the case
[13:30] <didrocks> I just added Component.onCompleted: console.log("uri now: " + uri)
[13:30] <kenvandine> not sure how that could be
[13:30] <didrocks> and the print is "uri now: "
[13:31] <kenvandine> hang on... phone ;)
[13:31] <didrocks> :)
[13:34] <kenvandine> didrocks, back
[13:34] <kenvandine> i'm still puzzled, the uri is set in the constructor
[13:34] <kenvandine> oh
[13:35] <kenvandine> console.log("uri now: " + appContentStore.uri)
[13:35] <kenvandine> uri isn't in the same scope as the page or whatever
[13:37] <didrocks> kenvandine: I'm on the onCompleted for that component
[13:37] <didrocks> let me add the id, but I doubt that will change
[13:38] <didrocks> yep, that didn't change, still blank
[13:38] <didrocks> I just have http://paste.ubuntu.com/12253258/
[13:38] <kenvandine> try doing it on your outer component
[13:38] <didrocks> the uri isn't set on component's completion (from the C++ code, you only set the uri on when it has a setStore())
[13:38] <kenvandine> page or whatever
[13:39] <didrocks> same on the page
[13:39] <kenvandine> that's on the transfer though
[13:39] <kenvandine> ok, let me check the source
[13:41] <kenvandine> didrocks, in cpp, the store requires a uri for the constructor
[13:41] <kenvandine>     Store(const QString& uri, QObject* parent = nullptr);
[13:41]  * kenvandine checks the qml bindings
[13:43] <kenvandine> weird, the qml bindings do something different
[13:43] <didrocks> in the opposite order, right? the store assign the uri
[13:44] <kenvandine> didrocks, well ContentStore qml binding doesn't actually set a cuc::Store internally until it's used in the transfer
[13:44] <kenvandine> Elleo, ^^ do you recall if that was intentional?
[13:45] <kenvandine> Elleo, or was that maybe left over from the first version of the bindings :)
[13:45] <kenvandine> when the store is set on the transfer in qml, then the internal store is set on the ContentStore
[13:45]  * kenvandine thinks that should happen in the constructor
[13:45] <didrocks> kenvandine: you get now why I was telling "empty until I set a transfer ;)"
[13:46] <kenvandine> didrocks, yeah, it doesn't make sense :)
[13:46] <didrocks> kenvandine: I'm sure you know are really eager to get a bug on this! :)
[13:46] <kenvandine> didrocks, i'm more familiar with the backend and cpp stuff :)
[13:46] <didrocks> (and at least, I understand why it didn't make sense to me to wait for a transfer to get the uri)
[13:46] <didrocks> that forced me in some interesting "workarounds"
[13:46] <kenvandine> yeah, the ContentStore api should be more useful
[13:47] <kenvandine> didrocks, please file a bug
[13:47]  * didrocks walks/jumps/runs to file one :)
[13:47] <didrocks> thanks for confirming kenvandine :)
[13:51] <Elleo> kenvandine: don't remember it being intentional, not sure much has changed in the ContentStore for quite a while though
[13:52] <kenvandine> Elleo, ok, i'm going to look at refactoring that a bit to ensure it's set in the constructor
[13:52] <didrocks> Elleo: kenvandine: bug #1491411 FYI
[13:53] <kenvandine> Elleo, i suspect that is leftover from the first iteration of the bindings
[13:53] <kenvandine> looks like gunther's code :)
[14:01] <kenvandine> Elleo, didrocks: i see why... it needs the ContentType of the transfer
[14:01] <kenvandine> so this is intentional
[14:01]  * kenvandine does want the ContentStore to be more generally useful
[14:02] <kenvandine> maybe we should add a contentType property to the ContentStore
[14:02] <kenvandine> didrocks, so basically not a bug, but could be made to be more generally useful for more than just transfers
[14:02] <Elleo> kenvandine: when you get a chance could you take a look at: https://code.launchpad.net/~michael-sheldon/content-hub/fix-initial-peer-list/+merge/269917 it allows us to avoid making an extra look up when creating a contentpeermodel, and fixes the browser incorrectly showing up in the contentpeerpicker for unknown types
[14:03] <kenvandine> Elleo, sure
[14:03]  * nemo pokes mcphail again
[14:03] <Elleo> kenvandine: I've added an "Undefined" type on the QML bindings to allow for the check, but I've only added it there and not also in the service, not sure if it's useful to add it everywhere or not
[14:08] <didrocks> kenvandine: yeah, that would be good, I'm still leaving it opened then
[14:08] <kenvandine> yeah
[14:08] <kenvandine> i'm commenting
[14:17] <Elleo> kenvandine: added a comment to that MR with info about the browser branch
[14:17] <kenvandine> thx
[14:20] <nik90> ahayzen: Hey , can you request QA to start testing music-app since it has all the necessary translations ready. Unless you guys were planning for additional fixes to land. While it waits in the QA queue, in parallel it will get further translations.
[14:23] <kenvandine> Elleo, how would you feel about adding that branch to silo 17?
[14:23] <kenvandine> it'll make it easier to test :)
[14:23] <kenvandine> the code looks good
[14:24] <kenvandine> but i haven't approved it yet
[14:25] <Elleo> kenvandine: sure thing
[14:25] <kenvandine> Elleo, cool, thanks!
[14:43] <kenvandine> Elleo, i see 17 is building, but without content-hub
[14:43] <kenvandine> i think you forgot to reconfigure it
[14:43] <Elleo> kenvandine: ah, will fix that now
[14:43] <Elleo> kenvandine: thanks for spotting it
[14:43] <kenvandine> np
[15:04] <Elleo> kenvandine: what do I need to do with the new system to get it to reconfigure? I'd thought just re-running assign would do it, but that doesn't seem to have worked
[15:30] <kenvandine> Elleo, that's all you need to do
[15:30] <kenvandine> Elleo, i'll look at it
[15:33] <kenvandine> Elleo, i assigned again and building, looks like it's going to build content-hub
[15:33] <kenvandine> had you specified the browser in the packages to rebuild before?
[15:34] <Elleo> kenvandine: I'd just selected the generic force rebuild option, rather than specifying anything individually
[15:34] <kenvandine> ah
[15:34] <kenvandine> i bet that meant rebuild existing packages
[15:34] <kenvandine> i didn't check anything
[15:34] <Elleo> ah
[15:34] <kenvandine> so it looks for changes to build
[15:34] <Elleo> okay, cool; will know for next time :)
[15:35] <kenvandine> you don't need to force when there are new revisions or new branches
[15:35] <kenvandine> it'll figure it out
[15:35] <Elleo> ah, okay
[17:08] <pmcgowan> popey, do you know if any progress was made on notifications for dekko mail
[17:08] <pmcgowan> or DanChapman,
[17:12] <ahayzen> nik90, yup, was just about to ping popey :-)
[17:57] <popey> pmcgowan: only updates from niklas updates, and some discussions with chipaca and rsalveti, no code
[17:59] <pmcgowan> popey, ok
[18:48] <mcphail> If anyone looks after http://unity.ubuntu.com/mir/ , can you fix it please? Hard to hack with Mir when the API docs are missing :) . Tempted to give up for the evening and pour a whisky instead
[18:57] <popey> mcphail: might be better off asking in #ubuntu-mir - kgunn specifically
[18:57] <mcphail> popey: kdub is helping there. Thanks