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