[01:03] <EgonR|2> Is there a roadmap or preliminary release date for the rewritten unity? (QT/QML)
[01:05] <EgonR|2> Also, will the QML version be free from all gtk* cruft?
[01:05] <EgonR|2> or will it still depend om gtk in any way?
[03:21] <EgonR|2> Not very lively today
[03:21] <EgonR|2> Ill wait a few more hours before i go to bed.
[03:24] <duflu> EgonR|2: Did you have a question that needs answering?
[03:25] <EgonR|2> I asked two and an half hour ago the following: Is there a roadmap publically available or preliminary release date for the rewritten unity? (QT/QML). Also, will the QML version be free from all gtk* cruft?
[03:25] <EgonR|2> perhaps you would know
[03:27] <duflu> EgonR|2: Yes *gtk* should be gone. And a basic roadmap is https://wiki.ubuntu.com/Mir/Spec#Roadmap
[03:28] <EgonR|2> Awesome! I am looking forward to is so much
[03:29] <EgonR|2> Will it be MIR exclusive? Or can you run the new unity on Xorg
[03:30] <EgonR|2> I mean, writing and entire displayserver takes time..
[03:31] <duflu> EgonR|2: Not totally sure. You should assume it's Mir-exclusive but we'll always aim to make things portable eventually. It's just not a priority right now
[03:31] <EgonR|2> Yeah, i understand that.
[03:32] <duflu> This is where we need some Unity Next people online. I think they're mostly in Europe so won't wake up for a few hours yet
[03:32] <EgonR|2> Oh ok
[03:33] <EgonR|2> Looks like that is very much a pattern for most OSS projects on freenode.
[03:34] <EgonR|2> I think US programmers use EFNet a lot more than the europeans though.
[03:36] <duflu> Maybe... Though it's Canonical policy to have its public discussions on FreeNode
[03:36] <EgonR|2> yup
[03:36] <duflu> Ubuntu policy even
[03:37] <EgonR|2> freenode seems like a better host for a software project. efnet is littered with strange channels as well..
[03:37] <EgonR|2> hehe
[03:39] <EgonR|2> duflu: Thank you for your time, it was most helpful. I will go back to lurking.
[03:45] <duflu> EgonR|2: No problem. Sorry more people don't pay attention very often
[06:10] <didrocks> hey Mirv, how are you?
[06:16] <Mirv> didrocks: morning, fine, and you?
[06:21] <didrocks> Mirv: I'm good, thanks! :)
[06:21] <didrocks> Mirv: I know it's Qt4 and not Qt5, but do you mind having a look at bug #1155327 and tell us what's the best course of action for it?
[06:28] <Mirv> didrocks: ok, looking..
[06:56] <Mirv> commented, although can't reproduce myself as it needs nvidia hardware to happen (+ possibly prelink installed). I don't know what to do other than revert to qtwebkit-source 2.2.1 (or ask for rebuild/fix from Microsoft)
[06:57] <Mirv> or finding out skype is the only affected package and accepting the workaround for it
[06:57] <didrocks> Mirv: do you mind discussing that with the kubuntu guys?
[06:58] <didrocks> Mirv: I think we should, from your comment revert
[06:58] <didrocks> Mirv: as you told, we are not sure if skype is the only affected package
[06:58] <Mirv> ok, I'll ask around on kubuntu channel
[06:58] <didrocks> thanks :)
[07:01] <Mirv> riddell has looked into it a week ago, asked for an update
[07:01] <didrocks> Mirv: excellent, do you mind keeping me in touch?
[07:05] <Mirv> didrocks: ok
[07:20] <didrocks> sil2100: good morning, how are you?
[07:23] <sil2100> didrocks: morning! Good, how about you?
[07:24] <didrocks> sil2100: I'm good, thanks!
[07:24] <didrocks> sil2100: do you have time for some touch apps boostrapping help for preparing that for S?
[07:25] <sil2100> didrocks: should be no problem, what can I do to help?
[07:25] <didrocks> sil2100: should we have a quick hangout? It will maybe be easier
[07:27] <sil2100> didrocks: ok
[07:27] <didrocks> sil2100: now is fine for you?
[07:29] <sil2100> didrocks: yep, ready when you are ;)
[07:35] <Saviq> mzanetti, whoa http://s-jenkins:8080/job/unity-phablet-ci/
[07:35] <sil2100> didrocks: just point me to the hangout when ready ;)
[07:35] <mzanetti> Saviq: yeah... I just cancelled them and am debugging right no
[07:35] <mzanetti> w
[07:36] <didrocks> sil2100: yeah, finishing a discussion and will ping you soon :)
[07:36] <Saviq> mzanetti, thanks
[07:40] <didrocks> sil2100: https://plus.google.com/hangouts/_/effa6372491bd8d9829359be5de48d6464cfbc83?authuser=0&hl=en
[08:11] <dandrader> Saviq, ping
[08:14] <Saviq> dandrader, pong
[08:18] <dandrader> Saviq, I've been working on removing those FooFake vs. FooWrapper switches and components throughout the qml code (e.g. get rid of ApplicationManagerFake). The plan is to have a fake implementation of Ubuntu.Application module. That way we can get the qml tree pretty much clean of those things. It started out as infrastructure to test RunningApplicationTile but then I though it would be better to just apply it on the whole code base
[08:18] <dandrader> Saviq, what do you think?
[08:20] <dandrader> Those FooFake vs. FooWrapper switches might be fine for running on the desktop but get in the way of testing
[08:24] <Saviq> dandrader, yeah, if we can make without those wrappers, I'm game
[08:25] <Saviq> dandrader, only so that the actual Ubuntu.Application is used elsewhere, make sure you put it in a separate module path
[08:25] <Saviq> and export QML2_IMPORT_PATH in the ./run script
[08:27] <dandrader> Saviq, right
[08:38] <mzanetti> hey, anyone knows whats going wrong that after recent upgrades in raring the machine doesn't come up any more because of a read only rootfs?
[08:39] <Saviq> mzanetti, why would you shut down? it's so '90s ;)
[08:40] <Saviq> mzanetti, but seriously, nope, haven't had that
[08:40] <mzanetti> Saviq: let me rephrase: the machine doesn't come up after a quick reboot because of kernel upgrades
[08:40] <mzanetti> :D
[08:40] <mzanetti> veebers has the same in his raring VM
[08:41] <veebers> o/
[08:42] <mzanetti> veebers: yeah, if you could find out if its only with raring too or happens after inclusion of phablet ppa's that would be great
[08:42] <Cimi> tsdgeos, hi :)
[08:42] <veebers> mzanetti: I'm just fire-ing up the VM now :-)
[08:42] <tsdgeos> Cimi: hi there
[08:42] <Cimi> I need a little help here if you have 5 mins
[08:42] <Cimi> https://code.launchpad.net/~unity-team/unity/phablet.moving_tests
[08:43] <Cimi> I was moving tests under subdirs
[08:43] <Cimi> but hud test complains of missing hudclient
[08:43] <Cimi> I think is something to do with the makefiles
[08:43] <Cimi> can you help me?
[08:45] <tsdgeos> sure
[08:45] <tsdgeos> give me a sec
[08:48] <Saviq> mzanetti, we got a PASSED!
[08:48] <mzanetti> Saviq: huh?
[08:48] <mzanetti> the tests?
[08:48] <Saviq> mzanetti, http://s-jenkins:8080/job/unity-phablet-ci/349/
[08:48] <mzanetti> Saviq: yeah... seems one of the VM's is configured different than the other
[08:48] <Saviq> uh
[08:48] <mzanetti> Saviq: and makes the tests stall... I'm on it
[08:49] <mzanetti> Saviq: right now Mir is building on the "broken" one which takes 1.5 hours :/
[08:49] <Saviq> right
[08:49]  * mzanetti is happy that unity phablet ci runs in ~10 mins :D
[08:52] <tsdgeos> Saviq: so i got a patch by "the qml guy"
[08:52] <Saviq> tsdgeos, nice
[08:52] <tsdgeos> it does indeed fix the crash but i'm not sure his solution is great
[08:52] <Saviq> tsdgeos, does it help?
[08:52] <Saviq> tsdgeos, :)
[08:52] <Saviq> tsdgeos, is it in gerrit?
[08:52] <tsdgeos> problem he is in US west coast, so it's going to take a while to ping-pong between us
[08:53] <tsdgeos> yep
[08:53] <tsdgeos> https://codereview.qt-project.org/53235
[08:54] <Saviq> tsdgeos, can you think of a better solution?
[08:54] <tsdgeos> Saviq: it's not a better solution, it's that this one is only partial
[08:55] <tsdgeos> i.e. accounts for removals to the cache but not additions, not really sure that this is a problem, but it might
[08:55] <tsdgeos> and also the delayed stuff comes from somewhere that does "delete this" thus we effectively end up with a dangling pointer in the cache too
[08:55] <tsdgeos> it "might" not be a problem
[08:55] <tsdgeos> but i'd want to make sure he has thought about these
[08:56] <Saviq> tsdgeos, that's what gerrit is for, isn't it :)
[08:56] <tsdgeos> it is
[08:56] <tsdgeos> i'm still perfecting my text :D
[08:56] <Saviq> tsdgeos, fortunately it's not awfully pressing
[08:56] <Saviq> tsdgeos, so we'll get there when we'll get there
[08:57] <tsdgeos> Cimi: what happened is this "Panel/qml/HudClient/"
[08:57] <Saviq> tsdgeos, will you own getting this distro-patched?
[08:57] <Cimi> tsdgeos, you have commit access if you can fix :)
[08:58] <tsdgeos> Saviq: once we agree on a solution upstream? sure, it's just messing with zoltan/mirv to get it into the packages, no?
[08:58] <Saviq> tsdgeos, yup
[08:58] <tsdgeos> sure, no worries
[09:02] <veebers> mzanetti: after a dist-upgrade with no PPAs and a reboot, machine came up fine. I'll try with a single ppa now see if that breaks
[09:02] <mzanetti> veebers: cool, thanks
[09:02] <Saviq> nic-doffay, you joining the hangout?
[09:02] <nic-doffay> One sec Saviq
[09:02] <Saviq> nic-doffay, cheers
[09:04] <tsdgeos> mzanetti: ping
[09:04] <mzanetti> tsdgeos: yes sir
[09:05] <tsdgeos> mzanetti: you added/wanted to add a make -i/-k to qmluitests, right?
[09:05] <mzanetti> tsdgeos: yes
[09:05] <tsdgeos> is that a good idea?
[09:05] <mzanetti> added
[09:05] <mzanetti> why not?
[09:05] <tsdgeos> i understand CI wise it makes sense
[09:05] <tsdgeos> but if i'm sitting here
[09:05] <MacSlow> Cimi, ping
[09:05] <tsdgeos> i run "make qmluitests"
[09:05] <tsdgeos> it writes lots of stuff in the shell
[09:06] <Cimi> MacSlow, pong
[09:06] <tsdgeos> like two screens
[09:06] <tsdgeos> and most probably i'll only look at the last test and see a "passed"
[09:06] <mzanetti> tsdgeos: its only when you run "./runtests.sh"
[09:06] <tsdgeos> ah
[09:06] <tsdgeos> ok :-)
[09:06] <tsdgeos> right
[09:06]  * tsdgeos hits head
[09:06] <mzanetti> tsdgeos: if you run "make qmluitests" manually there is no -k :D
[09:06] <tsdgeos> yeah, sloooooow
[09:06] <mzanetti> tsdgeos: hint: run "make alltests"
[09:06] <tsdgeos> Cimi: pushed
[09:08] <Cimi> tsdgeos, do panel tests work now?
[09:08] <tsdgeos> Cimi: sure, why wouldn't they?
[09:08] <Cimi> tsdgeos, thought thy needed qml subdir
[09:08] <tsdgeos> they do
[09:08] <tsdgeos> it's still there
[09:08] <tsdgeos> the part of it they need
[09:09] <tsdgeos> this is good too
[09:09] <tsdgeos> since we're splitting the "qml" subdir that holded separate stuff for two separate tests
[09:09] <Cimi> tsdgeos, because you modified cmakelist of panel
[09:09] <Cimi> tsdgeos, the part you left doesn't need it?
[09:09] <tsdgeos> and putting it into the correct places
[09:09] <tsdgeos> Cimi: no
[09:09] <Cimi> ok
[09:09] <Cimi> tsdgeos, if everything works we're ready for MR
[09:10] <luv> mardy: ping
[09:10] <Saviq> nic-doffay, you with us? ;D
[09:15] <Cimi> Saviq, mzanetti tsdgeos https://code.launchpad.net/~unity-team/unity/phablet.moving_tests/+merge/157821
[09:15] <mzanetti> Cimi: ack
[09:16] <Cimi> mzanetti, better sooner than peter so we have less tests to move afterwards :)
[09:16] <Cimi> *later
[09:20] <veebers> mzanetti: after the raring dist-upgrade, I added the phablet-team ppa and again did an update && dist-upgrade. I get this error: https://pastebin.canonical.com/88744/
[09:26] <veebers> mzanetti: running dist-upgrade again I get this error: http://pastebin.ubuntu.com/5691831/ (the apt-get -f install log: http://pastebin.ubuntu.com/5691833/)
[09:27] <mzanetti> veebers: hmm... somehow I can't figure how this relates to a read-only filesystem at boot
[09:27] <veebers> mzanetti: the dist-upgrade after that went fine, but after the reboot I get the read only filesystem
[09:28] <mzanetti> Saviq: any idea? ^
[09:29] <veebers> mzanetti, Saviq: this is what the phablet-team dist-upgrade wanted to install: http://pastebin.ubuntu.com/5691841/
[09:29] <mzanetti> veebers: mountall... that sounds like it could be involved
[09:29] <mzanetti> veebers: mind reverting your VM and just upgrade that package?
[09:30] <tsdgeos> Cimi: can you merge master into https://code.launchpad.net/~unity-team/unity/phablet.test_responsiveflowview/+merge/157343 ? It's what making the qmluitests fail
[09:31] <veebers> mzanetti: yeah I can do that, I'll upgrade it using the phablet-team ppa
[09:31] <mzanetti> veebers: thanks
[09:32] <veebers> np
[09:37] <Cimi> tsdgeos, ok
[09:38] <Cimi> tsdgeos, done
[09:42] <tsdgeos> tx
[09:43] <mardy> luv: pong
[09:44] <veebers> mzanetti, Saviq: After adding phablet-team and installing mountall, rebooting gives me a readonly filesystem
[09:44] <mzanetti> veebers: \o/ thanks a lot!!!
[09:45] <veebers> mzanetti: no worries, good spotting with the mountall issue
[09:45] <mzanetti> anyone knows what exactly this does, and expecially why we need a -phablet version for that?
[09:46] <luv> mardy: Hi! I've been messing around with accounts-sso and implementing the logout functionality to gnome-control-center-signon. I am trying to figure out an API call for libsignon to delete the stored password. What is also confusing me is that there is no signond running on my system.
[09:46] <luv> http://docs.accounts-sso.googlecode.com/git/libsignon-glib/html/SignonIdentity.html#signon-identity-remove just does not work for me
[09:47] <veebers> mzanetti: do you mind if I leave that with you? I need to finish for the night
[09:47] <luv> on the other hand, if I delete an account in gnome-control-center-signout the credentials are removed (I guess it communicates with signon via dbus - but no signond running?)
[09:48] <mardy> luv: it should work, because we are using that function call from inside libaccount-plugin to delete the identity when the account creation is aborted
[09:48] <mardy> luv: signond must be running, but it exits after a few seconds of inactivity
[09:49] <mardy> luv: set the debugging level to 2 in /etc/signond.conf, then keep an eye on the syslog
[09:49] <luv> yes, I was looking at libaccount-plugin to see how it deletes the account - but I didnt see a direct use of that function only a lot of dbus stuff
[09:49] <mardy> luv: you should be able to see if/why your call fails
[09:49] <luv> umm, I will try that
[09:50] <mardy> luv: http://bazaar.launchpad.net/~online-accounts/gnome-control-center-signon/trunk/view/head:/libaccount-plugin/oauth-plugin.c#L187
[09:50] <luv> thanks a lot, I will have another look tonight :-)
[09:51] <mardy> luv: but I'm a bit worried, why are you deleting identities? :-)
[09:51] <luv> alright - to implement "logout" functionality
[09:52] <mardy> luv: I don't think you should delete the identity in that case -- doing so will mess things up
[09:52] <Cimi> tsdgeos, I've also rebased to the moving tests branch
[09:52] <tsdgeos> oki
[09:52] <luv> mardy: well sure, but you cant keep passwords and tokens around if you want to implement logout
[09:52] <mardy> luv: if you really want to, you could store an empty password on the identity, but I'm not 100% sure it's a good idea
[09:52] <luv> that'd be useless
[09:53] <mardy> luv: why?
[09:53] <luv> keeping passwords and tokens around would be useless
[09:53] <mardy> luv: ah, yes, agreed
[09:54] <luv> well, I can modify gnome-control-center-signout to deal with a deleted identity properly
[09:55] <luv> and the apps themselves - they dont have access to identities, do they?
[09:55] <mardy> luv: you could retrieve the current IdentityInfo, clear the password (actually, I think you'll get it empty anyway), delete the record and then store the IdentityInfo as a new one
[09:56] <mardy> luv: they have access -- they use it when authenticating
[09:57] <mardy> luv: oh, a better solution, to make sure that there aren't race conditions, is to create the "cleared" identity record first, then store its ID into the account, and finally remove the previous ID
[09:58] <mardy> luv: maybe that's exactly what you wanted to do :-)
[10:07] <luv> mardy: sounds good!
[10:07] <luv> i will experiment with that for now ;-) and see where it goes
[10:09] <mardy> luv: but I think that it would be much better to implement a logout API directly in signond
[10:12] <luv> sure, but let me try this first
[10:13] <mzanetti> Cimi: you know whats weird...
[10:13] <Cimi> mzanetti, no :)
[10:14] <mzanetti> Cimi: if I call "runtests.sh" on current trunk it says 35% coverage
[10:14] <mzanetti> Cimi: if I run it on your branch its less
[10:15] <tsdgeos> lol
[10:15] <Cimi> mzanetti, let's fixthe script then
[10:15] <mzanetti> Cimi: ... (following code guidelines from mzanetti) ...
[10:15] <mzanetti> interesting... which ones?
[10:15] <mzanetti> :D
[10:16] <Cimi> mzanetti, when I asked you yesterday
[10:16] <mzanetti> Cimi: you mean the ordering of testcase and component
[10:16] <Cimi> yes
[10:16] <mzanetti> Cimi: yeah... its fine... I was just wondering... my guidelines? :D
[10:16] <Cimi> mzanetti, you now own a guideline, cheers :)
[10:19] <mzanetti> e
[10:23] <mzanetti> Cimi: mystery solved... and approved. cheers
[10:24] <Cimi> mzanetti, where was it? :)
[10:24] <mzanetti> untested OnScreenKeyboard.qml was removed in trunk but still present in your branch
[10:24] <Cimi> ah ok
[10:26] <mzanetti> we just reached > 50% coverage!
[10:26] <mzanetti> thanks everybody
[10:30] <Saviq> mzanetti, who told you to add phablet-team ppa? ;
[10:30] <Saviq> ;P
[10:30] <Saviq> and to upgrade from it!
[10:30] <Cimi> mzanetti, some tests are strikeout in the coverage document, means not needed?
[10:30] <mzanetti> Saviq: still, this is an issue
[10:31] <mzanetti> Saviq: I think our target should be to enable people to add the paa, no?
[10:31] <Saviq> mzanetti, not really, stuff should land in distro instead
[10:32] <mzanetti> Saviq: yeah... but I guess the packages in our ppa will be merged to the distro... as soon that happens it'll smash your system too
[10:32] <mzanetti> Cimi: yep
[10:33] <Saviq> mzanetti, I don't know what's changed in mountall
[10:36] <Saviq> mzanetti, looking at https://code.launchpad.net/~phablet-team/phablet-extras/mountall-quantal I'd say this should not land in distro
[10:37] <Saviq> mzanetti, but ping rsalveti or awe about it
[10:37] <mzanetti> Saviq: yeah, I will! thanks for the research!
[10:48] <nic-doffay> Guys, how can I compile the Hud with qmlscene?
[10:48] <nic-doffay> trying qmlscene Hud.qml
[10:55] <Cimi> tsdgeos, ^
[10:55] <dandrader> nic-doffay, you might need to pass the import path where the qml plugins it needs to run are located
[10:55] <dandrader> with -I path
[10:55] <Cimi> nic-doffay, there's a chance you nees -I and a path
[10:55] <tsdgeos> nic-doffay: the test?
[10:58] <nic-doffay> tsdgeos, not the test, the actual Hud.
[11:02] <tsdgeos> nic-doffay: why do you want to run the actual Hud with qmlscene?
[11:02] <nic-doffay> tsdgeos, just to take a look at it easily.
[11:03] <tsdgeos> i'm not sure it even works
[11:03] <tsdgeos> but sure, you'll have to pass the correct path to the HudClient plugin
[11:13] <tsdgeos> dednick: what creates unity.qmlproject.user ? QtCreator?
[11:13] <dednick> tsdgeos: yes
[11:13] <tsdgeos> ok
[11:14] <dednick> tsdgeos: yes
[11:15] <dednick> my bad
[11:15] <tsdgeos> ok
[11:15] <tsdgeos> :D
[11:26] <Cimi> someone *did* test Panel/IndicatorItem.qml?
[11:27] <Cimi> there's a Y in the document, but it's not green nor link on MR
[11:31] <tsdgeos> i'd say it's "part" of the regulra Indicators test
[11:31] <tsdgeos> maybe i'm mistaken
[11:33] <dandrader> Cimi, if you don't see a test for it then it's not tested. I would guess that original list was generated by checking which files were read by the tests
[11:33] <Cimi> dandrader, ok thx
[11:34] <dednick> anyone ever used the qml's item::mapFromItem ? it's driving me insane. trying to map a repeaters items to global position. i'm getting the correct location for the first item, but each subsiquent item is 2x the width of the previous item away...
[11:35] <tsdgeos> dednick: i used it once, worked without problems
[11:35] <tsdgeos> dednick: mapFromItem doesn't map width, you mean x?
[11:38] <dednick> tsdgeos: i mean the x of items after the first repeaters itms are 2xthe previous items width away.
[11:38] <dednick> so if the first items x's are 0, 28, 56, 84. when i do mapFromItem, i'm getting 0, 56, 112, 168
[11:38] <tsdgeos> right, you're probably maping it from the wrong item
[11:39] <dednick> but it shouldnt change the x scale if the item is in the parent heirachy surely?
[11:39] <tsdgeos> not sure
[11:39] <tsdgeos> try ignoring the repeater
[11:39] <tsdgeos> and map against the row
[11:40] <tsdgeos> or whatever is holding the repeaetr
[11:40] <dednick> i'm mapping to the indicator
[11:40] <dednick> indicator -> indicator row -> row -> row repeater -> item
[11:41] <dednick> bur i've tried doing it to a few of them with the same resules.
[11:41] <dednick> *results
[11:46] <nic-doffay> What's the deal with the frantic key presses when running qmlscene?
[11:46] <nic-doffay> It's really annoying.
[11:46] <dednick> tsdgeos: found the issue. me being a general idiot.
[11:47] <dednick> i was including the x,y of the item in the mapFromItem call, which was adding width...
[11:49] <dednick> tsdgeos: found the issue. I was including the x,y of the item in the mapFromItem call, which was adding width...
[11:49] <tsdgeos> ouch
[11:49] <dednick> yeah. pretty stupid
[11:50] <dednick> i take solice in the fact that i'm not the first to do it. found answer on the web ;)
[11:50] <Cimi> mzanetti, hey, I'm testing the Clock: I have two ways to get the text label: using objectName and grepping the label, or creating a readonly property alias of those labels
[11:50] <Cimi> mzanetti, which is the preferred?
[11:51] <mzanetti> Cimi: if possible, avoid API changes just for tests... prefer findChild()
[11:51] <Cimi> ok
[11:51] <mzanetti> Cimi: if the API already offers that property for other reason, use that because its faster than findChild()
[11:56] <dandrader> Saviq, is it so that the ApplicationLauncher plugin is not used anymore?
[11:56] <Saviq> dandrader, yes
[11:56] <dandrader> Saviq, can we nuke it?
[11:56] <Saviq> dandrader, yup
[11:56] <dandrader> Saviq, will do
[12:02] <Cimi> where do I find qt. javascript functions?
[12:03] <Cimi> I want to see if I can get a date from a string
[12:03] <Cimi> (testing Greeter's Clock)
[12:03] <Cimi> there's Qt.formatTime and Qt.formatDate, how about the opposite?
[12:04] <Cimi> found
[12:04] <Cimi> !
[12:04] <mzanetti> Cimi: interesting... where?
[12:04] <Cimi> but it's not documented
[12:04] <Cimi> http://qt-project.org/doc/qt-5.0/qtqml/qtqml-javascript-functionlist.html#date-objects
[12:05] <Cimi> actually I'm not sure that works
[12:05] <mzanetti> Cimi: Qt itself doesn't really ship any javascript functions... The javascript engine itself support the ECMA standard
[12:05] <Cimi> ah ok
[12:06] <mzanetti> Cimi: additionally Qt register a object (called "Qt") that offers a little functionality
[12:06] <mzanetti> Cimi: its mostly a subset of the QDateTime C++ class
[12:06] <Cimi> I was speaking of that
[12:06] <Cimi> yes
[12:06] <Cimi> do you know how can I do the opposite?
[12:06] <Cimi> check if a string is a regular date?
[12:08] <mzanetti> Cimi: not out of my head, no
[12:09] <mzanetti> Cimi: but does that make sense? I mean... the string is the direct output of Qt.formatDate()... No need to test if formatDate() works. Qt folks should test that inside Qt
[12:12] <Cimi> mzanetti, so I will check if those strings are not empty
[12:13] <mzanetti> Cimi: yeah, thats good. you can also compare with a static string I guess
[12:13] <Cimi> mzanetti, static string of that?
[12:14] <mzanetti> something linke this in the data() function:
[12:14] <mzanetti> { input: 123456; outputData: "Mon Feb. 12"; outputTime: "12:34" }
[12:15] <mzanetti> if you have a predefined input date (e.g. some unix timestamp) you can compare if the label holds that correct time
[12:15] <mzanetti> just an idea... not sure its really way to go...
[12:16] <mzanetti> not empty could in theory also be something like "Error converting date" which is not what we want
[12:19] <mzanetti> Cimi: ^ (not sure if you still saw it)
[12:20] <Cimi> mzanetti, do you think qt.formatTime returns that?
[12:20]  * Cimi tests
[12:21] <Cimi> mzanetti, just tested, qt returns empty string
[12:21] <mzanetti> Cimi: for what=
[12:21] <mzanetti> ?
[12:21] <Cimi> I tested passing "__date" to Qt.formatTime and formatDate
[12:21] <Cimi> instead the variable __date
[12:34] <mzanetti> tsdgeos: https://code.launchpad.net/~mzanetti/unity/phablet-copyright-headers/+merge/157858
[12:35] <Cimi> mzanetti, https://code.launchpad.net/~unity-team/unity/phablet.test_greeter-clock/+merge/157859
[12:36] <Cimi> mzanetti, my only question here is if I should change width and height to something else, these are half width and height of greeter/dash tests
[12:36] <mzanetti> Cimi: I'd say its fine
[12:37] <Cimi> ok
[12:37] <Cimi> works
[12:37] <mzanetti> Cimi: if you change it, then I guess childrenRect.height/width would be ok
[12:38] <Cimi> I should change to that?
[12:38] <Cimi> it does binding loop
[12:38] <Cimi> nevermind
[12:47] <mzanetti> Cimi: reviewed
[12:47] <davmor2> hey guys is there an actual package for autopilot if so what is it called or is it installed by default?
[12:48] <mzanetti> davmor2: autopilot-phablet
[12:48] <mzanetti> davmor2: if you're working with "the old unity" you can use python-autopilot
[12:48] <mzanetti> davmor2: both are in ppa:autopilot/ppa
[12:48] <davmor2> mzanetti: thanks
[12:49] <mzanetti> Cimi: could you do a quick check on this please: https://code.launchpad.net/~mzanetti/unity/phablet-copyright-headers/+merge/157858
[12:50] <mzanetti> Cimi: we need to merge this soon because I've enabled the check Jenkins and that will put Needs Fixing on all the other MP's until this is merged
[12:58] <tsdgeos> mzanetti: done
[12:58] <mzanetti> cheers
[13:04] <tsdgeos> we have 33 branches waiting for merge
[13:04] <tsdgeos> instead of down we're going up :D
[13:18] <tsdgeos> mzanetti: you getting https://code.launchpad.net/~paulliu/unity/phablet-add_unit_test/+merge/156859 ?
[13:19] <tsdgeos> mzanetti: want me to do https://code.launchpad.net/~mzanetti/unity/phablet-pageheader-tests/+merge/157711 ?
[13:19] <mzanetti> tsdgeos: sure
[13:20] <mzanetti> tsdgeos: hmm... the openeffect thing is indeed a bit strange
[13:20] <tsdgeos> yeah, may an artifact of that the class hasn't really much to test
[13:21] <tsdgeos> "class"
[13:21] <mzanetti> yeah
[13:23] <mzanetti> tsdgeos: but it would have potential for the coolest looking test :D
[13:24] <mzanetti> tsdgeos: well, dunno... I would have tested it quite differently... but not sure if its worth the effort to force paul to invest more time in it
[13:24] <mzanetti> there isn't much to test indeed. I guess he covered that bits. its not to too obvious
[13:31] <Cimi> mzanetti, was sleeping like a baby during lunch break :)
[13:32] <mzanetti> Cimi: :D
[13:32] <Saviq> guys, we'll be late
[13:32] <mzanetti> Saviq: should we just start or wait?
[13:32] <Saviq> mzanetti, go
[13:32] <mzanetti> ack
[13:33] <Saviq> greyback, your turn for notes
[13:33] <greyback> Saviq: ok
[13:34] <Cimi> dednick, nic-doffay standup
[13:35] <nic-doffay> Don't have a mic here Cimi .
[13:35] <Cimi> ok
[13:50] <Cimi> Saviq, are you going to merge the two dirs or shall I?
[13:51] <Saviq> Cimi, you
[13:51] <Cimi> ok
[13:51] <Cimi> Saviq, so to recap: qmluitests -> shell, unittests -> shell
[13:51] <paulliu> Is there copyright problem FTBFS?
[13:51] <Cimi> Saviq, and two appropriare macro
[13:51] <Cimi> *appropriate
[13:52] <Saviq> Cimi, yeah, the macro and the correct calls are already in place
[13:52] <Saviq> Cimi, you just need to movie it in a single CMakeLists.txt file
[13:52] <Saviq> *move
[13:53] <Cimi> ok
[13:55] <tsdgeos> paulliu: yes, merge with trunk
[13:56] <tsdgeos> Cimi: can you merge trunk again in here? https://code.launchpad.net/~unity-team/unity/phablet.test_responsiveflowview/+merge/157830
[13:57] <Cimi> tsdgeos, I will
[13:57] <paulliu> ok
[13:58] <tsdgeos> Cimi: ah wait, sorry no need
[13:58] <tsdgeos> we just need the copyright thing to work
[13:58] <tsdgeos> and i'll approve again
[13:58] <mzanetti> paulliu: what time is it at yours btw?
[13:58] <mzanetti> tsdgeos: thanks
[13:59] <Cimi> Saviq, in reality is slightly different http://paste.ubuntu.com/5692396/
[14:00] <Saviq> Cimi, right, we don't support the path, just the component name
[14:00] <Saviq> Cimi, but yeah
[14:00] <Saviq> Cimi, that looks fine
[14:00] <Cimi> mmm
[14:00] <Cimi> Saviq, maybe I am not that into cmake
[14:01] <Saviq> Cimi, that paste looks fine
[14:01] <Cimi> Saviq, but is not correct
[14:01]  * Saviq => meeting
[14:01] <Cimi> ok
[14:01] <Cimi> who helps me here?
[14:01] <mzanetti> Cimi: Saviq: that will break the default things
[14:01] <mzanetti> Cimi: I can
[14:01] <paulliu> mzanetti: 22:01
[14:01] <Cimi> ok will push in a branch mzanetti
[14:01] <paulliu> mzanetti: it's ok for me.
[14:01] <mzanetti> paulliu: poor guy daily standup at 9pm...
[14:02] <Cimi> mzanetti, lp:~unity-team/unity/phablet.merge_qmluitests-unittests
[14:03] <mzanetti> Cimi: all you need to do is to remove line 15 and 16 from the paste
[14:03] <Cimi> ok
[14:03] <Cimi> mzanetti, but all files into this dir
[14:03] <Cimi> mzanetti, will be moved under shell/Components
[14:04] <Cimi> mzanetti, with the same CMakeFile used for qmluitests
[14:04] <Cimi> how can that work?
[14:05] <mzanetti> Cimi: you need to merge unittests/Components/CMakeLists.txt and qmluitests/Components/CMakeLists.txt too
[14:05] <mzanetti> Cimi: "shell/Components" ?
[14:05] <paulliu> tsdgeos: trunk is lp:unity/phablet, right?
[14:05] <mzanetti> paulliu: yes
[14:05] <Cimi> mzanetti, tests/shell/Components
[14:05] <Cimi> qmluitests => shell
[14:06] <paulliu> mzanetti: hmm, I merged. But CI build failed.
[14:06] <mzanetti> Cimi: I don't know why you want to rename that too... just leave it qmluitests
[14:06] <Cimi> mzanetti, following michal mail
[14:06] <mzanetti> Cimi: ok then... well, just rename it then
[14:06] <mzanetti> whats the problem?
[14:07] <paulliu> https://code.launchpad.net/~paulliu/unity/phablet-add_unit_test/+merge/156859
[14:07] <Cimi> mzanetti, the problem is that to me they will be treated like qmluitests
[14:07] <Cimi> mzanetti, because the cmakelist is the same
[14:07] <Cimi> mzanetti, so they have one target?
[14:07] <Cimi> mzanetti, otherwise for each subdirectory I need to add a special target for unittests
[14:07] <mzanetti> Cimi: yeah
[14:07] <mzanetti> isn't that what you want?
[14:08] <Cimi> I'll try to do it and ask you for a review
[14:08] <Cimi> I don't know how this cmake works
[14:08] <mzanetti> Cimi: I don't see the point in moving the files together but keeping separate make targets
[14:09] <mzanetti> actually I don't see the point in moving them together at all...
[14:09] <Cimi> mzanetti, so why we agreed on that on the standup?
[14:09] <mzanetti> I'm not against it... If you all want it... just said I don't see the point
[14:12] <nic-doffay> Some QML file structure queries if anyone has a second. I have infographics currently with those dots representing days in the Infographics.qml, however I'd like to make the "day dot" a separate component. Firstly is this overkill?
[14:13] <mzanetti> nic-doffay: we can't know unless we see how much code it actually is
[14:13] <nic-doffay> It will probably be a fair amount mzanetti
[14:13] <mzanetti> nic-doffay: sounds ok to me...
[14:15] <nic-doffay> Ok, in that case how should the folder hierarchy be structured mzanetti ? Shall I put everything in Infographics/ (I imagine there will be more than one component) or just keep all the separate components in /Greeter?
[14:15] <nic-doffay> If other components are created for the Greeter this could create clutter.
[14:15] <nic-doffay> And confusion.
[14:17] <mzanetti> nic-doffay: dunno... can't tell without seeing the code. I wouldn't worry too much as long as you have only 3 files. its easy to move them around afterwards if it turns out to get cluttered
[14:19] <nic-doffay> Thanks for the comments mzanetti I'll keep everything in one file until it grows a sizeable amount.
[14:19] <Cimi> mzanetti, my new cmake doesn't work as the previous... so I'll gently skip that :)
[14:20] <Cimi> (make test doesn't run unittests anymore)
[14:20] <mzanetti> Cimi: ?
[14:20] <mzanetti> Cimi: yeah... that was expected
[14:20] <mzanetti> Cimi: well... It still should run qsortfiltermodeltest
[14:20] <Cimi> it does
[14:20] <Cimi> mzanetti, anyway, let's keep separate for now
[14:20] <mzanetti> Cimi: then you're fine I'd say
[14:21] <Cimi> I'll adapt tests with the discussed guidelines
[14:21] <Cimi> and update readme
[14:21] <mzanetti> Cimi: thats was the reason for the separation... to have tests that can run as unittests in that target
[14:21] <mzanetti> Cimi: but in jenkins we execute all tests anyways, that's why I don't have a stron opinion on it
[14:37] <mzanetti> dednick: FYI: lp:~nick-dedekind/unity/phablet-test-indicators requires a merge of trunk to pass CI again
[14:38] <dednick> mzanetti: hm. i just did it about 30 min ago...
[14:39] <dednick> let me check again
[14:39] <mzanetti> dednick: ok... sorry... I was just browsing through the failed jenkins jobs
[14:39] <mzanetti> the job in question was started 37 mins ago...  :)
[14:40] <dednick> mzanetti: i just triggered a rebuild. i pushed about 40 minutes ago
[14:46] <dednick> mazhm. i need to run a test suite once for fullscreen, and once for not.
[14:46] <dednick> fek
[14:46] <dednick> mzanetti: i need to run a test suite once for fullscreen, and once for not. what would be the best way to do that?
[14:46] <mzanetti> rofl
[14:47] <nic-doffay> What's the gu to pixel for the phone?
[14:47] <mzanetti> dednick: Father ted?
[14:47] <mzanetti> dednick: what kind or tests?
[14:47] <dednick> mzanetti: fullscreen just being a flag for the indicators
[14:48] <dednick> mzanetti: panel tests. it's just a flag that needs to be set, but the behaviour should be the same. so dont really want to replicate tests.
[14:48] <mzanetti> dednick: a _data() function?
[14:49] <mzanetti> { tag: "windowed"; fullscreenFlag: false }
[14:49] <mzanetti> { tag: "fullscreen"; fullscreenFlag: true }
[14:49] <mzanetti> dednick: you understand what I mean?
[14:49] <mzanetti> nic-doffay: depends on the screen
[14:49] <dednick> mzanetti: nope :)
[14:50] <mzanetti> dednick: let me write a pastebin snippet... one sec
[14:50] <nic-doffay> For the Nexus 7 lets say mzanetti
[14:50] <mzanetti> I think that was 16
[14:50] <nic-doffay> Cool thanks, just wanted to get some point of reference.
[14:50] <dednick> i remember seeing a list somewhere.
[14:50] <mzanetti> nic-doffay: the Galaxy Nexus has 18 iirc
[14:51] <mzanetti> nic-doffay: I use 20 on my Laptop with Retina screen
[14:51] <mzanetti> nic-doffay: bottomline: your code should not care about it
[14:51] <nic-doffay> It doesn't.
[14:51] <mterry> didrocks, cu2d-config has been updated, needs your archive-admin powers to make it final.  Also, maybe you want to review https://code.launchpad.net/~mterry/cupstream2distro-config/media-signals/+merge/157726 while you're thinking on cu2d-config stuff
[14:52] <Cimi> mzanetti, you can kill me https://code.launchpad.net/~unity-team/unity/phablet.tests_coding-style/+merge/157888
[14:52]  * Cimi runs
[14:52] <Cimi> well the refactoring branch is there ^
[14:53] <mzanetti> dednick: https://pastebin.canonical.com/88768/
[14:53] <mzanetti> dednick: the test_seomething() function will now be called for every row in the _data() function
[14:54] <mzanetti> dednick: so you run the same test twice with different parameters
[14:55] <dednick> mzanetti: ah. awesome
[14:55] <dednick> thanks
[14:56] <didrocks> mterry: two questions, is that what's need qt5?
[14:56] <mterry> didrocks, can you rephrase that?
[14:57] <didrocks> mterry: you uploaded qt5 to the ppa
[14:57] <didrocks> is it needed for anything?
[14:57] <didrocks> those patches can't be into raring?
[14:57] <mterry> didrocks, the patch was for qtubuntu.  I didn't put it in raring because it changes which symbols are exposed
[14:58] <didrocks> mterry: ok, and now looking at qtubuntu-media-signals
[14:58] <mterry> didrocks, it just adds symbols (doesn't take them away), but it still felt like a feature break
[14:58] <didrocks> mterry: this is qtubuntu-media?
[14:58] <Cimi> dandrader, https://code.launchpad.net/~unity-team/unity/phablet.tests_coding-style/+merge/157888
[14:58] <mterry> didrocks, this is qtubuntu-media-signals
[14:59] <mterry> didrocks, I'm still draining the swamp to get to my own package
[14:59] <mterry> didrocks, once this is in the PPA I can propose a patch for qtubuntu-media itself
[14:59] <didrocks> mterry: ok, I don't see it on the spreadsheet though
[15:00] <dandrader> Cimi, checking
[15:00] <didrocks> mterry: like, in term of tests, integration tests and so on
[15:00] <mterry> didrocks, ah yeah.  This was a late addition (it wasn't on our roadmap until I realized it was needed).  It's a super tiny package, like 20 lines of code.  So it doesn't have any tests  :-/  But I can add to spreadsheet
[15:01] <didrocks> mterry: ok, just add it please and add that you have the feeling tests are not needed :)
[15:01] <didrocks> mterry: then, you ping me so that I pull for that stack or something else?
[15:02] <didrocks> mterry: I saw that qtubuntu-sensors has been added when we shouldn't as per the spreadsheet
[15:02] <mterry> didrocks, added to spreadsheet.  What's that about pulling?
[15:03] <mterry> didrocks, qtubuntu-sensors is really xnox's package.  I added it to the stack though in order to get to my own packages
[15:03] <mzanetti> tsdgeos: autolanding the header fixes failed :/ I fear we were too early with thelling people to merge trunk
[15:03] <didrocks> mterry: the tests are not read apparently :/
[15:03] <didrocks> mterry: so I'm not confortable adding it
[15:03] <tsdgeos> mzanetti: :-/
[15:03] <mterry> xnox, ^
[15:03] <tsdgeos> mzanetti: what went wrong?
[15:04]  * xnox is getting a raring chroot up on nexus7 to test out sensors.
[15:04] <tsdgeos> mzanetti: can we kill all the autoloanding jobs until that one is the first again?
[15:04] <mterry> didrocks, it would be really nice to decouple a "tests are acceptable for distro" check-off and the work to get these packages into the PPA in the first place
[15:04] <mzanetti> tsdgeos: ci failed because of the hanging qmluitests and posted a needs fixing just before autolanding would have merged
[15:04] <didrocks> mterry: you mean pushing the stuff in the ppa without having tests?
[15:04] <mzanetti> tsdgeos: yeah... I'll kill the queue
[15:04] <mterry> didrocks, tests are something distro can't really write for PS, so it's blocking our work to daily-release these
[15:04] <mterry> didrocks, they're in a PPA now without tests.  We're just changing the PPA
[15:07] <didrocks1> mterry: sorry, got disconnected
[15:07] <mterry> didrocks, I said...
 didrocks, tests are something distro can't really write for PS, so it's blocking our work to daily-release these
 didrocks, they're in a PPA now without tests.  We're just changing the PPA
[15:08] <didrocks1> mterry: yeah, one time push is fine, just not daily release ;)
[15:08] <didrocks1> mterry: the spreadsheet is there to make the separation, right?
[15:09] <didrocks1> mterry: do you mind putting qtubuntu-sensors if not good to to_transition:
[15:09] <mterry> didrocks, I just think we're making things harder on ourselves.  Distro can make the packaging better and get everything under distro release ourselves.  But tests should be driven by PS.  We can tell PS that we won't copy the PPA into the archive until tests are finished, but I don't see why we block our *own* work on PS
[15:09] <didrocks1> mterry: and feel free to upload it once :)
[15:10] <didrocks1> mterry: if you stay and everyone stays on that line, that's fine by me
[15:10] <mterry> didrocks1, or at least, if we *are* going to block our own work, can we light a fire under xnox?  :)
[15:10] <didrocks1> mterry: but I know what will happen…
[15:10] <didrocks1> "put that in distro now"
[15:10] <didrocks> mterry: that's why "one manual upload" is unblocking you, isn't it?
[15:11] <mterry> didrocks, yeah it would.  But I'm leery of future changes making more manual uploads necessary
[15:11] <mterry> but OK
[15:11] <didrocks> mterry: let's do manual and ensure we are pushing upstream with deadlines
[15:12] <didrocks> as I had to do with unity upstream
[15:12] <didrocks> and we can see the result now :)
[15:12] <didrocks> otherwise, we'll slip over and nothing good will be out of this
[15:12] <didrocks> (like for indicators)
[15:12] <xnox> didrocks: mterry: i think with sensors & platform-api it's not that tests are not there, it's non-trivial to have tests as they are tied in against android hw layer.
[15:12] <mterry> didrocks, alright, I pushed to config trunk a change to make qtubuntu-sensors in transition
[15:12] <xnox> and solving how those will be run on daily basis is the key point.
[15:12] <didrocks> xnox: if we are telling "we can't run them by now", I'm fine with it as long as it's logged and known
[15:13] <didrocks> mterry: ok, let me pull that, thanks! you are deploying, isn't it?
[15:13] <xnox> cause there is no way to run them at package build-time nor on distro-builders.
[15:13] <mterry> didrocks, guh!  no, let me deploy.  I forgot that was a step
[15:13] <didrocks> :)
[15:14] <mterry> didrocks, now deployed
[15:14] <mterry> didrocks, but there's nothing to do anymore, since that was my one change
[15:14] <mterry> didrocks, (enabling it then disabling it)
[15:14] <didrocks> mterry: you didn't deploy the media stuff?
[15:14] <mterry> didrocks, it's not landed in trunk yet
[15:14] <mterry> didrocks, just MP
[15:15] <didrocks> mterry: approved
[15:15] <didrocks> mterry: so you can deploy :p
[15:15] <mterry> didrocks, I've been trying to do things in serial, but I guess I should just do a lot of one-off uploads and then do a mass migration in the config
[15:15] <didrocks> mterry: that's fine as well
[15:17] <mterry> ls
[15:17] <mterry> heh, whoops
[15:17] <didrocks> :p
[15:25] <mterry> didrocks, OK.  Media stack added and deployed
[15:26] <didrocks> mterry: I will pull the branch ASAP :)
[15:26] <nic-doffay> Are there any generally accepted trends when commenting QML files?
[15:27] <mterry> nic-doffay, you mean like gtk-doc syntax or not or just whether to use // or /*?
[15:27] <didrocks> mterry: thanks!
[15:27] <nic-doffay> gtk-doc syntax mainly mterry
[15:27] <mterry> nic-doffay, I've mostly seen // but I haven't seen anything commented as rigorously as gtk-doc style
[15:28] <nic-doffay> So simple // wherever is generally fine?
[15:28] <mterry> nic-doffay, but I've just poked around unity-next, not an expert
[15:28] <mterry> nic-doffay, that's what I've seen
[15:28] <nic-doffay> Cool.
[15:29] <mzanetti> nic-doffay: yeah... explaining internal stuff is fine with // or /* */
[15:30] <mzanetti> nic-doffay: I don't think you need an API doc for what you do right now
[15:32] <nic-doffay> Cool thanks mzanetti
[15:32] <nic-doffay> Another quick question
[15:32] <nic-doffay> Why is an assignment made in this: https://pastebin.canonical.com/88773/
[15:33] <nic-doffay> (It's off the QML tuts)
[15:33] <nic-doffay> I read elsewhere yesterday that assignments weren't done in QML.
[15:33] <nic-doffay> On the same docs.
[15:33] <mzanetti> nic-doffay: because onClicked: is executed as in imperative code
[15:34] <mzanetti> nic-doffay: the cellColor for example is read at startup and cellColor: "red" will remain throughout the whole lifetime
[15:34] <mzanetti> nic-doffay: the helloText.color = cellColor is only exected once when you click on it
[15:34] <nic-doffay> Thanks mzanetti I found a page detailing it.
[15:35] <nic-doffay> If anyone else is interested: http://qt-project.org/doc/qt-5.0/qtqml/qtqml-syntax-objectattributes.html#imperative-value-assignment
[15:43] <didrocks> mterry: if you see more components that you need, do not hesitate to mark them as WI (you did the work after all!) and to request help from sil2100 if needed
[15:52] <Cimi> dandrader, https://code.launchpad.net/~unity-team/unity/phablet.tests_coding-style/+merge/157888
[15:53] <Cimi> update
[15:59] <Cimi> mzanetti, so, what to test of /Panel/IndicatorItem.qml ?
[16:01] <Cimi> tsdgeos, can you reapprove this? https://code.launchpad.net/~unity-team/unity/phablet.test_responsiveflowview/+merge/157901
[16:02] <sil2100> mterry: indeed - push anything that you I could work on to me ;)
[16:03] <mzanetti> Cimi: set an icon/text and check if the width adjusts accordingly
[16:07] <tsdgeos> Cimi: sure, i dreamt i did it already
[16:07] <tsdgeos> what did i approve if not that?
[16:07]  * tsdgeos checks
[16:07] <Cimi> tsdgeos, you did, but I merged trunk
[16:07] <Cimi> tsdgeos, and superseeded
[16:07] <tsdgeos> i mean 5 minutes ago
[16:07] <Cimi> ah ok
[16:08] <tsdgeos> ahh
[16:08] <tsdgeos> you did this 15 min ago
[16:08] <tsdgeos> ok
[16:08] <tsdgeos> maybe my 5 minutes was 16 minutes ago :D
[16:08] <Cimi> tsdgeos, I'm glad I'm not a girl and I'm not having a date with you :)
[16:09] <tsdgeos> Cimi: i'd be more careful :-P
[16:09] <Cimi> lol
[16:15] <tedg> pete-woods, Thinking, we'll need to choose what data set to show by default in the greeter....
[16:15] <tedg> pete-woods, Thinking the default setting should be the data set with the highest standard deviation.
[16:16] <tedg> pete-woods, That one is likely to have the most interesting graphic.
[16:16] <tedg> Anyway, random thought.
[16:21] <pete-woods> tedg: it'll have to be something statistical, yes!
[16:21] <pete-woods> tedg: I believe there is the idea that some sets are more important, like I don't know 3G data usage, or high battery usage?
[16:21] <mterry> didrocks, if I'm uploading to PPA manually, and the UNRELEASED version in trunk is 0.3, will I screw daily-release up if I upload with 0.3~manual1?
[16:22] <tedg> pete-woods, Yeah, but I imagine you'd want to choose the one that's the most interesting for that user.  It's about personalization.
[16:22] <tedg> pete-woods, They user would of course be able to explicitly set.  But, by default we're going to have to choose one.
[16:23] <didrocks> mterry: no, it will try to upload the first time 0.3daily<…>
[16:23] <didrocks> mterry: so good :)
[16:24] <pete-woods> tedg: yep, I don't know for sure if SD is necessarily the right choice, but there does need to be some indicator of activity
[16:24] <tedg> Hmm, got an e-mail from LinkedIn that pete-woods visited my profile.  LinkedIn is creepy.
[16:24] <mterry> didrocks, thanks
[16:24] <tedg> pete-woods, Sure, I was thinking interesting graphic there.
[16:24] <pete-woods> tedg: yes, I've started getting connection requests from Canonical folks now
[16:25] <pete-woods> a whole new cluster of linked in folks
[16:25] <didrocks> mterry: yw! it's only if things hit the "dest" ppa (like if it hitted "distro") that he wants it
[16:25] <didrocks> (on the changelog)
[16:26] <tedg> pete-woods, Ha!  That is a cool visualization.
[16:27] <Cimi> mzanetti, mmm
[16:27] <Cimi> mzanetti, IndicatorItem
[16:28] <Cimi> mzanetti, has label and iconSource
[16:28] <Cimi> but where are thos properties defined?
[16:28] <mzanetti> Cimi: thats the API to be tested
[16:28] <Cimi> mzanetti, there are not defined
[16:28] <Cimi> *they
[16:28] <mzanetti> Cimi: ?
[16:28] <Cimi> mzanetti, iconSource is what?
[16:29] <mzanetti> Cimi: you set that from the outside
[16:29] <Cimi> mzanetti, but item doesn't have this property
[16:29] <dandrader> Cimi, they probaly come from the context, injected from the model, if IndicatorItem is being used as a delegate
[16:29] <Cimi> aaaahn ok
[16:30] <dandrader> yes, it's cryptic
[16:31] <Cimi> dandrader, so how do I use them in tests?
[16:31] <Cimi> dandrader, I simply add IndicatorItem { iconSource = "...." }
[16:31] <Cimi> assuming is used?
[16:32] <dandrader> Cimi, I don't know, I never faced this situation myself
[16:32] <Cimi> if someone knows, here we are :)
[16:32] <dandrader> I think dednick had this problem before
[16:33] <dednick> Cimi: they are defined in the PluginModel. Items of a Repeater can access the model roles in the same way as properties
[16:34] <dednick> Items of a model i should say.
[16:34] <Cimi> mmm shall I use a model then?
[16:35] <dednick> Cimi: there is a fake one defined in Panel/qml/Ubuntu/ChewieUI/PluginModel.qml. It's used to mimic behaviour of the indicator model in chewieui.
[16:35] <dednick> which is what you want?
[16:36] <Cimi> dunno
[16:36] <mzanetti> Cimi: hmmm... now I understand... sorry
[16:36] <dednick> what are you testing? IndicatorItem?
[16:36] <Cimi> dednick, yes
[16:36] <dednick> then yes, you can use that
[16:37] <mzanetti> Cimi: dednick: shouldnt the item be fixed to offer those two properties as an API?
[16:37] <dednick> mzanetti: yeah. i think i was told not to when i wrote the tests ;). although i didnt really do it in a nice way.
[16:38] <mzanetti> yeah... its a thin path
[16:38] <mzanetti> imho this one would justify a fix
[16:38] <dednick> although i'm not really sure if you can just alias the model roles as a property. something you can try Cimi.
[16:38] <mzanetti> yeah, alias would work
[16:39] <mzanetti> just add property alias iconSource: image.source
[16:39] <mzanetti> and then, where the IndicatorItem is used, set those properties from the outside
[16:39] <mzanetti> as that one is the file where the model actually lives (hopefully :D)
[16:39] <mzanetti> Cimi: is that ok for you?
[16:40] <Cimi> ok
[16:41] <dednick> mzanetti: not sure if that will work without an attached model? the icon.source is bound to the model's iconSource role. wont that just either cause a failure, or some crazy recursion?
[16:41] <dednick> source: iconSource
[16:41] <mzanetti> dednick: no... local context has priority
[16:42] <mzanetti> dednick: if there are conflicts, you can access model stuff with model.iconSource
[16:42] <dednick> zequence:
[16:42] <dednick> fek
[16:42] <Cimi> other question, I never have to add the @18.png just .png is fine right?
[16:42] <mzanetti> dednick: but if you just call iconSource and there is a local property with that name, the local one is used
[16:43] <dednick> but if the local one is an alias?
[16:43] <mzanetti> Cimi: yep. never add that. its the job if the SDK internals to do that
[16:43] <Cimi> ok
[16:43] <mzanetti> dednick: doesn't matter... its a property. no matter of which type
[16:43] <Cimi> mzanetti, but I don't have Ubuntu components imported
[16:43] <Cimi> mzanetti, so first I have to import them I guess, right?
[16:43] <mzanetti> Cimi: yeah. import them
[16:45] <mzanetti> dednick: Cimi: https://pastebin.canonical.com/88782/
[16:46] <mzanetti> and where you use it, just set "text: label" and "iconSource: model.iconSource"
[16:47] <Cimi> mzanetti, public pastebin pls
[16:47] <Cimi> paste.ubuntu.com
[16:47] <Cimi> (don't have my phone here :-)))
[16:47] <mzanetti> Cimi: oh... ok
[16:47] <Cimi> mzanetti, anyway if it's for the alias, I've already used it
[16:47] <Cimi> mzanetti, or you can do bzr diff Panel/IndicatorItem.qml | pastebinit
[16:48] <dednick> Cimi: http://pastebin.ubuntu.com/5692847/
[16:48] <Cimi> yep was exactly what I did
[16:48] <mzanetti> Cimi: http://paste.ubuntu.com/5692848/
[16:48] <mzanetti> ah
[16:48] <Cimi> the trick above is pro though :)
[16:48] <Cimi> bzr diff filename | pastebinit
[16:49] <mzanetti> hehe
[16:49] <Cimi> be sure to apt-get install pastebinit
[16:49] <mzanetti> indeed
[16:49] <mzanetti> Cimi: I have an icon in my panel ans when I drag&drop stuff on it it pastes it
[16:49] <Cimi> that's even more pro
[16:49] <Cimi> :)
[16:50]  * bschaefer installs pastebinit
[16:50] <mzanetti> hehe
[16:54] <mterry> cyphermox, you around today?
[16:55] <didrocks> fginther: do you mind having a look at https://code.launchpad.net/~robru/cupstream2distro-config/webbrowser-app/+merge/157917 for the CI part?
[16:55] <didrocks> robru: ^
[16:56] <cyphermox> mterry: yeah
[16:56] <cyphermox> I'm always around
[16:56] <mterry> cyphermox, :)  I see that hud failed to build in the PPA
[16:56] <cyphermox> whether i'm temporarily not answering due to debugging is another matter though
[16:56] <cyphermox> yeah
[16:56] <cyphermox> don't worry about it, I'm looking at this with sil right now
[16:56] <mterry> cyphermox, cool!
[16:57] <cyphermox> mterry: I'll be doing another upload and hopefully that one will be good, then we'll know it builds fine on all arches and we can start the daily release
[16:57] <mterry> cyphermox, awesome, thanks man!
[16:59] <cyphermox> mterry: hud is waiting on a ci job right now, which may or may not be failing due to tests
[16:59]  * cyphermox runs off to grab food
[17:09] <mzanetti> Cimi: I'd have a test now that does not require any window... should I put it to unittests or qmluitests then?
[17:09] <Cimi> unittests
[17:09] <mzanetti> ack
[17:09] <Cimi> mzanetti, I believe we won't move to a new structure until we all agree and we don't have functionality regressions
[17:10] <mzanetti> Cimi: ok... I wrote my opinion on it to the ML. I'm fine with either way.
[17:17] <Cimi> mzanetti, https://code.launchpad.net/~unity-team/unity/phablet.test_IndicatorItem/+merge/157919
[17:17] <Cimi> I'm done for today ;)
[17:18] <Cimi> like I don't think I can start a new test and finish in good time, better go to the gym :D
[17:19] <mzanetti> Cimi: https://code.launchpad.net/~mzanetti/unity/phablet-test-sidestage/+merge/157921
[17:19] <mzanetti> I'm done too
[17:19] <Cimi> mzanetti, I can review that tomo morning
[17:19] <mzanetti> Cimi: sure. no problem
[17:19] <mzanetti> Cimi: have fun at the gym
[17:20] <Cimi> mzanetti, I bet no fun and lots of sweat
[17:20]  * Cimi is doing heavy HIIT
[17:20]  * mzanetti tries to have fun when doing sports
[17:20] <mzanetti> but thats why I don't go to the gym but rather running or biking
[17:20] <Cimi> mzanetti, running is fun, running with HIIT is not fun
[17:21] <cyphermox> HIIT?
[17:21] <Cimi> unless you're masochist :)
[17:21] <Cimi> high intensity interval training
[17:21] <mzanetti> Cimi: FYI, your test doesn't need to be a qmluitest
[17:21] <mzanetti> Cimi: it would make a nice unittest :D
[17:21] <Cimi> I basically run 1 min at 15-16Km/h, 1 min 11km/h... that for 40 min
[17:21] <cyphermox> Not that beep test thing?
[17:21] <cyphermox> Yuck.
[17:22] <Cimi> it's deadly hard
[17:22] <Cimi> mzanetti, why not? it required a window no?
[17:22] <cyphermox> Thought it would be something like running/hiking with weights
[17:22] <mzanetti> Cimi: no not really
[17:22] <mzanetti> Cimi: you don't do any mouse or keyboard interaction
[17:23] <mzanetti> Cimi: just calculating some integers can be done in memory only
[17:23] <Cimi> mzanetti, I thought it was depending on showing things on screen
[17:23] <mzanetti> Cimi: yeah... you would need to remove the "when: windowShown" then it would execute the same test without a window
[17:23] <Cimi> mzanetti, so if I move the file to unittests and move TestCase to parent, will work?
[17:23] <mzanetti> Cimi: no need to move the TestCase to parent either
[17:23] <Cimi> ok
[17:24] <mzanetti> Cimi: just remove "when: windowSowhn"
[17:24] <Cimi> mzanetti, ok I'll move it under unittest
[17:24] <Cimi> so it's ready for your review tomo
[17:24] <mzanetti> Cimi: ok then. I'm off too. see you all tomorrow!
[17:25] <Cimi> (I'm finding excuses to postpone the HIIT)
[17:25] <Cimi> ciao!
[17:27] <Cimi> (ok that was quick, pushed)
[17:28] <Cimi> mzanetti, in reality I need the findChild
[17:28] <Cimi> I'll add the proper import
[17:28] <mzanetti> Cimi: wait
[17:28] <mzanetti> Cimi: I have the same problem too
[17:29] <mzanetti> Cimi: I just did the quick&dirty way of importing ../../qmluitests
[17:29] <Cimi> yep
[17:29] <Cimi> not nice?
[17:29] <mzanetti> Cimi: but if this is a common thing we should probably move the UnityTestCase away to tests/imports/testhelpers.js or something like this
[17:29] <Cimi> +1
[17:30] <mzanetti> Cimi: and then import testhelpers.js wherever we need findChild
[17:30] <Cimi> but let's do this in a separate branch
[17:30] <mzanetti> ack. then lets merge our two first with the quick&dirty one
[17:31] <mzanetti> Cimi: if you want you can take care of that tomorrow... otherwise I'll do it at some point tomorrow
[17:31] <Cimi> ok
[17:58] <mterry> didrocks, are we not upstream for hybris?
[17:59] <didrocks> mterry: I don't think so from what I understood from ogra
[17:59] <mterry> didrocks, oh, hm.  We have some code in there anyway
[17:59] <didrocks> mterry: right, it's part of the "patched" things
[18:00] <mterry> didrocks, yar
[18:00] <didrocks> mterry: one sec, sergio is assigned to push it to distro
[18:01] <mterry> didrocks, it's homepage is apparently not up now
[18:01] <didrocks> https://blueprints.launchpad.net/ubuntu/+spec/client-1303-ubuntu-touch-porting
[18:01] <didrocks> [rsalveti] Update the libhybris codebase to be upstream compatible (we want the upstream based version at raring): INPROGRESS
[18:01] <didrocks> mterry: ^
[20:07] <slangasek> mterry: hey, so didrocks intimated that you might be the one to look at whatever unity integration test failures are blocking my super-important compiz fix from reaching raring
[20:08] <slangasek> mterry: do you have a handle on it?  are the failures my fault?  anything I can do to help?
[20:08] <mterry> slangasek, hrm, maybe.  Or at least point you at someone else  :)
[20:08] <mterry> slangasek, can you point me at a log?
[20:08] <slangasek> mterry: only an IRC log ;P
[20:08] <mterry> slangasek, oh I see what you mean, sure.  give me a sec
[20:10] <mterry> fginther, I'm having trouble connecting to the jenkins VPN
[20:12] <mterry> slangasek, sorry, technical difficulties
[20:15] <fginther> mterry, sorry, I can't get to it either
[20:17] <mterry> slangasek, there is problem with the QA labs network right now, I can't check for you
[20:17] <slangasek> mterry: oh bother
[20:18] <mterry> slangasek, if it's super urgent, you can always just distro-patch it like old times
[20:18] <mterry> slangasek, it won't screw up daily-releasing, we'll just have a bit of paperwork to do to sync back up
[20:18] <slangasek> mterry: nah, it's not super-urgent, it's just that I spent a lot of time tracing that bug down and I want instant gratification ;)
[20:18] <mterry> slangasek, :)
[20:18] <slangasek> mterry: for my edification, if the QA lab weren't having trouble, where would I look to see the test failures?
[20:19] <mterry> slangasek, there's an internal-VPN that has a jenkins web UI to look at
[20:19] <mterry> slangasek, if you expect you have access already, I can give you a URL
[20:20] <slangasek> mterry: I do have access, but don't have the url
[21:45] <fginther> cyphermox_, ping
[21:54] <fginther> bregma, compiz/0.9.9 ?
[23:35] <cyphermox_> fginther: pong