[09:23] <Saviq> mzanetti, morning, can you please make launcher hide by default for now, until there's UI to change the behaviour
[09:24] <mzanetti> kk
[09:24] <mzanetti> Saviq, just out of curiosity: why?
[09:24] <mzanetti> because you like it better? or does it introduce an issue?
[09:24] <mzanetti> I mean, the default for unity7 is to show it too
[09:24] <mzanetti> and all the mockups do show it too
[09:25] <Saviq> mzanetti, design review
[09:25] <mzanetti> ah ok
[09:25] <Saviq> mzanetti, it just changes behaviour without a (UI) way to go back
[09:25] <mzanetti> so bascially in unity7 we use a default that we shouldn't use
[09:25] <Saviq> mzanetti, no, it's just about that there's no UI for changing it
[09:25] <Saviq> mzanetti, we'll make it stick by default when there's a setting UI
[09:26] <mzanetti> my point is, we're changing it now because the majority doesn't like it to be always shown. why not have that as default then?
[09:26] <mzanetti> Saviq, should I push it to launcher-sizing or create a new branch?
[09:26] <Saviq> that's not why we're changing it ;)
[09:27] <mzanetti> not sure then why :D
[09:27] <Saviq> mzanetti, because it's a behaviour change without UI to go back
[09:27] <mzanetti> it's not really a behavor change... there is no release of the desktop stuff yet
[09:28] <mzanetti> pushing to launcher-sizing then, ok?
[09:29] <Saviq> mzanetti, yeah
[09:29] <mzanetti> done
[09:30] <tsdgeos> the "use this screen as a pointer" thing disappears with silo 10 after touching
[09:30] <tsdgeos> is that on purpose?
[09:30] <tsdgeos> mzanetti: ↑
[09:31] <Saviq> tsdgeos, yes, it always disappeared
[09:31] <Saviq> the text I mean
[09:31] <tsdgeos> really?
[09:31] <tsdgeos> ok, i had a different memory
[09:43] <tsdgeos> Saviq: i think https://code.launchpad.net/~aacid/unity8/desktopRotatedCamera/+merge/287137 fixes the camera problem, or at least does with mako+silo 10+forcing desktop mode
[09:43] <tsdgeos> not sure if it does fix the problem with flo
[09:43] <Saviq> tsdgeos, ack, will check
[09:43] <tsdgeos> as far as i understand it should
[09:44] <Saviq> tsdgeos, how about min/max window dimensions?
[09:45] <tsdgeos> Saviq: how are they related?
[09:45] <Saviq> tsdgeos, same way requestedSize is, no? we need to transform them wrt the counter rotation?
[09:45] <tsdgeos> but this is for fullscreen apps only, no?
[09:46] <Saviq> tsdgeos, no
[09:46] <tsdgeos> no?
[09:46] <tsdgeos> ok, then this won't work :D
[09:47] <Saviq> tsdgeos, camera isn't fullscreen in windowed any more (there's a .click for it in the silo "Manual Download" section, should've mentioned it)
[09:48] <tsdgeos> ok
[09:49] <tsdgeos> will review a few things first and go back to it
[10:10] <cimi> tsdgeos, ping
[10:10] <tsdgeos> cimi: hi
[10:11] <cimi> hola hola companero
[10:11] <cimi> (not sure is correct)
[10:11] <tsdgeos> kind of yea
[10:11] <tsdgeos> you can't type ñ
[10:11] <cimi> nope
[10:12] <cimi> I was reading your comment on the review of review preview
[10:12] <tsdgeos> yep
[10:12] <cimi> Title of the Rating & review widget to be same size as the others (i.e.: “Info”, “Updates”) and sizes of stars must be x1.5 current size.
[10:12] <tsdgeos> see the Wireframe
[10:12] <cimi> it's unrelated to my modifications? just a bug
[10:12] <tsdgeos> it is and it is not
[10:13] <tsdgeos> the whole bug is "it's hard to do this"
[10:13] <tsdgeos> now with your changes is almost even harder
[10:13] <tsdgeos> because you can barely find where to do the review
[10:13] <tsdgeos> since it's so small in the grand scheme of thigns
[10:14] <cimi> oki
[10:15] <cimi> tsdgeos, why are we using semi transparent text?
[10:15] <cimi> everywhere in the previews
[10:15] <cimi> tsdgeos, wouldn'd be faster to blend the color with the background color of our scopes and have it opaque?
[10:18] <Saviq> cimi, it's still antialiased
[10:18] <Saviq> so still needs to be blended
[10:18] <tsdgeos> cimi: did we ever get a scope to test https://code.launchpad.net/~cimi/unity8/preview-sharing-string-and-array/+merge/287008 ?
[10:19] <cimi> tsdgeos, private message
[10:27] <cimi> tsdgeos, shall I also move the rating stars under the "rate this" label?
[10:27] <tsdgeos> cimi: yeah
[10:27] <tsdgeos> well at least that's what the wireframe seems to want
[10:28] <cimi> tsdgeos, still, padding and star sizes are different from wireframe
[10:28] <tsdgeos> cimi: they also the star bigger, no?
[10:30] <cimi> tsdgeos, yeah
[10:30] <tsdgeos> also -> also want
[10:30] <tsdgeos> :D
[10:36] <cimi> tsdgeos, pushing http://paste.ubuntu.com/15196182/
[10:37] <cimi> tsdgeos, even if it looks like we need different icons for the rating, those are small
[10:39] <tsdgeos> cimi: ask design for bigger ones?
[10:40] <cimi> tsdgeos, yeah I will
[10:40] <tsdgeos> cool :)
[10:41] <tsdgeos> cimi: tried just enlarging the ones we have now by setting the size and checking how they look?
[10:41] <tsdgeos> maybe it's acceptable
[10:41] <tsdgeos> after all it's just straight lines
[10:42] <cimi> tsdgeos, I'll get double size
[10:42] <tsdgeos> ok, i think this big size is only for "your" review, not for the others people have made
[10:43] <cimi> tsdgeos, yeah
[10:43] <tsdgeos> k
[10:57] <cimi> tsdgeos, so matthieu gave me new svg
[10:57] <cimi> tsdgeos, question is, will using svg make reviews slower to view?
[10:57] <cimi> tsdgeos, or qml smartly caches the texture?
[10:59] <tsdgeos> it should cache it, but not for the first render as far as i remember
[11:01] <cimi> tsdgeos, yeah that was my guess
[11:01] <cimi> it shouldnt be a problem
[11:04] <tsdgeos> cimi: two comments on https://code.launchpad.net/~cimi/unity8/preview-sharing-string-and-array/+merge/287008
[11:14] <tsdgeos> davmor2: when you have some time, i think https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1535798 "fixed itself" with the media-hub changes
[11:14] <ubot5`> Launchpad bug 1535798 in Canonical System Image "My Music scope, tracks with odd characters in the path play but don't update the icon or show progress bar" [High,In progress]
[11:15] <davmor2> tsdgeos: I'll give it a go when I get a few minutes
[11:16] <tsdgeos> greatx
[11:57] <cimi> tsdgeos, resolving an url is not simple ad I thought
[11:57] <cimi> tsdgeos, I did                 console.log(Qt.resolvedUrl(shareData["uri"][i]), exportedItems[i].url)
[11:57] <cimi>                 verify(exportedItems[i].url == Qt.resolvedUrl(shareData["uri"][i]));
[11:58] <cimi> tsdgeos, however one of them has path of the test file, the other the real qml component path
[11:58] <tsdgeos> cimi: don't resolve the url
[11:58] <tsdgeos> cimi: just give it an url as input
[11:58] <tsdgeos> a fake one
[11:58] <cimi> ah ok
[11:58] <tsdgeos> file:///this/is/an/url
[12:01] <cimi> tsdgeos, fixed
[12:04] <tsdgeos> cimi: does compare work instead veify?
[12:04] <cimi> tsdgeos, I asked myself the same, I guess it will
[12:05] <cimi> tsdgeos, pushed with compare
[12:05] <tsdgeos> cool
[12:05] <tsdgeos> Saviq: yeah confirmed, bugfix doesn't work with non fullscreen windows, back to drawing board
[12:05] <Saviq> kk
[12:26] <cimi> tsdgeos, how do I get the suru icon inside actions/scalable/ ?
[12:27] <cimi> tsdgeos, I tried with image://theme/starred
[12:27] <tsdgeos> that should be it
[12:27] <tsdgeos> doesn't work?
[12:27] <tsdgeos> look at the other theme icons we have
[12:28] <cimi> tsdgeos, it works, just matthieu gave me a different name
[12:28] <tsdgeos> we have image://theme/clear works
[12:28] <tsdgeos> ok
[12:28] <tsdgeos> food!
[12:28] <cimi> tsdgeos, starred worked, unstarred didnt
[12:28] <cimi> was non-starred
[12:28] <cimi> enjoy
[12:35] <mzanetti> Saviq, found a bad merge. fixed it. now we should be ok
[12:36] <Saviq> mzanetti, uh oh, does it conflict with spread-visual-updates?
[12:36] <Saviq> https://ci-train.ubuntu.com/job/ubuntu-landing-064-1-build/69/console
[12:36] <mzanetti> hmpf
[12:37] <alan_g> greyback: are we ever going to land the initial window management MPs in qtmir?
[12:37] <mzanetti> could be...
[12:37] <Saviq> alan_g, trying
[12:38] <greyback> alan_g: what he said ^
[12:39] <mzanetti> Saviq, easy one. resubmitting visual-updates
[12:39]  * alan_g wonders what can reasonably take 3 months of trying
[12:39] <mzanetti> haha
[12:39] <mzanetti> like landing the launcher branches?
[12:40] <Saviq> alan_g, the usual, $reasons
[12:41] <alan_g> $reasons need fixing
[12:41] <Saviq> we're on it
[12:42] <alan_g> Really? Soon MPs will be landing in hours?
[12:44] <Saviq> if someone takes care of landing them, sure
[12:45] <alan_g> EXPECT_THAT("takes care of landing", Eq(TA))
[12:47] <cimi> tsdgeos, after lunch, https://code.launchpad.net/~cimi/unity8/preview-rating-input-tweaks/+merge/287065
[12:47] <cimi> look at the changes
[12:48] <cimi> like, visual changes
[12:57] <alan_g> Saviq: are you conflating "land" with "release"?
[12:58] <Saviq> alan_g, yes, we don't, and we won't, have a staging/devel branch like Mir does
[12:58] <Saviq> trunk == release
[12:59] <alan_g> That is soo last century.
[12:59] <Saviq> I'm hoping for implementing a twist on the staging approach, will let you guys know how it goes
[12:59] <alan_g> CI is widespread and proven to be more effective
[13:00] <Saviq> I've yet to be convinced
[13:00] <alan_g> What do you need convincing of? That it is better to identify problems early?
[13:01] <Saviq> alan_g, of a different process that works for us reliably
[13:01] <alan_g> That "release" doesn't need to deal with conflicts that could have been resolved weeks ago?
[13:02] <alan_g> That it is good to have a branch with the latest changes?
[13:02] <Saviq> too many times have I had to pull things, that have supposedly been "ready to go", from a release
[13:03] <alan_g> Wouldn't it be better to detect the problem when marking "ready to go" than when releasin?
[13:03] <Saviq> oh sure, let me know when you solve how to do this ;)
[13:04] <alan_g> What's the problem with that? Why don't you detect problems earlier?
[13:05] <alan_g> Is there something you don't do until release?
[13:05] <alan_g> Why not?
[13:07] <Saviq> we don't have enough autotest coverage atm, it's easier to do manual testing when things are in a silo already, and doing it once together for a bunch of changes is less time consuming than per chnage
[13:09] <alan_g> Yep, reliance on manual testing is disruptive to an effective workflow. But that's not really solved by DI.
[13:10] <alan_g> Unless you address that you're going to get very poor throughput.
[13:11] <alan_g> And if you address it you'll be happy with CI?
[13:14] <Saviq> I don't see me merging into trunk without release, no – I do plan to have a staging branch onto which self-contained changes (not dependant on other projects) will be... staged
[13:15] <Saviq> but that's just potehto, potahto, I want our trunks to equal what's in ubuntu, you have a separate lp:mir/ubuntu branch for that
[13:16] <Saviq> we will have a lp:project/staging to stage things - you have lp:mir to do that
[13:19] <alan_g> That's likely just a contectual terminology thing. Usually developers refer to the active development branch as "trunk" whereas packages refer to the current distro as "trunk"
[13:19] <alan_g> *contextual
[13:20] <alan_g> The point is that CI is about integrating somewhere continuously
[13:21] <Saviq> alan_g, sure, that I want to do, with the caveat that I only want to include self-contained changes, to not introduce interdependencies between development branches of different projects
[13:22] <Saviq> it does feel like we're missing a MP state that differentiates Merged vs. Released
[13:22] <alan_g> That too can be managed by automation (I've done it a few times). But agree it isnt the next step.
[13:24] <alan_g> It is a state of the piece of work. But the MP specifically is just merged.
[13:24] <alan_g> So the trello card or bug fix can be "merged/waiting for release"
[13:25] <alan_g> And those states exist
[13:25] <Saviq> yeah, but that means we have multiple tools to track the progress of something, I can't easily look at an MP to know whether it's released or not
[13:26] <Saviq> if all of them were backed by bugs, we could do what you do in Mir; but not all of them are (and for good reason)
[13:27] <Saviq> my biggest beef, with projects that have a staging/devel branch today, is that I need to hunt for whether a particular MP got released yet
[13:30] <alan_g> Sure it could be easier than comparing the "merged at revision" and the tag for the release
[13:32] <alan_g> But you're saying that QtMir is getting a branch for CI to target and that things will land there without waiting for a release?
[13:36] <Saviq> alan_g, that's the plan, yes
[13:37] <alan_g> Great
[13:37] <Saviq> alan_g, note I won't allow "updates for Mir 0.21" in there, though, those would have to land in train as they do today ;)
[13:37] <Saviq> otherwise we'd have to wait for you to release Mir 0.21 to land our staging
[13:38] <alan_g> Saviq: would you allow them if they have #if conditionals on the Mir version?
[13:38] <Saviq> alan_g, sure, if I can land them without landing new mir, fine by me
[13:39] <Saviq> s/land/release/
[13:39] <alan_g> That ought to cover most things then. :)
[13:41] <alan_g> That would let us set up builds against both release and development versions of Mir - and maybe also populate a "development" ppa
[13:42] <Saviq> yup
[13:42] <Saviq> alan_g, that said, devel-mir-next is a kind of "staging" for new Mir releases
[13:44] <Saviq> alan_g, that could be backing the development PPA, following the "real" staging of qtmir at the same time
[13:44] <alan_g> Saviq: true, today that lets us release Mir without worrying QtMir changes.
[13:49] <alan_g> I think it would be nice to have /all/ the most recent changes for our little collection of projects in a PPA
[13:49] <Saviq> totally doable
[13:53] <alan_g> Having a CI job that highlights downstream issues (without blocking landing) ensures things don't get overlooked
[14:35] <tsdgeos> cimi: in https://code.launchpad.net/~cimi/unity8/preview-rating-input-tweaks/+merge/287065 we don't have a test that actually checks that the thing grows after selecting a star, no?
[14:45] <cimi> tsdgeos, we test if they are visible
[14:45] <tsdgeos> cimi: before and after clicking a star?
[14:45] <cimi> tsdgeos, I can make a test to see if it grows
[14:45] <cimi> tsdgeos, not that, indeed
[14:45] <tsdgeos> cimi: i'd like a test that shows that it is not visible before and it is after
[15:10] <cimi> tsdgeos, well we do test that if there is a valid input of rating the review area is visible
[15:10] <tsdgeos> do we?
[15:11] <tsdgeos> where?
[15:11] <cimi> tsdgeos,             if (data.widgetData["visible"] [15:11] <cimi>                 compare(reviewTextArea.visible, false);
[15:11] <cimi> so this is before
[15:11] <cimi> then
[15:12] <cimi> tsdgeos, yeah I guess we miss that the flag turns visible after
[15:13] <tsdgeos> oki, can you add it?
[15:16] <Silentlord> I am creating a trayicon but on ubuntu 14.04 unity is not showing but other tray icons are showing, what can i do?
[15:21] <greyback> Silentlord: system tray has a whitelist specified in gsettings, look for systray-whitelist in com.canonical.Unity.Panel
[15:24] <Saviq> Silentlord, also check out https://unity.ubuntu.com/projects/appindicators/
[15:25] <Silentlord> i dont have that property
[15:25] <Silentlord> com.canonical.Unity.Panel
[15:27] <Saviq> Silentlord, systray-whitelist is no longer there - see bug #974480 ← greyback
[15:27] <ubot5`> bug 974480 in unity (Ubuntu) "Notification area whitelist is obsolete" [High,Fix released] https://launchpad.net/bugs/974480
[15:28] <greyback> huh, old memory then
[15:42] <tsdgeos> cimi: i have a few branches waiting for review if you want
[15:42] <cimi> tsdgeos, cool
[15:43] <cimi> tsdgeos, I added a test for visibility after good rating
[15:43] <tsdgeos> cimi: here they come
[15:43] <tsdgeos> https://code.launchpad.net/~aacid/unity8/unity-scope-tool-fixes/+merge/287191
[15:43] <tsdgeos> https://code.launchpad.net/~aacid/unity8/cardCreatorFixedHeaderSizeOptimization/+merge/286281
[15:43] <tsdgeos> https://code.launchpad.net/~aacid/unity8/cardAsyncOnCompileTime/+merge/286275
[15:58] <mterry> I'm building in a chroot and getting the following error with u8 trunk.  Am I doing something dumb (file seems to be in place, u8 seems to have call to find it):
[15:58] <mterry> /root/u8/trunk/plugins/Lights/android-hardware.h:22:31: fatal error: hardware/hardware.h: No such file or directory
[15:58] <mterry>  #include <hardware/hardware.h>
[16:02] <alan_g> mterry: I think kdub fixed something similar in Mir
[16:03] <kdub> mterry, there's been some shuffling of the android headers in archive
[16:12] <tsdgeos> mterry: dpkg -l | grep  android-headers
[16:12] <mterry> ii  android-headers                                 23-0ubuntu1~overlay1                                  all          Android Platform Headers from AOSP releases
[16:12] <mterry> ii  android-headers-19                              23-0ubuntu1~overlay1                                  all          Android Platform Headers from AOSP releases
[16:12] <mterry> tsdgeos, ^
[16:12] <tsdgeos> mterry: that is vivid or xenial?
[16:13] <mterry> tsdgeos, vivid + overlay
[16:13] <tsdgeos> k
[16:13] <tsdgeos> no idea, xenial needs 23-0ubuntu2
[16:13] <tsdgeos> with 23-0ubuntu1 we had that error too
[16:14] <tsdgeos> but we have the train building it
[16:14] <tsdgeos> so it is buildable
[16:25] <mterry> tsdgeos, ah... android-headers changed /usr/include/android to be a symlink. But looks like it doesn't handle upgrades.  So had to uninstall and reinstall.  :-/  ah well
[16:26] <tsdgeos> ouch
[16:27] <cimi> tsdgeos, https://code.launchpad.net/~cimi/unity8/preview-rating-input-tweaks/+merge/287065/comments/732746
[16:30] <tsdgeos> k
[16:30] <tsdgeos> will check tomorrow
[17:16] <josharenson> Saviq: any interesting bugs I can take on while I wait for reviews on yesterdays MPs?