[07:08] <Saviq> aaand we're back to red CI
[07:09] <mzanetti> \o/
[07:10] <jbermudes> Does anyone know how difficult it would be to edit the unity-2d-launcher to have the tooltip text always showing next to the icon like a label?
[07:13] <Saviq> jbermudes, shouldn't be too difficult, dig in this file http://bazaar.launchpad.net/~unity-2d-team/unity-2d/trunk/view/head:/shell/launcher/LauncherItem.qml
[07:15] <mzanetti> Saviq: doesnt look so red to me
[07:15] <Saviq> mzanetti, MacSlow's fix for notifications got merged like 10mins ago
[07:15] <Saviq> s/fix/workaround/
[07:15] <mzanetti> oh..
[07:16] <Saviq> but it didn't have the necessary skip() in the tests it affected :/
[07:17] <mzanetti> Saviq: mind removing your Needs Fixing here? https://code.launchpad.net/~mzanetti/unity8/new-lockscreen-design/+merge/230478
[07:17] <Saviq> mzanetti, will check
[07:17]  * mzanetti things this looks quite bad now...
[07:17] <mzanetti> thinks
[07:19] <MacSlow> mzanetti, Saviq: what's missing?
[07:20] <Saviq> MacSlow, your workaround broke a test verifying that the animation is happening
[07:20] <Saviq> MacSlow, so it's missing a skip()
[07:22] <MacSlow> Saviq: but didn't it pass Jenkins yesterday?
[07:23] <Saviq> MacSlow, no
[07:23] <MacSlow> Saviq, so how could it get merged then?
[07:23] <Saviq> MacSlow, https://code.launchpad.net/~macslow/unity8/disable-opacity-animation-1354406-workaround/+merge/231588/comments/563565
[07:23] <Saviq> MacSlow, because jenkins pass isn't required for a merge
[07:24] <Saviq> newsflash, we've had non-passing jenkins for like the past month ;)
[07:24] <Saviq> and that didn't stop us from landing things
[07:24] <MacSlow> :)
[07:25] <Saviq> but I kinda hoped for this situation to end for at least some time...
[07:25] <mzanetti> MacSlow: guess why there is a point "did CI ran pass?" in the checklist
[07:26] <jbermudes> Saviq: Thanks, I'll take a look
[07:26] <mzanetti> MacSlow: now we only would need use that
[07:28] <MacSlow> mzanetti, for unity8 there's no ci-related bullet-point in the required checklist
[07:28] <mzanetti> MacSlow: you didn't ever do a review so far?
[07:29] <Saviq> MacSlow, https://wiki.ubuntu.com/Process/Merges/Checklists/Unity8#preview
[07:30] <Saviq> " * Did CI run pass? If not, please explain why."
[07:30] <Saviq> MacSlow, in the review one, not submission
[07:30] <MacSlow> Saviq, mzanetti: I was referring to the submission-checklist
[07:31] <Saviq> MacSlow, when submitting, you don't know if CI will pass, so would be kinda weird
[07:31] <MacSlow> Saviq, indeed
[07:31] <Saviq> MacSlow, and we don't want to require you to run all the tests locally, because that what we have CI for
[07:35] <tsdgeos> MacSlow: lp:~macslow/unity8/fix-1348092 does not merge cleanly
[07:36] <MacSlow> tsdgeos, I look into that once I've sorted out the current qml-test failure
[07:36] <tsdgeos> ok
[07:38] <MacSlow> Saviq, I can't see the relation between the current qml-test failure of notifications and the disabled animations
[07:39]  * MacSlow looks for sugar and caffeine
[07:41] <Saviq> MacSlow, well, those tests passed yesterday, don't today, they're in notifications...
[07:41] <Saviq> MacSlow, most probably something depends on opacity
[07:42] <Saviq> MacSlow, so yeah, your workaround broke sounds in notifications
[07:42] <Saviq> Notification.qml:85
[07:43] <tsdgeos> Saviq: i'm going to discard https://code.launchpad.net/~unity-team/unity8/category-transition-speed-fix/+merge/203898
[07:43] <MacSlow> Saviq, *sigh* yeah
[07:43] <tsdgeos> it's old by nic d'offay and we don't even have FilterGrid.qml anymore
[07:43] <Saviq> tsdgeos, kk
[07:44] <tsdgeos> so it's not that's its of much interest to keep around
[07:46] <MacSlow> Saviq, fixed it
[08:09] <tsdgeos> Saviq: comments on https://code.launchpad.net/~nick-dedekind/unity8/indicator-polishing/+merge/228700/comments/563749 ?
[08:10] <Saviq> tsdgeos, https://blueprints.launchpad.net/ubuntu-ui-toolkit/+spec/time-formatter
[08:10] <Saviq> ;)
[08:10] <Saviq> Registered by Michał Sawicz on 2013-12-10
[08:10] <tsdgeos> sure
[08:10] <tsdgeos> but meanwhile
[08:11] <tsdgeos> do we want to use dgettext with indicator domain to save us the trouble of carrying different translations
[08:11] <tsdgeos> and risk them breaking if indicator changes
[08:13] <Saviq> tsdgeos, yeah, just commented
[08:13] <Saviq> @unity, change of plans for landing priorities: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-016
[08:14] <mzanetti> ?
[08:14] <Saviq> please if one of those branches is yours in review (or yours in the first place), drive it to a close
[08:15]  * Saviq finds it difficult to not see inline comments in *current* diff in LP
[08:16] <MacSlow> Saviq, mzanetti: Here's the fix... AP- and qml-tests pass locally... https://code.launchpad.net/~macslow/unity8/qmltest-tweak-for-1354406-workaround/+merge/231687
[08:17] <tsdgeos> marcustomlinson: ping
[08:17] <mzanetti> MacSlow: interesting.... did you try if only removing line 40 in this second diff would be enough to work around the issue?
[08:17] <mzanetti> I could imagine that this layer.enabled stuff is the thing that makes it slow
[08:19] <Saviq> MacSlow, why comboButton.text = comboRepeater.count >= 3 ? comboRepeater.itemAt(2).actionLabel : "" ?
[08:20] <Saviq> mzanetti, in theory layer is only enabled during transitions (to make the fade nicer), but I imagine this could have an impact indeed
[08:21] <mzanetti> Saviq: reading the the "fix" I had a hard time to see how it could be related tbh
[08:21] <mzanetti> Saviq: now that I see that it implcitly disables that layering I kinda get a feeling about it
[08:22] <mzanetti> Saviq: I think what happens is that it stacks multiple of those layer.enabled = true on top of each other, animating each's opacity
[08:22] <mzanetti> which then makes the hardware suffer too much
[08:22] <mzanetti> so all the workaround does is to disable that transition
[08:23] <Saviq> mzanetti, but it's not about it getting slow
[08:23] <mzanetti> its not?
[08:24] <Saviq> mzanetti, it's about it getting stuck completely
[08:24] <Saviq> mzanetti, and why would a layer be so hardware intensive, it only renders once and then animates opacity on a single texture (instead of all the children)
[08:25] <mzanetti> dunno... but why would a NumberAnimation on opacity lock up the device
[08:25] <mzanetti> the layer.enabled is the closest thing I could think of...
[08:27] <MacSlow> mzanetti, it speeds it up... at least it seemed to speed up the qmltest-run
[08:27] <MacSlow> Saviq, avoids QWARNs
[08:27] <Saviq> mzanetti, it doesn't *lock up* the device
[08:27] <Saviq> mzanetti, it confuses the modal overlay
[08:28] <Saviq> mzanetti, so device works just fine, you can even still dismiss the invisible notification if you know when to tap, and all goes back to normal
[08:28] <Saviq> s/when/where/
[08:29] <MacSlow> mzanetti, Saviq: what happens is that the opacity-animation gets stuck at value 0... everything else just runs fine
[08:29] <mzanetti> ḿhm
[08:29] <MacSlow> mzanetti, Saviq: e.g. one can still interact with the invisible snap-decision and tap the button to proceed
[08:29] <Saviq> ḿ?
[08:29] <mzanetti> typo
[08:30] <Saviq> looks like a missing glyph in Ubuntu mono, too
[08:30] <MacSlow> mzanetti, typo?! with dead-keys :)
[08:30] <mzanetti> MacSlow: hah... you have no idea what typos I'm capable of
[08:30] <MacSlow> mzanetti, :)
[08:31] <mzanetti> actually I scratched my screen above that ḿ before, thinking it would be dirt
[08:31] <mzanetti> didn't know this was possible
[08:35] <Saviq> hehe
[08:51] <MacSlow> tsdgeos, I'll now look into making lp:~macslow/unity8/fix-1348092 merge and pass ... again :)
[08:58] <Cimi> Saviq, scope settings and overlay padding review :)
[08:59] <Saviq> Cimi, and why is it me that has to do them? :P
[08:59] <Saviq> Cimi, settings I'll do
[08:59] <Cimi> Saviq, because a bird one day told me to push people to get reviews :)
[08:59] <Saviq> overlay padding - wonder if we need a test in testCard
[08:59] <Saviq> Cimi, *people*, not *Saviq*
[09:00] <Saviq> Cimi, we've broken the margins so many times now I'd like to have those autotested please
[09:00] <Cimi> Saviq, in a separate branch
[09:00] <Saviq> mzanetti, ah btw, if you have concerns about the lockscreen design, please do screenshots and ask kemmko to have a look
[09:00] <Saviq> mzanetti, before and after that iss
[09:00] <Saviq> -s
[09:01] <dednick> tsdgeos: ack on the datetime not updating. not same bug as my branch fixes, but looking into if it's a unity8 issue.
[09:01] <tsdgeos> Saviq: what does https://code.launchpad.net/~pitti/unity8/use-langpack/+merge/231390 actually do/mean
[09:01] <tsdgeos> ?
[09:01] <Saviq> tsdgeos, see description
[09:02] <Saviq> tsdgeos, https://lists.launchpad.net/ubuntu-phone/msg08566.html
[09:02] <tsdgeos> Saviq: so we'll lose all the .po from the repo?
[09:02] <Saviq> tsdgeos, no
[09:03] <tsdgeos> ok
[09:03] <Saviq> tsdgeos, that basically means .mo are shipped separately, meaning a) can be installed per-language, not per-package; b) can be updated as translations in launchpad are updated
[09:03] <Saviq> without upstream release
[09:03] <tsdgeos> ok
[09:03] <Saviq> tsdgeos, we will lose .mo from  the binary packages
[09:08] <Cimi> Saviq, but how do we do a test in testCard when the containers and items are dinamically generated?
[09:09] <Saviq> Cimi, testCard uses cardcreator
[09:09] <Cimi> Saviq, yes
[09:10] <Saviq> greyback, hey man, so... seems like Daniel's lifecycle got in before surface sizing, how about we rebase and land them together?
[09:10] <Cimi> Saviq, ah I see how we can do it
[09:11] <greyback> Saviq: ok
[09:11] <Cimi> Saviq, using calculation of x and width of title item and noticing the position of it compared to the right edge of the bigger container
[09:18] <Saviq> Cimi, bingo!
[09:18] <Saviq> exclamation mark
[09:23] <tsdgeos> Saviq: http://paste.ubuntu.com/8104832/ quick MR to add i18n.tr to the ones in /qml/Panel/Indicators ?
[09:23] <Saviq> tsdgeos, dev tools, we don't want to translate those
[09:24] <tsdgeos> ah damn
[09:24] <Saviq> tsdgeos, Clear and Empty I think are gone already
[09:24] <tsdgeos> i always forgot client is a dev tool
[09:24] <Saviq> dednick, ↑?
[09:24] <tsdgeos> Saviq: they'll be gone with https://code.launchpad.net/~nick-dedekind/unity8/indicator-polishing/+merge/228700
[09:24] <Saviq> yeah
[09:24] <tsdgeos> which is still in progress
[09:24] <tsdgeos> but o
[09:24] <tsdgeos> k
[09:26] <dednick> Saviq: ?
[09:26] <dednick> yes, will be gone.
[09:27] <dednick> if that's what you're asking
[09:27] <tsdgeos> yes
[09:34] <tsdgeos> mzanetti: https://code.launchpad.net/~mzanetti/unity8/new-lockscreen-design/+merge/230478/comments/563781
[09:34] <mzanetti> tsdgeos: shouldn't that happen automatically?
[09:35]  * mzanetti doesn't even know how to do that
[09:35] <tsdgeos> mzanetti: it should in the ideal world
[09:35] <tsdgeos> we live in the sad world
[09:35] <tsdgeos> mzanetti: make knows
[09:35] <tsdgeos> actually no, not make
[09:36] <tsdgeos> yes make too
[09:36] <tsdgeos> either make unity8.pot or just run po/update-unity-pot
[09:36] <mzanetti> well, just running "make" doesn't
[09:36] <Saviq> make pot_file
[09:36] <tsdgeos> ah that
[09:36] <tsdgeos> the cmake file is confusing
[09:36] <mzanetti> tsdgeos: pushed
[09:36] <mzanetti> tsdgeos: that's cause its cmake :)
[09:37] <tsdgeos> least confusing of the buildsystems if you ask me
[09:37] <Saviq> mzanetti, tsdgeos, it *could* happen automagically, but if it happens automagically on each MP then we'll be flooded with pot-only changes
[09:37] <tsdgeos> Saviq: and noone will care
[09:37] <mzanetti> Saviq: don't we have like daily launchpad translations commits anyways?
[09:37] <Saviq> if it happens on package build, then it doesn't end up in our trunk
[09:37] <Saviq> mzanetti, translations, not templates
[09:37] <Saviq> mzanetti, LP doesn't know how to extract the strings
[09:38] <Saviq> if it doesn't end up in our trunk, it doesn't end up on translations.lp.com
[09:38] <Saviq> so useless
[09:38] <tsdgeos> which is sad given how i maintain something created more than 10 years ago that does already that :D
[09:38] <tsdgeos> but that's a different story
[09:38] <Saviq> tsdgeos, well, we just lack convention, completely agree
[09:39] <Saviq> tsdgeos, slight problem is, some projects might require additional deps to generate the templates
[09:39] <tsdgeos> Saviq: if i can get volunteers to agree on convention, i'm pretty sure we can get paid developers to agree on them ;)
[09:39] <Saviq> tsdgeos, so it's not just a case of "aaah, execute that script"
[09:39] <tsdgeos> it really is
[09:39] <tsdgeos> you just need to have the available deps on the server
[09:40] <Saviq> tsdgeos, except you don't have the right to install them on the machine that executes it
[09:40] <Saviq> tsdgeos, anyway, I do have an idea that will work, just need to flesh it out with the train folks
[09:40] <tsdgeos> sure
[09:41] <Saviq> tsdgeos, as I believe this should happen in train, just after merging all the MPs
[09:41] <tsdgeos> i'm just saying this is far from an unsolvable problem
[09:41] <Saviq> tsdgeos, sure
[09:41] <Saviq> tsdgeos, ideally we'd have the same for qmltypes
[09:41] <Saviq> tsdgeos, although these, arguably, should come with the changes to plugins
[09:41] <tsdgeos> qmltypes should be just part of make
[09:41] <Saviq> tsdgeos, can't be
[09:42] <tsdgeos> why?
[09:42] <Saviq> tsdgeos, because requires all the *runtime* dependencies of a plugin
[09:42] <Saviq> and anyway IMO generated stuff != build-time generated
[09:43] <Saviq> not necessarily at least
[09:44] <tsdgeos> Saviq: honestly, if i am compiling somethign i may as well have the runtime dependencies
[09:44] <tsdgeos> otherwise i'll have a problem in 5 seconds after i try to run the thing i compiled
[09:44] <tsdgeos> unless i'm the build servers of course
[09:44] <Saviq> tsdgeos, if *you* are, maybe, if a build machine does, not so much
[09:44] <Saviq> tsdgeos, yes exactly
[09:44] <tsdgeos> well there's something called conditional building
[09:44] <Saviq> tsdgeos, we can make ./build.sh
[09:44] <Saviq> to do qmltypes too
[09:45] <Saviq> tsdgeos, but we can't put them in ALL
[09:45] <tsdgeos> we can
[09:45] <tsdgeos> cmake can do it if you have the dependencies
[09:45] <tsdgeos> but it's ok
[09:45] <Saviq> tsdgeos, but if they're checked into trunk anyway, it's a waste, and if there's only one that can't be built build-time, they need to be checked in
[09:45] <tsdgeos> it's not like i have any use for those qmltypes files :D
[09:46] <Saviq> you kinda do, assuming QtC can actually find them ;P
[09:46] <tsdgeos> the translations are a much more pressing issue
[09:46] <tsdgeos> Saviq: and assuming i use QtC ;)
[09:46] <Saviq> tsdgeos, WAH!?
[09:46] <Saviq> tsdgeos, yeah, I'll talk to landing guys today
[09:51] <mzanetti> Saviq: can we programmatically run scopes (from outside unity)
[09:51] <mzanetti> Saviq: like using a script or something to load a newly installed scope
[09:51] <mzanetti> and display it
[09:51] <Saviq> mzanetti, scope tool
[09:51] <Saviq> mzanetti, point at the .ini file
[09:52] <mzanetti> on the phone too?
[09:52] <Saviq> mzanetti, on phone just go to overview
[09:52] <mzanetti> Saviq: programmatically
[09:52] <Saviq> mzanetti, it'll be there
[09:52] <Saviq> mzanetti, what do you want to achieve? :)
[09:52] <mzanetti> Saviq: clicking play in QtC and showing the scope
[09:52] <mzanetti> so actually zbenjamin, not me
[09:53] <Saviq> mzanetti, we should add a url handler to unity8-dash
[09:53]  * zbenjamin reads backlog
[09:53] <mzanetti> Saviq: makes sense
[09:53] <Saviq> mzanetti, and when deploying the scope, he'd restart scope-registry and url-dispatch scope:///scopename
[09:53] <Saviq> zbenjamin, ↑
[09:54] <mzanetti> yep, sounds sane
[09:54] <Saviq> http://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.Components.UriHandler/
[09:54] <zbenjamin> Saviq: oook thanks, going to try that!
[09:55] <mzanetti> Saviq: doesn't say how to register it though
[09:55] <Saviq> mzanetti, https://wiki.ubuntu.com/URLDispatcher -ish
[09:55] <mzanetti> ah
[09:55] <mzanetti> better
[09:56] <mzanetti> zbenjamin: ok... so seems requires some change in unity8-dash, shouldn't be too hard, but needs to be done still
[09:56] <Saviq> mzanetti, http://bazaar.launchpad.net/~system-settings-touch/ubuntu-system-settings/trunk/view/head:/ubuntu-system-settings.url-dispatcher
[09:56] <mzanetti> right... got it
[09:56] <zbenjamin> mzanetti: ok so its not there yet, because the scopes team said its all in place (or does the scope start but not come up yet)
[09:56] <Saviq> installed into /usr/share/url-dispatcher
[09:56] <Saviq> zbenjamin, their side's there
[09:57] <Saviq> zbenjamin, ours isn't, but should be maybe 20 lines diff
[09:57] <mzanetti> yeah... and most of it { and }
[09:57] <mzanetti> still... tbd
[09:57] <zbenjamin> Saviq: ok and eta when i can get this?
[09:57] <zbenjamin> Saviq: we should have that before RTM
[09:57] <mzanetti> zbenjamin: you could try to add it yourself ;)
[09:57]  * zbenjamin hides
[09:58] <zbenjamin> mzanetti: ugh ;)
[09:58] <mzanetti> zbenjamin: well, its just adding that hook file to unity8 and then adding this: http://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.Components.UriHandler/ to Dash.qml
[09:59] <zbenjamin> mzanetti: ok, let me see
[10:02] <Saviq> tsdgeos, can you tell zbenjamin what he'd need to do with scope:/// uris from url dispatcher? Scopes.performQuery or something?
[10:03] <Wellark> mzanetti: thanks for reminding about the SIM unlock situation
[10:03] <tsdgeos> Saviq: not sure i understand question/context
[10:03] <Wellark> it's basically the same thing I talked about introducing the dual sim support.
[10:03] <tsdgeos> i mean, yes, i'm sure i don't understand  it :D
[10:03] <Wellark> to the backend
[10:03] <Wellark> that will fix it also
[10:03] <Saviq> tsdgeos, we'll get a scope:/// url from url-dispatcher
[10:03] <Saviq> tsdgeos, what do we need to do with it so that Scopes gives up openScope or gotoScope?
[10:03] <Wellark> mzanetti: care to do the review tomorrow?
[10:04] <mzanetti> Wellark: sure
[10:04] <tsdgeos> Saviq: good question
[10:04] <tsdgeos> let me see
[10:04] <Wellark> mzanetti: thanks!
[10:04] <Saviq> tsdgeos, I'm slightly worried it's Scope::performQuery
[10:04] <tsdgeos> i am not sure
[10:04] <tsdgeos> it was for a brief moment
[10:04] <Saviq> tsdgeos, so we'd need to grab the first scope and call that (yuck)
[10:04] <Saviq> tsdgeos, it's whatever the header links do
[10:04] <tsdgeos> but then mhr3 changed it i think
[10:05] <Saviq> tsdgeos, nah, it's still Scope::performQuery
[10:05] <tsdgeos> actualy yes
[10:05] <Saviq> GSV.qml:409
[10:05] <tsdgeos> you're right
[10:05] <tsdgeos> it's only 2 / and not 3 it seems though
[10:05] <tsdgeos> ./qml/Dash/ScopesOverview.qml:450:                    scope.performQuery("scope://com.canonical.scopes.clickstore");
[10:05] <Saviq> yeah that's fine
[10:05] <zbenjamin> mzanetti: i just wonder where to add the hook, does unity come with its own manifest file?
[10:05] <tsdgeos> or maybe both work
[10:06] <Saviq> tsdgeos, no
[10:06] <Saviq> tsdgeos, scope name is the hostname part in there
[10:06] <Saviq> tsdgeos, but that's fine, only problem I'm seeing is that it's on Scope:: and not Scopes::
[10:06] <MacSlow> Saviq, mzanetti: it passed on jenkins... https://code.launchpad.net/~macslow/unity8/qmltest-tweak-for-1354406-workaround/+merge/231687
[10:06] <tsdgeos> yes
[10:06] <tsdgeos> taht's by design
[10:07] <tsdgeos> as openScope is also in scope
[10:07] <tsdgeos> not in scopes
[10:07] <Saviq> tsdgeos, well, yeah, broken design IMO :P
[10:07] <tsdgeos> a design i don't really agree much with tbh
[10:07] <tsdgeos> but it's the design
[10:07] <Saviq> ok so we need to grab the current scope and performQuery() on that
[10:07] <Saviq> tsdgeos, well, reason kinda is that we open the temp scope inside GSV
[10:08] <Saviq> tsdgeos, when we go for a stack, I think we'll be able to move up to Scopes
[10:08] <tsdgeos> let's see
[10:09] <Saviq> so /me thinking DashContent.qml: UriHandler { onOpened: currentItem.scope.performQuery(uris[0]) }
[10:09] <Saviq> pseudo-code
[10:10] <Saviq> zbenjamin, ↑ something like this, unless tsdgeos vetoes
[10:10] <tsdgeos> yeah makes sense
[10:10] <zbenjamin> Saviq: ok
[10:12] <larsu> seb128: your warning comes from the fact that qt tries to load the icon with a size of (32,0) first
[10:12] <larsu> then, when it doesn't find it, it runs the same query again with 32,32
[10:15] <larsu> ah, QSize::isValid() returns true for sizes that are 0 in one dimension, but QIcon::pixmap() from such a size returns an invalid pixmap
[10:15] <zbenjamin> Saviq: where do i need to put the hook/url dispatcher file ?
[10:16] <Saviq> zbenjamin, /usr/share/url-dispatcher
[10:16] <zbenjamin> Saviq: i don't see a manifest file or any other files like this in the unity8 tree
[10:16] <Saviq> zbenjamin, see how ubuntu-system-settings does it
[10:16] <Saviq> zbenjamin, not sure if there's a post-inst required, url-dispatcher should pick them up automagically I'd say
[10:17] <zbenjamin> Saviq: ok
[10:17] <Saviq> zbenjamin, yeah, just install it into /usr/share/url-dispatcher
[10:17] <Saviq> zbenjamin, with schema: "scope"
[10:18] <zbenjamin> Saviq: ok so i put the file there, probably unity.url-dispatcher and then just register with the QML component to the URL?
[10:19] <seb128> larsu, 0? weird...
[10:19] <seb128> larsu, is the custom component buggy for doing a call with 0?
[10:19] <Saviq> zbenjamin, unity8-dash.url-dispatcher please, and yeah, the above in DashContent.qml
[10:19] <larsu> seb128: ya... "If requestedSize is a valid size, the image returned should be of that size."
[10:19] <zbenjamin> Saviq: ah now i see the APP_ID is used as selector
[10:19] <larsu> seb128: no, qt does this even when I explicitely set sourceWidth and Height
[10:20] <Saviq> zbenjamin, right
[10:20] <seb128> larsu, that seems buggy...
[10:20] <Saviq> larsu, seb128, that's why Icon has a workaround
[10:20] <Saviq> that it only sets source *after* both sourceSize.width and .height are > 0
[10:20] <zbenjamin> Saviq: thx
[10:20] <mzanetti> zbenjamin: sorry... just saw you message now (doing operator tests atm)
[10:20] <zbenjamin> mzanetti: np Saviq helped me to figure it out
[10:21] <larsu> Saviq: what do you mean by after? Does property ordering matter? Or in onComponentComplete?
[10:21] <Saviq> larsu, it just goes source: width > 0 && height > 0 ? blah : ""
[10:21] <larsu> Saviq: that's ... annoying
[10:21] <Saviq> larsu, it is, that's declarative for you
[10:22] <Saviq> larsu, fwiw, sourcesize 0 is valid
[10:22] <Saviq> larsu, just not for an icon from a theme :|
[10:22] <larsu> right
[10:22] <larsu> I wonder if I should just use width=height?
[10:23] <larsu> I'd do that in StatusIcon anyway...
[10:23] <Saviq> larsu, that's still a binding
[10:23] <larsu> Saviq: I mean in the image provider
[10:23] <Saviq> larsu, no, StatusIcon supports non-square icons
[10:23] <Saviq> it's its whole purpose, really
[10:23] <Saviq> larsu, but yeah, in the theme image provider
[10:23] <Saviq> larsu, it makes sense to just go =
[10:23] <Saviq> larsu, there's a but, though
[10:23] <larsu> Saviq: it doesn't load my icon when I don't set sourceWidth
[10:24] <Saviq> larsu, that will still call the provider twice...
[10:24] <Saviq> larsu, StatusIcon??
[10:24] <larsu> I might have patched it ... a bit
[10:24] <Saviq> larsu, works in indicators...
[10:24] <Saviq> and elsewhere in the shell?
[10:24]  * larsu wonders why this is so complicated
[10:26] <larsu> Saviq: I've simply removed the custom theme lookup in StatusIcon and I can't find where it used to set the width...
[10:27] <Saviq> larsu, because icon themes do not support non-square icons...
[10:27] <Saviq> larsu, it didn't
[10:27] <larsu> ah, it loads the image directly
[10:27]  * larsu gets it now, thanks
[10:27] <Saviq> larsu, yes
[10:27] <Saviq> larsu, it's a stupid/nasty hack, but it works ;P
[10:27] <larsu> ya... :/
[10:28] <Saviq> larsu, need to come up with how we start supporting non-square assets in the theme
[10:28] <larsu> does the fdo spec care about that?
[10:28] <larsu> or is it just qt not handling this right?
[10:28] <Saviq> larsu, no, the theme only has "size"
[10:29] <Saviq> larsu, the theme definition I mean
[10:29] <larsu> right
[10:29] <Saviq> larsu, so (without reading the spec, though) it seems like it only supports squares
[10:29] <tsdgeos> yep
[10:29] <larsu> ya, makes sense
[10:29] <tsdgeos> spec assumes squares everywhere
[10:30] <tsdgeos> why would anyone want non square icons... :D
[10:30] <Saviq> tsdgeos, you know who to talk to?
[10:30] <Saviq> I can tell you ;)
[10:30] <tsdgeos> i'm not an expert in the field
[10:30] <tsdgeos> my opinion is the one of a simple user
[10:31] <Saviq> tsdgeos, sil2100, bug #1359667
[10:32] <tsdgeos> Saviq: looks sane
[10:32] <Saviq> tsdgeos, confirm please
[10:33] <sil2100> Saviq: thanks :)
[10:35] <larsu> Saviq: does requesting an image with a width of 0 usually mean "preserve aspect"? I might just implement that in the icon theme provider then
[10:47] <Saviq> larsu, yes
[10:47] <Saviq> larsu, there's a few intricacies, see http://qt-project.org/doc/qt-5/qml-qtquick-image.html#sourceSize-prop
[10:47] <Saviq> larsu, the problem is though how do you select an image from the theme
[10:48] <Saviq> larsu, you'd have to assume "size" to be either height or width
[10:48] <Saviq> FWIW in our use cases it's always height AFAICT
[10:49] <larsu> k, thanks
[11:01] <Saviq> greyback, didn't reply to my other inline comments on purpose or missed them?
[11:02] <greyback> Saviq: sorry I find inline comments easy to miss
[11:03] <greyback> ok found 'em
[11:04] <Saviq> greyback, yeah, ctrl+F $reviewer is what I do, totally agree though
[11:10] <greyback> Saviq: "Fire. Exclamation mark." we don't like expressing surprise/astonishment?
[11:11] <Saviq> greyback, j/k, there was a significant count of exclamation marks in your MP is all ;)
[11:12]  * greyback going to start putting emoticons in his code now
[11:13] <Saviq> ☺
[11:14] <Saviq> /food
[11:15] <zbenjamin> Saviq: is there any way i can see unity output on the phone?
[11:16] <zbenjamin> Saviq: i mean stdout/stderr
[11:16] <zbenjamin> mzanetti: ^
[11:17] <mzanetti> zbenjamin: ./cache/upstart/unity8.loh
[11:17] <mzanetti> log
[11:17] <zbenjamin> mzanetti: in phablet home?
[11:17] <mzanetti> yes
[11:22] <zbenjamin> mzanetti: ok, how is there url-dispatcher command called?
[11:22] <zbenjamin> or is it located not in the path?
[11:23] <Cimi> Saviq, tests added https://code.launchpad.net/~cimi/unity8/overlay-right-padding/+merge/231586
[11:24] <mzanetti> zbenjamin: hmm... that's called when you do Qt.openUrlExternally() in qml, or with QDesktopService::openUrl() or similar
[11:24] <mzanetti> zbenjamin: how to do that in python, I have no clue
[11:24] <zbenjamin> mzanetti: ook there is /usr/lib/arm-linux-gnueabihf/url-dispatcher/url-dispatcher
[11:25] <mzanetti> yeah... I guess you can invoke that with a aparam too
[11:25] <mzanetti> haven't ever done it myself though
[11:25] <zbenjamin> mzanetti: not working
[11:26] <mzanetti> Saviq: do you know=
[11:26] <mzanetti> ?
[11:26] <zbenjamin> ** (process:11117): ERROR **: Unable to connect to D-Bus: Could not connect: Connection refused
[11:26] <mzanetti> zbenjamin: you are trying that in a user session, right?
[11:26] <mzanetti> not with adb shell as root or similar
[11:26] <tsdgeos> pstolowski: https://code.launchpad.net/~aacid/unity8/expandable_model_not_array/+merge/231708
[11:26] <zbenjamin> mzanetti: yes
[11:27] <tsdgeos> Saviq: is there any chance we can get https://code.launchpad.net/~aacid/unity8/expandable_model_not_array/+merge/231708 in in next mega-merge? i did a mistake in the test of expandable that means the code is also wrong
[11:28] <zbenjamin> mzanetti: ** (process:11361): WARNING **: Unable to get name 'com.canonical.URLDispatcher'  thats what i get now
[11:29] <tsdgeos> zbenjamin: you already have one running?
[11:29] <mzanetti> ah
[11:29] <mzanetti> tsdgeos: what he tries is to invoke some url from command line
[11:29] <mzanetti> do you know how that works?
[11:29] <tsdgeos> nope sorry :/
[11:29] <mzanetti> tedg: is that even possible?
[11:29] <zbenjamin> tsdgeos: from python would be fine as well
[11:30] <Cimi> tsdgeos, I can review that
[11:30] <tsdgeos> Cimi: please
[11:30] <mzanetti> tedg: we're trying to invoke some url from *not* Qt :) cli or python ideally
[11:31] <tsdgeos> Saviq: there's also the question if we want to show the [+]/[-] button if there's only less than "collapsible-widgets" and they are all very small (i.e. the [+][-] does nothing) or we just let the scope author use the stuff correctly
[11:31] <zbenjamin> mzanetti: actually i would prefer python ;)
[11:31] <mzanetti> zbenjamin: I guess a dbus call would do then...
[11:32] <tsdgeos> mzanetti: why not from Qt?
[11:32] <tsdgeos> i mean all the Qt part does is
[11:32] <tsdgeos> http://paste.ubuntu.com/8105544/
[11:32] <mzanetti> tsdgeos: 'cause we'd need to build a binary just for this
[11:32] <tsdgeos> which i imagine would be the same a command line or python thing would do
[11:33] <mzanetti> ok... not from c/c++
[11:33] <mzanetti> and not from qml
[11:33] <Cimi> tsdgeos, doc for it?
[11:33] <tsdgeos> Cimi: doc?
[11:33] <Cimi> tsdgeos, where is it stated that is not an array?
[11:33] <tsdgeos> we don't use arrays
[11:33] <Cimi> tsdgeos, just to double check we are doing the right thing
[11:33] <facundobatista> Morning!
[11:33] <tsdgeos> we use models
[11:33] <Cimi> tsdgeos, and was not a bug in model
[11:33] <Cimi> s/model/backend
[11:34] <tsdgeos> Cimi: such thing does not exist
[11:34] <facundobatista> Do you know how to take a screenshot from the phone?
[11:34] <pstolowski> tsdgeos, thanks
[11:34] <tsdgeos> facundobatista: there's a command line app
[11:34] <zbenjamin> tsdgeos: its for the SDK launcher to support running scopes from QtCreator, we have a python based script for launching apps, now we need the same for scopes
[11:34] <zbenjamin> tsdgeos: thats why python
[11:34] <tsdgeos> facundobatista: in the pc
[11:34] <facundobatista> tsdgeos, I tried "phablet-screenshot foo.png" but doesn't work
[11:34] <tsdgeos> facundobatista: on the pc?
[11:34] <facundobatista> yeap
[11:35] <Cimi> tsdgeos, https://docs.google.com/a/canonical.com/document/d/1NmiM4UCnJgf6IEawmfyTOHRNAA5ZGrqpyrPqPOibwc8/edit#heading=h.i0usbmllncqr
[11:35] <tsdgeos> facundobatista: used to work
[11:35] <tsdgeos> Cimi: yes that is all we have
[11:35] <tsdgeos> Cimi: doesn't say it's a model, but it's the same structure as "previews":   "widgets":
[11:35] <tsdgeos> and "previews":   "widgets": is a model
[11:35] <facundobatista> tsdgeos, http://linkode.org/Aew2csBJKyWB7AbIJh4Qw1  maybe I'm missing a package?
[11:35] <tsdgeos> so ours should be too
[11:36] <Cimi> tsdgeos, ok
[11:36] <tsdgeos> facundobatista: thsi is whati get http://paste.ubuntu.com/8105576/
[11:36] <Cimi> tsdgeos, makes sense
[11:36] <tsdgeos> facundobatista: mayeb
[11:40] <Cimi> tsdgeos, where can I find a previewExpandable to test?
[11:40] <tsdgeos> Cimi: besides the testcase?
[11:40] <Cimi> tsdgeos, yes
[11:40] <tsdgeos> you need to compile "lots of stuff
[11:40] <Cimi> real one
[11:40] <tsdgeos> "
[11:40] <tsdgeos> pstolowski: ↑↑↑↑
[11:40] <tsdgeos> well, let me just copy
[11:40] <Cimi> oh arg
[11:40] <Cimi> tsdgeos, let's wait a silo then
[11:40] <tsdgeos> lp:~stolowski/unity-scopes-api/expandable-widget
[11:40] <tsdgeos> lp:~stolowski/unity-scopes-shell/expandable-widget
[11:40] <tsdgeos> then run scope-A from demo/scope-A subdirectory of scopes-api with unity-scope-tool
[11:41] <tsdgeos> ...
[11:41] <Cimi> tsdgeos, approved
[11:41] <Cimi> tsdgeos, we should get all in a silo and test
[11:42] <tsdgeos> or you can compile it
[11:42] <tsdgeos> it takes 15 min
[11:42] <pstolowski> Cimi, it's still WIP on my side, but yeah, should work already
[11:43] <zbenjamin> mzanetti: seems dbus call it is, hopefully the interface won't change between images :/
[11:43] <mzanetti> zbenjamin: unlikely
[11:45] <karni> Have you guys seen this problem where after you kill an app (swipe away), you try to launch it again, it looks like it's starting, and then it just disappears? I could share unity8.log if someone's interested or have seen a similar problem.
[11:46] <karni> if I use ubuntu-app-launch directly from adb shell, the app launches properly
[11:46] <karni> but not from the dash, after I swipe it away
[11:46] <karni> mhall119: ↑
[11:50] <karni> facundobatista: phablet-screenshot is in phablet-tools package
[11:51] <facundobatista> karni, yes, but I'm getting http://linkode.org/Aew2csBJKyWB7AbIJh4Qw1
[11:51] <facundobatista> karni, I'm currently upgrading the tablet to see if that fixes it
[11:51] <karni> facundobatista: right. sorry, I've no idea what causes that problem.
[12:00] <Saviq> zbenjamin, you want unity8-dash, not unity8.log
[12:00] <Saviq> tsdgeos, sure
[12:01] <Saviq> zbenjamin, mzanetti `url-dispatcher scope://scopename` is all you need
[12:01] <Saviq> url-dispatcher might be in url-dispatcher-tools though, not on the phone by default
[12:01] <mzanetti> Saviq: well, there is sone url-dispatcher binary
[12:02] <Saviq> mzanetti, that's the service
[12:02] <Saviq> unfortunately named the same
[12:02] <Saviq> hence the "can't get name"
[12:02] <mzanetti> and no matter how you call it, it just prints a dbus-message and that's it
[12:02] <Saviq> but it's not on $PATH for a reason
[12:02] <Saviq> mzanetti, that's the service
[12:02] <Saviq> mzanetti, it's already running
[12:02] <mzanetti> might be useful to say so :)
[12:02] <Saviq> mzanetti, you need the other end of that
[12:02] <mzanetti> yeah, I understand.
[12:02] <Saviq> mzanetti, it's not like you're supposed to look in /usr/lib for executables ;)
[12:03] <mzanetti> Saviq: well... that's what I thought too until recently
[12:03] <mzanetti> but seems that happens a lot around here :)
[12:04] <Saviq> mzanetti, like where?
[12:04] <Saviq> anyway, /me back to food still
[12:10] <Cimi> mzanetti, if you want, I can do this https://bugs.launchpad.net/unity8/+bug/1359157
[12:12] <mzanetti> Cimi:  I have the assets here already... will fix it
[12:12] <Cimi> mzanetti, cool
[12:36] <mlankhorst> hey does anyone here remember what package failed with the llvm 3.5 changes? I want to retest manually before uploading next mesa built against 3.5-rc3
[12:40] <mlankhorst> my previous testcase no longer appears to work (online-account-ui)
[12:42] <zbenjamin> Saviq: can we then include the url-dispatcher-tools? the idea is that the developer should never have to enable his image to be writeable
[12:44] <Saviq> zbenjamin, it's probably best that you just invoke dbus-send, url-dispatcher-tools isn't meant to be there in the images AFAIK, we'll have to talk to tedg about this
[12:44] <zbenjamin> Saviq: ok
[12:45] <zbenjamin> Saviq: i added this to DashContent.qml     Connections {    target: UriHandler      onOpened: dashContentList.currentItem.scope.performQuery(uris[0])    }
[12:45] <zbenjamin> Saviq: after invoking the url the Dash crashed i guess
[12:46] <zbenjamin> Saviq: its gone now
[12:48] <Saviq> zbenjamin, should've respawned
[12:48] <tsdgeos> mterry: https://code.launchpad.net/~mterry/unity8/notify-authenticated/+merge/231022/comments/563880
[12:48] <zbenjamin> Saviq: nope, just black
[12:48] <Saviq> zbenjamin, and is there a .crash file for unity8-dash in /var/crash ?
[12:49] <Saviq> zbenjamin, if you have a branch, please push/MP it and we'll have a look
[12:49] <zbenjamin> _usr_bin_unity8-dash.32011.crash
[12:49] <zbenjamin> Saviq: i have no branch yet , i hacked the files on the phone ;)
[12:50] <Saviq> zbenjamin, you made it crash, now's a good time to make a branch then ;)
[12:50] <zbenjamin> Saviq: pfffft ;)
[12:51] <mterry> tsdgeos, replied
[12:51] <tsdgeos> mterry: would that test have catched this bug?
[12:52] <Saviq> greyback, you need to resubmit with lifecycle as a prerequisite
[12:53] <pstolowski> Saviq, hey, can we land this https://code.launchpad.net/~stolowski/unity-scopes-shell/favorite-scopes/+merge/230824 ?
[12:53] <mterry> tsdgeos, hrm maybe not, because that new test is in the WithPin test.  Alright, you got me.  :)  I'll add a brief test in this branch
[12:53] <tsdgeos> mterry: ;)
[12:54] <tsdgeos> mterry: only if it's not a lot of work
[12:54] <Saviq> pstolowski, sure, ACKed
[12:54] <Saviq> pstolowski, if you want, you can land, otherwise I'll land when unity8 adapts
[12:54] <mterry> tsdgeos, I think I'll just add a tiny test to confirm that various properties are correct, nothing complicated
[12:56] <greyback> Saviq: the qtmir branch? They merge cleanly already, so it prereq really needed?
[12:57] <Saviq> greyback, for completeness, and then you'd add your entry to the changelog
[12:57] <greyback> Saviq: completeness, ok. Isn't changelog added by train though?
[12:57] <Saviq> greyback, not if it's being touched
[12:58] <greyback> Saviq: ok
[12:59] <mterry> tsdgeos, done
[13:00] <tsdgeos> mterry: oki, another very small thing at https://code.launchpad.net/~mterry/unity8/no-lock-during-call/+merge/227996
[13:01] <mterry> tsdgeos, I just updated the qmltypes now
[13:04] <mterry> tsdgeos, awesome thanks!
[13:05] <tsdgeos> anyone else is missing a review?
[13:05] <tsdgeos> from a quick look at them seems most of them are already picked by someoene
[13:08] <pstolowski> Saviq, thanks. it's ok to land with unity8
[13:08] <pstolowski> thostr_, ^
[13:09] <thostr_> pstolowski: ack, thanks
[13:11] <kgunn> Saviq: sorry i didn't land anything other than the workarounds, would it help if i worked on landing what's approved while you do "other stuff"
[13:12] <kgunn> e.g. silo16
[13:14] <zbenjamin> Saviq: lp:~zeller-benjamin/unity8/scope-url
[13:14] <Saviq> kgunn, there's some review / tweaking work needed in silo 16 still
[13:14] <Saviq> kgunn, which is what I'm after now
[13:15] <Saviq> kgunn, it's fine (re landing fixes), only our ci is red again because of that ;P
[13:19] <greyback> Saviq: ok my 3 branches rebased on top of dandrader's
[13:19] <greyback> waiting for him to update changelogs whenever he appears
[13:21] <Saviq> greyback, whyy? you just add an entry in yours instead?
[13:21] <Saviq> greyback, just in your branches, now that you merged his
[13:21] <greyback> Saviq: completeness? :)
[13:21] <Saviq> greyback, go `dch "initial surface sizes"` or so
[13:22] <Saviq> greyback, but his branches shouldn't be changed just because yours ar based on his?
[13:28] <mzanetti> Saviq: :) is my device now going to flash whenever I press the volume down button?
[13:28] <greyback> Saviq: changelog on qtmir pushed
[13:28] <kgunn> Saviq: what's red on ci ?
[13:29] <kgunn> unity8 or something else ?
[13:29] <Saviq> kgunn, MacSlow's workaround broke notification sounds
[13:29] <Saviq> kgunn, for which there's a test that now fails
[13:30] <Saviq> mzanetti, read my review
[13:30] <mzanetti> Saviq: yeah, didn't really get that comment :)
[13:33] <MacSlow> kgunn, Saviq: well I've fixes in MPs up to sort out all issues which came up
[13:34] <Saviq> MacSlow, sure, I'm just complaining to kgunn that he was sloppy :P
[13:34] <Saviq> but maybe the situation required some of it ;)
[13:34] <MacSlow> hehe
[13:34] <kgunn> it did remove the pressure
[13:34] <MacSlow> kgunn, Saviq: I got everybody's back covered still :)
[13:35] <Saviq> kgunn, yeah, I know, which is why I didn't mention it yesterday and let it all through, but want to fix it again asap
[13:35] <Saviq> greyback, waait
[13:36] <Saviq> greyback, you don't need a changelog entry for *qtmir*
[13:36] <MacSlow> kgunn, Saviq: although no progress yet on the real issue of the opacity-animation getting stuck... but I'd rather see the workound-fix and MPs for LP: #1348092 land
[13:36] <Saviq> greyback, only for unity-api
[13:36] <Saviq> greyback, deps between qtmir and unity8 are handled by the -impl-foo virtuals
[13:36] <Saviq> greyback, that is, unless you wanted a qtmir 0.4.2 anyway
[13:37] <greyback> Saviq: I did
[13:38] <Saviq> greyback, but yeah, no need for Daniel's entry there
[13:38] <Saviq> greyback, let me clarify one thing
[13:38] <Saviq> with sil
[13:39] <Saviq> sil2100, two MPs, second (in order of merging) of them touches changelog, the other does not, will the first one's commit message be appended to the changelog anyway?
[13:40] <sil2100> Saviq: hmm, I would expect it to, yes, but let me dive into the code and make sure it does
[13:40] <Saviq> sil2100, nw, we'll find out soon enough :)
[13:41] <Saviq> greyback, so yeah, sorry, I miscommunicated, for a *particular MP* changelog isn't used if it's touched
[13:41] <Saviq> greyback, so please drop Daniel's entry from your MP
[13:41] <Saviq> grr
[13:41] <sil2100> If it doesn't, it's a bug ;) But this part of CI Train code is a bit specifically written, so it's always hard to easily check and modify
[13:42] <Saviq> s/isn't used/is used/
[13:42] <Saviq> greyback, as long as Daniel's branch doesn't touch changelog, his commit msg will be added to your v0.4.2
[13:42] <greyback> Saviq: ok
[13:47] <greyback> Saviq: ok, for unity-api, daniel adds custom changelog, so my branch on top does not touch changelog
[13:47] <greyback> for qtmir, Daniel does not touch changelog. My branch on top does however, bumping version number
[13:48] <greyback> I was updating u8, forgot where I am with that, but will get it in shape
[13:52] <Saviq> greyback, yeah, thanks
[13:58] <zbenjamin> Saviq: did you see my branch? or who is the right person to look at it?
[14:16] <tsdgeos> mzanetti: is https://code.launchpad.net/~mzanetti/unity8/smaller-dropshadow-asset/+merge/231729 really dependant on your prerequisite?
[14:16] <tsdgeos> or you're just chaining it for easy merging
[14:16] <tsdgeos> ?
[14:16] <mzanetti> tsdgeos: easy merging
[14:16] <mzanetti> tsdgeos: it'll conflict otherwise
[14:31] <Cimi> dednick, standup
[14:40] <Saviq> mterry, hey, lp:~mterry/unity8/sim-unlock-on-boot conflicts with lp:~mterry/unity8/sim-unlock-on-boot could you please chain them?
[14:41] <mterry> Saviq, try again?
[14:43] <Saviq> mterry, Text conflict in tests/qmltests/tst_Shell.qml
[14:43] <Saviq> 1 conflicts encountered.
[14:44] <mterry> Saviq, yeah but you copy and pasted the same url
[14:44] <mterry> Saviq, which two conflict?
[14:44] <Saviq> mterry, aah
[14:44] <Saviq> mterry, lp:~mterry/unity8/notify-authenticated
[14:44] <Saviq> sorries
[14:44] <mterry> Saviq, OK, will chain
[14:47] <mterry> Saviq, updated notify-authenticated to include sim-unlock-on-boot
[15:12] <Saviq> mterry, thanks
[15:17] <Saviq> mterry, will you resubmit with prerequisite too?
[15:20] <mterry> Saviq, oh I figured that would be unnecessary paperwork, but I can do
[15:21] <Saviq> mterry, it ensures correct ordering of merges :)
[15:22] <mterry> Saviq, done
[15:22] <Saviq> mterry, thanks
[15:22] <mterry> (including re-setting the commit message -- so annoying that that's lost on a resubmit)
[15:23] <Saviq> mterry, +1
[15:35] <mterry> Saviq, btw I'm gone tomorrow and Monday.  I don't think there's anything waiting on me, but just so you know
[15:36] <Saviq> mterry, how about the u-s-c crash?
[15:38] <mterry> Saviq, ah, you said moving toward me as if the diagnostics for where the fault lay weren't settled yet, so I hadn't started looking.  I can look today and do a brain dump on the bug
[15:38] <Saviq> mterry, yeah, please do
[15:41] <mterry> Cimi, speaking of, I'm out tomorrow and Monday, so if the location-page merge is still in limbo, can you please find someone to finish it up?
[15:45] <dandrader> Saviq, Ha! I think I have a way to reproduce the mysterious no mouse-event bug (or something similar to it)
[15:46] <Saviq> dandrader, oh!
[16:06] <Saviq> greyback, what's with https://code.launchpad.net/~gerboland/qtmir/lttng/+merge/231750, why's that resubmitted too? and why do I see a changelog entry there ¿?
[16:08] <greyback> Saviq: rebased on top of something else in the silo. changelog remnant of something, removing
[16:08] <Saviq> greyback, yeah, was no need to rebase though?
[16:08] <Saviq> no conflict I mean
[16:08] <Saviq> greyback, I know, you hate me today
[16:09] <Saviq> greyback, I wanted the rebase on Daniel's lifecycle because there were conflicts
[16:09] <greyback> I'm making a clear path of MRs, so there's no ambiguity
[16:09] <Saviq> greyback, yeah, but now I need to rebuild again ;)
[16:09] <Saviq> anyway, doing
[16:10] <greyback> sorry about that
[16:10] <Saviq> greyback, so yeah, at least my approach is to only chain MPs that are, or have the potential to, conflicting
[16:10] <greyback> and no I don't hate you, I understand your approach
[16:11] <greyback> I just dislike that the system requires such an approach
[16:11] <Saviq> greyback, otherwise you're locking your branches in an order, and if one of the bottom ones does not land for whatever reason, the rest is blocked
[16:11] <Saviq> greyback, meaning that there's more than one MP in parallel at any given point? or?
[16:11] <greyback> I just don't trust that "potential to" thing
[16:11] <greyback> it's hard to predict
[16:12] <Saviq> greyback, well, it's not like you can't resubmit when it happens
[16:12] <greyback> Saviq: this chaining approach is effectively compensating for lack of a proper trunk
[16:12] <greyback> and yes I understand the arguments for and against
[16:12] <greyback> and what you're doing is the best we can do. Just the amount of shepherding you have to do is unreal
[16:13] <Saviq> greyback, I'm playing with a modified devel approach in my mind
[16:15] <Saviq> greyback, but any single devel/staging branch gets us into a "only one landing happening at a time" too, because without testing a set of projects (like unity-api,qtmir,unity8 in a single silo) all together, they shouldn't get into staging/devel even IMO
[16:16] <Saviq> greyback, but we could go for a hybrid approach
[16:16] <greyback> Saviq: yep that I get too.
[16:17] <Saviq> greyback, if you want, I can describe what I've in mind
[16:17] <greyback> I'd love a dedicated branch of trunk, with the MRs applied, that you could pass to the silo somehow. And would land in a way that would not screw up the history
[16:17] <greyback> Saviq: well I'm holding off opining until the promised next iteration appears
[16:17] <Saviq> greyback, airline will not change that
[16:18] <Saviq> greyback, but yeah, that's what I was thinking of a hybrid approach, a branch that's clean *on top* of trunk, that would get pulled, not merged, with any additional MPs put on top
[16:20] <Saviq> greyback, so we'd stage self-contained branches, that would get pulled (not merged) onto trunk, on top of that would go any additional MPs in the silo
[16:20] <greyback> Saviq: sounds like a dev branch per silo
[16:20] <greyback> if we can pull onto trunk, then yes I like that
[16:20] <Saviq> greyback, yeah, except I wouldn't do it per silo
[16:21] <Saviq> greyback, MPs that require other project changes would not get staged
[16:21] <Saviq> greyback, we'd only staged top-ack'ed, self-contained MPs
[16:21] <Saviq> I'd still target them against trunk
[16:21] <Saviq> but somewhat manually stage on lp:unity8/staging
[16:21] <Saviq> so they remain Approved until they land in trunk
[16:22] <Saviq> so that there's no confusion between Merged into trunk and Merged into staging/devel, as there generally is
[16:22] <greyback> Saviq: there'll be multiple such branches so. And conflicts will remain easy to happen and miss
[16:22] <Saviq> greyback, which ones? those that require other projects?
[16:23] <greyback> yep
[16:23] <Saviq> greyback, they could get staged if the relevant projects had staging too
[16:23] <Saviq> greyback, they'd get staged together
[16:24] <Saviq> this would have to be in sync so that you can actually build trunks against trunks, stagings against stagings
[16:24] <Saviq> greyback, but that also means we'd need to sync releases between projects
[16:24] <greyback> that's what the train is for :)
[16:24] <greyback> I need to chew on the idea more
[16:25] <Saviq> greyback, well, yeah, but how can you stage something that you haven't properly tested (and by properly with packages built by lp)
[16:26] <Saviq> greyback, if we staged all of them together, that would then mean all the projects will only be landed when the slowest one's staging lands
[16:26] <Saviq> so the slowest one starts blocking others
[16:26] <Saviq> which is why I'd lean towards not staging non-self-contained changes
[16:34] <Saviq> dandrader, if you could have another look at https://code.launchpad.net/~gerboland/qtmir/lttng/+merge/231750 - greyback pushed a few commits more
[16:35] <Cimi> mzanetti, did you see my comment on the right padding branch?
[16:35]  * mzanetti looking
[16:39] <mzanetti> Cimi: GRID_UNIT_PX=16
[16:40] <Cimi> mzanetti, hah
[16:40] <mzanetti> Cimi: so not sure if your change is actually the culprit
[16:42] <mzanetti> Cimi: fails in trunk too... mind fixing it nevertheless? Your branch is close enough
[16:47] <dandrader> Saviq, done
[16:48] <Cimi> mzanetti, I don't know why results are wrong at different gu
[16:48] <Cimi> mzanetti, might be me using mapToItem wrong
[16:48] <Saviq> dandrader, thanks
[16:52] <mzanetti> Cimi: hmm... ok... then I'll have a look at some point here.
[16:52] <mzanetti> Cimi: any idea why testGenericScopeView fails on Jenkins?
[16:52] <Cimi> mzanetti, nope
[16:53] <mzanetti> fails here too
[16:57] <Cimi> mzanetti, something here is crazy
[16:57] <Cimi> mzanetti, titleToCard.x @ 8gu is 64
[16:57] <Cimi> @16 is 16???
[16:59] <mzanetti> Cimi: I don't really know what it what atm
[17:01] <Cimi> mzanetti, var titleToCard = title.mapToItem(card, 0, 0, title.width, title.height);
[17:01] <Cimi> mzanetti, the x of this Item does crazy things when changing GU
[17:02] <mzanetti> yeah... I mean I don't know where the tile in the card is etc
[17:02] <mzanetti> still trying to figure
[17:02] <Cimi> mzanetti, is the title you see... doesn't visually change position
[17:02] <Cimi> mzanetti, unless is relative to a previous load
[17:03] <Cimi> mzanetti, it's a race!
[17:04] <Cimi> mzanetti, I added wait(1000) after the waitForRendering
[17:04] <Cimi> mzanetti, it might be because title is the variable in the TestCase, and not calculated there
[17:04] <dandrader> Mirv, so I wanna propose a patch for merging into qtdeclarative-opensource-src. Should it go to lp:ubuntu/qtdeclarative-opensource-src or lp:ubuntu/utopic-proposed/qtdeclarative-opensource-src
[17:04] <mzanetti> Cimi: indeed... makes it pass here too with the wait
[17:05] <mzanetti> huh... this seems a bit strange indeed
[17:05] <mzanetti> aren't those objects destroyed all the time?
[17:06] <mzanetti> I wonder how this works at all
[17:06] <mzanetti> ah... because card changes
[17:06] <Cimi> mzanetti, they are defined in the UnityTestCase...
[17:06] <Cimi> card changes maybe too late
[17:06] <Cimi> and the binding is still working
[17:06] <Cimi> with previous card
[17:07] <mzanetti> Cimi: yeah, I guess you want an init() here that somehow makes sure everything is updated
[17:08] <mzanetti> Cimi: maybe something like tryCompareFunction( testcase.title != null|undefined )
[17:08] <mzanetti> hmm... no its not
[17:08] <mzanetti> well, you'll figure something :)
[17:08] <Cimi> mzanetti, yeah... tomorrow :)
[17:08] <Cimi> gym time
[17:08] <mzanetti> o/
[17:09] <Cimi> I'll be back later to review mterry branch anyway
[17:10] <dandrader> Saviq, Mirv do you know what I'm doing wrong? http://paste.ubuntu.com/8107713/ how do I target lp:ubuntu/utopic-proposed/qtdeclarative-opensource-src ?
[17:12] <Saviq> dandrader, try utopic, not utopic-proposed
[17:13] <dandrader> Saviq, btw, do you know if I should target lp:ubuntu/qtdeclarative-opensource-src or lp:ubuntu/utopic-proposed/qtdeclarative-opensource-src ?
[17:14] <Saviq> dandrader, what you *should* target is https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src
[17:14] <Saviq> dandrader, only the packaging branch, not the auto-import
[17:15] <Saviq> dandrader, those are packaging-only branches, they don't carry source
[17:16] <dandrader> Saviq, and what's that then? https://code.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src
[17:16] <Saviq> dandrader, every time a package is uploaded into ubuntu
[17:16] <Saviq> dandrader, the changes get pushed there as a commit
[17:16] <dandrader> Saviq, "This page is for a packaging branch for a program in Ubuntu. Changes should be made here to Ubuntu packaging or for changes specific to Ubuntu's needs. Changes to the program in general should be made on the upstream branch"
[17:16] <dandrader> sounds like what I want...
[17:16] <Saviq> dandrader, indeed :)
[17:17] <Saviq> dandrader, but in this case, because there *is* a packaging branch
[17:17] <Saviq> dandrader, you should target that
[17:18] <dandrader> crazy
[17:18] <Saviq> dandrader, truth be told I don't think the /ubuntu/ branches are used for anything else than tracking changes in the packages that go into distro
[17:18] <Saviq> they might have been before, but not these days
[17:30] <Mirv> dandrader: just a quick note that Saviq is right, offer an additional patch against kubuntu-packaging debian/ only branch. but first please do git clone ssh://danieldandrada@codereview.qt-project.org:29418/qt/qtdeclarative.git and propose it to upstream (instructions in wiki) so that we don't change in a thing like touch handling from upstream
[17:30] <Mirv> s/change/diverge/
[17:31] <Mirv> (I checked that you've an account for pushing MP:s to Qt)
[17:32] <dandrader> Mirv, so I should propose upstream *before*  proposiing the ubuntu packaging patch?
[17:34] <Mirv> dandrader: yes, always. in case of urgencies we may not necessarily wait for it to be accepted but the normal procedure would be to wait that upstrem accepts it and then cherry-pick it from there.
[17:35] <Mirv> but since proposing is ~easy, it's nicer to git fetch "proposed upstream patch" at least from the upstream tracker
[17:36] <Mirv> plus we don't make other Qt 5 users in derivatives raise eyebrows in non-upstream patches appearing, now that KDE5 is full steam also
[17:38] <dandrader> alright
[19:05] <ajalkane> Can anyone give me some indicators where to start off with fixing this bug: https://bugs.launchpad.net/hud/+bug/1165420 (Unable to access indicators from HUD)
[19:05] <ajalkane> It's driving me crazy
[20:15] <mterry> Cimi, try the location branch now, I read the file directly and present in a Label
[20:15] <mterry> Cimi, much nicer, I just didn't know it was relatively easy to load a file in Qml
[20:53] <Cimi> mterry, can you remove the quote in bug reports?
[20:54] <mterry> Cimi, the bit about location?
[20:54] <Cimi> for location
[20:54] <Cimi> yup
[20:55] <mterry> Cimi, sure.  I've asked design what we should do, they are considering combining the two pages.  but until then, removing the excess line is fine
[20:55] <mterry> Cimi, done
[20:56] <Cimi> mterry, excellent thx
[20:56] <Cimi> mterry, I would combine the two pages
[20:56] <Cimi> yeah not now :)
[20:56] <Cimi> I think it makes sense
[20:58] <Cimi> mterry, the stuck is messed up
[20:58] <mterry> Cimi, stuck?
[20:59] <Cimi> mterry, stack
[20:59] <mterry> Cimi, how do you mean?
[20:59] <Cimi> mterry, to reproduce
[20:59] <Cimi> mterry, check "t & c"
[20:59] <Cimi> mterry, tap on link to read them
[21:00] <Cimi> mterry, even try the webview
[21:00] <Cimi> mterry, now go back
[21:00] <Cimi> mterry, continue
[21:00] <Cimi> mterry, here goes back to wifi
[21:01] <Cimi> mterry, or other combinations...
[21:02] <mterry> Cimi, works for me..
[21:02] <Cimi> dunno then...
[21:03] <mterry> Cimi, you updated all the changed files from the branch update?
[21:03] <Cimi> yep
[21:04] <Cimi> mterry, I can approve but we need another eye
[21:05] <Cimi> mterry, definitely not working for me
[21:05] <Cimi> mterry, do you have a sim card?
[21:05] <mterry> Cimi, :(
[21:05] <mterry> Cimi, no
[21:05] <Cimi> I also have that page in the stack
[21:05] <Cimi> ah ok
[21:05] <Cimi> so we are same situation
[21:06] <Cimi> I will try recording
[21:17] <Cimi> mterry, we should print the stack... but I cannot now
[21:18] <Cimi> mterry, https://drive.google.com/file/d/0BzO8ZDfBk9UKaWI0MWFLaG52TUk/edit?usp=sharing
[21:30] <dandrader> Mirv, so I should propose upstream *before*  proposiing the ubuntu packaging patch?
[21:34] <dandrader> ^^^^ weird. I accidentally resent a previous message. ignore it