[08:36] <Saviq> mzanetti, I can has a sanity check https://code.launchpad.net/~unity-team/unity8/drop-hud-bottom-edge/+merge/218572
[08:39] <mzanetti> Saviq: yep
[08:41] <mzanetti> greyback: hey, tsdgeos is splitting the dash into an app.
[08:42] <mzanetti> greyback: was wondering if it should be threated as a proper app in ApplicationManager or just be a surface in SurfaceManager
[08:42] <mzanetti> but probably a real app
[08:42] <mzanetti> whats your opinion on that?
[08:42] <mzanetti> tsdgeos: what's different in terms launching it?
[08:42] <mzanetti> it is a separate process, is it?
[08:43] <tsdgeos> mzanetti:
 so it can't be launched by upstart-app-launch
 but rather "on started unity8" or so
[08:43] <mzanetti> sure... but that's not a problem...
[08:44] <mzanetti> I mean, we still can start suff from cmdline with --desktop_file_hint=...
[08:44] <mzanetti> so... it'll be just the same
[08:44] <mzanetti> I think the ApplicationManager API needs a new method startDash() or similar
[08:44] <mzanetti> and ApplicationInfoInterface needs a property closable which we can set to false
[08:45] <mzanetti> and then it just launches the process in there and we're up just like any other app
[08:45] <mzanetti> now the question is on which branch to do that :D
[08:45] <mzanetti> I'd need this at first in the tablet branch I guess
[08:46] <Saviq> mzanetti, we don't want to support running with --desktop_file_hint for long
[08:47] <mzanetti> Saviq: sure... but because we don't want to supoprt it any more, not because there is something preventing us to do that
[08:47] <Saviq> mzanetti, well, yeah, but I mean we don't want to use it for the dash because of that
[08:48] <mzanetti> Saviq: no... I wanted to say that in the ApplicationManager we're fine with non-upstart-started apps
[08:48] <mzanetti> and gave that as an example
[08:48] <Saviq> mzanetti, ah yeah, sure
[08:49] <greyback> mzanetti: I presume Dash will never be lifecycled? (i.e. save state & killed)
[08:49] <Saviq> Cimi, if you haven't started yet, lp:~unity-team/unity8/new-infographics I started cleaning this up before
[08:49] <Saviq> greyback, it won't
[08:49] <mzanetti> greyback: hmm... wouldnt say so
[08:49] <mzanetti> no?
[08:49] <mzanetti> ok
[08:49] <Cimi> Saviq, I can merge thx
[08:50] <mzanetti> ah right... yeah... no state saving and killing
[08:50] <mzanetti> but are we freezing it in the background?
[08:50] <Saviq> yeah, SIGSTOP, yes
[08:50] <mzanetti> kk
[08:50] <tsdgeos> we plan sigstoping the dash?
[08:51] <mzanetti> once its an app it'll happen
[08:51] <greyback> hmm, well we can choose
[08:51] <mzanetti> unless we add some exceptions to that too
[08:51] <greyback> if dash crashes, upstart relaunches it
[08:52] <tsdgeos> yes
[08:53] <greyback> Saviq: OSK is a trusted helper?
[08:53] <Saviq> greyback, not yet it isn't
[08:54] <greyback> Saviq: but it will be
[08:54] <Saviq> greyback, there were talks of making it one
[08:54] <greyback> Saviq: yeah. The advantage of which now escapes me
[08:54] <Saviq> greyback, probably makes sense
[08:54] <mhr3_> Saviq, hey, do you know how are we going to deal with language changes? atm some things change when you switch language, most don't
[08:54] <Saviq> mhr3_, reboot
[08:55] <mhr3_> cool then
[08:55] <Saviq> mhr3_, no other plan that I know of
[08:55]  * mhr3_ ticks that off
[08:55] <Saviq> mhr3_, we probably could have a per-user setting somewhere that everything would listen to changes of
[08:55] <mhr3_> seb128, is that something on your list ^?
[08:55] <greyback> Saviq: I was going to propose that Dash&OSKs were "shell helper applications" that the AppMan can manage separately
[08:55] <greyback> mzanetti: ^^
[08:56] <greyback> but if OSK is instead to be a trusted helper thing...
[08:56] <Saviq> greyback, OSK is a bit more special, it's app-bound
[08:56] <Saviq> greyback, i.e. when moving apps around, we should move the OSK with them
[08:56] <Saviq> greyback, so in that sense it makes sense for it to be a trusted helper
[08:57] <mhr3_> Saviq, yea, we could, imo for rtm reboot is safer, we have too many components that should listen to it, and i'm pretty sure at least one wouldn't :)
[08:57] <Saviq> mhr3_, indeed
[08:57] <Saviq> mhr3_, and then we're using gettext() directly in C++, which doesn't support "updating"
[08:58] <mhr3_> it does
[08:58] <mhr3_> and i remember that from my windows days :P
[08:58] <greyback> Saviq: sounds a bit overcomplicated for a small gain. Why not 1 OSK, and each app's osk state is saved and applied when that app is brought to the front?
[08:59] <Saviq> greyback, oh wait I didn't say it's actually meant to be multiple OSKs
[08:59] <Saviq> greyback, it could be multiple surfaces, or just one surface that we screenshot
[08:59] <Saviq> greyback, but it does get complicated with that
[09:00] <Saviq> greyback, because you might have 5 OSKs on the spread, each in a different layout / state
[09:00] <mzanetti> did I just hear the word screenshot?
[09:00] <mzanetti> :D
[09:00] <Saviq> greyback, and we need to maintain that
[09:00] <Saviq> mzanetti, we'll need those anyway
[09:01] <greyback> Saviq: we could just hide the OSK when you start spread, and restore it when app re-focused
[09:01] <Saviq> greyback, and re-flow the app in the process? no
[09:02] <greyback> Saviq: we've just gone down the road that every application, once it uses the OSK, becomes part of a trusted session
[09:02] <Saviq> greyback, I'm not hung up on that, don't worry
[09:02] <greyback> which is a complex solution to a small problem IMO
[09:02] <Saviq> greyback, but remember apps need to adapt to the OSK (like add a bottom margin for example)
[09:02] <Saviq> greyback, if you remove the OSK going into the spread, you need to reflow the app, and reflow it back when focusing it again
[09:02] <greyback> Saviq: I realise that, I don't think that's terrible
[09:02] <Saviq> greyback, I do
[09:03] <Saviq> greyback, and designers do, too, we've talked about this
[09:04] <Saviq> greyback, imagine switching between two apps with a short-right-edge gesture, both apps have a keyboard
[09:04] <Saviq> greyback, the amount of movement on the screen would make me barf
[09:04] <Saviq> if both apps would reflow all the time
[09:04] <seb128> mhr3_, what?
[09:06] <Saviq> greyback, don't get me wrong, this *could* be solved by a single OSK surface that we snapshot, I'd be worried about making it restore to the correct state when switching apps
[09:06] <Saviq> greyback, but sure it's possible - I do think it'd be easier if there were just multiple OSK surfaces for each app that needs one at any given time
[09:06] <Saviq> greyback, obviously more resource-hungry, though
[09:09] <Saviq> and now greyback's sitting in a corner cursing me to seven hells
[09:09] <greyback> Saviq: was making tea
[09:09] <Saviq> greyback, trying to calm your nerves, are you :D
[09:09] <Saviq> mhr3, <seb128> mhr3_, what?
[09:10] <mhr3> seb128, reboot after lang change
[09:10] <mhr3> and thx Saviq
[09:10] <Saviq> mhr3, session restart would be enough
[09:10] <mhr3> right
[09:10] <greyback> Saviq: again, I see that there's an extra animations going on if OSK separate from app. Anything is possible, but things have a cost. I think the cost is very high. It is up to design to justify that cost
[09:11] <Saviq> greyback, "OSK separate from app"? that's exactly what we _don't_ want, we need OSK to be part of the app
[09:11] <seb128> mhr3, there is that bug about that yes
[09:12] <mhr3> seb128, got bug #?
[09:12] <Saviq> greyback, there's obviously one interesting part to it... side-stage
[09:12] <greyback> Saviq: that's the complexity I'm referring to. I'm not convinced. There _needs_ to be an OSK for user to enter text/numbers into an app.
[09:13] <Saviq> greyback, kinda doesn't make sense to keep OSK together with app in multi-app environment, but in a single-app one, I believe there is
[09:14] <Saviq> greyback, anyway, this is indeed a design issue atm, it wasn't solved properly yet
[09:14] <Saviq> greyback, but the main/sidestage argument is definitely one against the use of trusted sessions for the OSK
[09:14] <greyback> Saviq: how about the shell itself?
[09:15] <greyback> if I'm in an app, and snap decision comes in with a text input box, and I tap in it, does another OSK appear?
[09:15] <Saviq> greyback, not necessarily visibly
[09:15] <Saviq> greyback, but yeah, that'd be another case where trusted sessions don't work well
[09:16] <Saviq> greyback, don't get me wrong, I'm not saying that's how it should be
[09:16] <Saviq> greyback, visually, I think it'd be better if we kept the OSK together with the app whenever possible
[09:16] <greyback> Saviq: my primary argument is that OSK per app has a cost, so that cost needs to be justified
[09:16] <greyback> I'm not saying it's a bad idea
[09:16] <greyback> it has many merits really
[09:17] <Saviq> greyback, sure, flipping your argument, single OSK and making it behave has a cost, too
[09:17] <greyback> Saviq: but that's what we have now
[09:17] <greyback> we've mostly paid that cost
[09:18] <greyback> architecturally speaking ofc
[09:18] <Saviq> greyback, we haven't made it behave yet
[09:18] <Saviq> greyback, sure, it disappears when you unfocus an app
[09:19] <Saviq> greyback, but it stays on screen when you swipe an app in from the right, until you change the focused one
[09:19] <seb128> mhr3, bug #1240875
[09:19] <Saviq> greyback, and it's just a flip of visible: true/false, not exactly nice UX
[09:19] <mhr3> seb128, thx
[09:19] <seb128> mhr3, yw
[09:20] <greyback> Saviq: I did say "mostly" - agreed it does need polish
[09:21] <Saviq> greyback, sure, and as long as the solution to that bad UX is "OSK needs to be part of the app", it brings a lot of complexity whatever way you look at it
[09:21] <Saviq> greyback, but IMO it is the correct thing to do in a single-app environment
[09:22] <Saviq> greyback, we should write this down somewhere
[09:22] <greyback> Saviq: again, I'm not arguing it is wrong, I just think it is a complex approach and thus has a cost
[09:23] <Saviq> especially the pro/con arguments
[09:24] <Saviq> greyback, think we should slap it in one of the wm blueprints? or maybe start a new one?
[09:25] <greyback> Saviq: it's not a very large issue, WM blueprint less likely to be lost in the noise
[09:31] <greyback> mzanetti: Saviq: anyway back to the point, think AppManager will need extending to support a "shell application"=dash, which it can SIGSTOP&SIGCONT, but isn't in running application lists. Its surface can then be controlled via SurfaceManager. Should be enough, no?
[09:31] <mzanetti> greyback: why not in running apps list?
[09:32] <mzanetti> greyback: imo it should be just like any other app but with a property that indicates its special and can't be closed
[09:32] <greyback> mzanetti: don't want user stopping it. Want Dash icon in hardcoded place in list
[09:32] <mzanetti> greyback: which list?
[09:32] <Saviq> greyback, it *needs* to be in the app list
[09:32] <greyback> mzanetti: launcher
[09:32] <Saviq> greyback, maybe you didn't hear, dash is meant to go into the spread et al
[09:32] <mzanetti> greyback: the launcher would just ignore it if that "special" flag is set
[09:33] <mzanetti> greyback: I'm thinking more of code that finds an app to a surface
[09:33] <Saviq> greyback, we're not only talking about splitting the surface, but to actually make it behave like an app
[09:33] <mzanetti> if we just don't allow closing it we won't need to special case all the code around
[09:33] <greyback> Saviq: ah ok
[09:33] <greyback> right well then, it's just a special app
[09:33] <Saviq> greyback, basically, the only way in which dash remains special is that you can't close it and that it respawns
[09:33] <Saviq> greyback, yup
[09:34] <greyback> has it a particular position in the spread?
[09:34] <greyback> i.e. always on the bottom?
[09:42] <Saviq> greyback, no, same as any other app
[09:43] <greyback> ok
[09:55] <Cimi> Saviq, https://code.launchpad.net/~cimi/unity8/preview-text-summary-bottom-padding/+merge/217903/comments/520741
[09:55] <Cimi> what you mean with fixed behaviour?
[09:55] <mzanetti> Saviq: we do want to keep the current HUD code, right?
[09:55] <mzanetti> just keep it disabled
[09:55] <Saviq> mzanetti, yeah
[09:55] <mzanetti> ok
[09:56] <Saviq> Cimi, this fixes the bottom padding, but you only adapt the tests to try instead of compare, which means we didn't actually test that padding before
[09:56] <Saviq> Cimi, would be good to test it now that you fixed it
[09:56] <mzanetti> Saviq: how about qml/Bottombar/Bottombar.qml ?
[09:57] <Saviq> mzanetti, that should probably go away indeed
[09:57] <Cimi> Saviq, that would be a test for height
[09:57] <mzanetti> seems useless if bottombarvisibilitythingy has gone
[09:57] <Wellark> Saviq: what is this war against tags, anyway? :)
[09:57] <Cimi> Saviq, pretty much making sure height is contentHeight
[09:58] <Saviq> Wellark, we got tags from lp:unity into lp:unity8 by way of LP deciding that lp:unity/8.0 should have the same tags as lp:unity, even though the two had nothing to do with each other
[09:58] <Saviq> Wellark, so we're trying to lose the tags that don't make sense for unity8
[09:58] <Cimi> or that height is num lines * line height
[09:58] <Saviq> Cimi, or that it's text height + units.gu(1) ;)
[09:59] <Wellark> Saviq: ok. is this something that has to be done once on lp:unity8 and all of the local branches we have floating around?
[09:59] <Wellark> or is LP adding them back again and again?
[09:59] <Saviq> Wellark, no, just once
[09:59] <Wellark> ok.
[09:59] <Saviq> Wellark, but *everywhere*
[09:59] <Wellark> Saviq: could you not incorporate the script to the ci train merger?
[10:00] <Cimi> Saviq, height is contentHeight
[10:00] <Wellark>  so that for each merge that goes through the CI train process the tags would be stripped
[10:00] <Cimi> I can check that
[10:00] <Saviq> Cimi, you'll manage, just please make a test that fails before your change, but passes after your change :P
[10:00] <Saviq> mzanetti, pushed
[10:00] <mzanetti> cheers
[10:01] <Saviq> mzanetti, dropped the whole Bottombar folder, I doubt we'll need any of it back
[10:01] <mzanetti> +1
[10:01] <Saviq> brb, need to switch to nvidia
[10:07] <mzanetti> paulliu: hey, you around?
[10:18] <Bacta> Hi - am I right in thinking that the placement of window decorations on the left of a window relates to why there's no ability to move the launch to the bottom of the screen?
[10:27] <Saviq> Bacta, not really, it's a design decision that the launcher is on the left, and window buttons are on the left to not conflict with indicator icons when maximized, to name one reason
[10:27] <Bacta> Ok
[10:28] <Bacta> I'm composing a post to the forum but is there a way of moving it to the bottom?
[10:28] <Saviq> Bacta, the fact that it can't be moved, is a maintenance decision - adding customizability means someone needs to support and maintain it
[10:28] <Saviq> Bacta, and then the dash would become disconnected from the launcher
[10:29] <Bacta> That's fine. I'm even happy to accept that it was a design decision but I've tolerated this for a number of years now and still don't like it.
[10:29] <Saviq> Bacta, there's a bunch of reasons, I'm sure there's plenty of questions and answers about this already in launchpad, forums and askubuntu
[10:31] <Cimi> Bacta, the reason why it's on the left is to use screen space at best
[10:32] <Cimi> Bacta, we almost all have wide screen monitors
[10:32] <Cimi> Bacta, so we have more horizontal space than vertical
[10:33] <Cimi> Bacta, it makes more sense to have on left or right edge than top or bottom
[10:34] <Cimi> "First, we want to move the bottom panel to the left of the screen, and devote that to launching and switching between applications. That frees up vertical space for web content, at the cost of horizontal space, which is cheaper in a widescreen world."
[10:34] <Cimi> http://www.markshuttleworth.com/archives/383
[10:36] <Bacta> Sure, but you can't always create a one size fits all solution and this is Linux
[10:37] <tsdgeos> you don't want to use the "this is Linux" argument, it's a noop
[10:38] <Saviq> Bacta, that's why there's plenty of sizes to choose from
[10:48] <Cimi> Bacta, do you have a 4:3 screen?
[10:51] <Bacta> 16:9
[10:53] <Bacta> I've checked out the code. Curious to see if it's possible
[10:53] <Cimi> Bacta, so you fit the solution :)
[10:54] <Bacta> It's a solution looking for a problem
[10:54] <Cimi> Bacta, a launcher on left/right edge allows you to have maximum vertical content when browsing web, writing a document, a mail, music playlistsa...
[10:54] <Bacta> The bottom placement of the launcher is pretty universal
[10:55] <Cimi> Bacta, because was designed 20 years ago when screens were 4:3
[10:55] <Bacta> I could understand the
[10:56] <Bacta> *it being a design decision
[10:56] <Cimi> I personally have a macbook air with osx, no ubuntu installed, and I hated the dock at the bottom
[10:56] <Bacta> But looking back I'm pretty sure it originally shipped with the launcher being hidden automatically?
[10:56] <Cimi> it forces me to have tiny ultrawide web pages
[10:56] <Cimi> so I put it on another side
[11:01] <Cimi> Bacta, if you really want a launcher at the bottom try elementary os
[11:02] <Bacta> I would prefer to keep looking through the source for now ;)
[11:10] <Cimi> Bacta, there was a patch long time ago, I bet it doesn't work anymore
[11:10] <Cimi> Bacta, http://www.omgubuntu.co.uk/2011/12/how-to-customise-unity-like-never-before
[11:10] <Bacta> Yeah I think I tried that one on an earlier version with no luck
[11:21] <Cimi> Saviq, qml-module-qtquick-xmllistmodel  cannot be found when I try sbuilding that branch
[11:21] <Saviq> Cimi, time to switch to utopic
[11:21]  * Cimi scared
[11:22] <Cimi> sudo do-release-upgrade -d
[11:22] <Cimi> nope
[11:22] <Cimi> don't tell me to sed! xD
[11:22] <Saviq> Cimi, nope, `sed -i 's/trusty/utopic/' /etc/apt/sources.list` still
[11:23] <Saviq> might want a "g" after utopic/
[11:23] <Cimi> yes
[11:23] <Cimi> I know sed
[11:23] <Cimi> let me disable PPAs first
[11:25] <Cimi> Saviq, hold on
[11:25] <Cimi> Saviq, is it possible to have utopic in sbuild?
[11:25] <Saviq> Cimi, sure
[11:25] <Cimi> and still trusty as host?
[11:25] <Cimi> wow
[11:25] <Cimi> let me do that then
[11:25] <Saviq> Cimi, but you won't be able to run on your host easily
[11:26] <Cimi> Saviq, running unity on the desktop doesn't work either way
[11:26] <Saviq> ENOGETIT
[11:29] <Bacta> SetGeometry(nux::Geometry(0, 0, width, height));
[11:30] <karni> dpm: Hey man o/ Is translating scopes documented already? I believe it's pretty fresh stuff.
[11:31] <dpm> karni, hey! It's quite fresh indeed, and we've got no docs. This might give you a few pointers, though: https://bugs.launchpad.net/savilerow/+bug/1316713
[11:31] <karni> dpm: thanks
[11:31] <Cimi> Saviq, what does it mean?
[11:31] <Saviq> Cimi, it means Error I NO GET IT
[11:31] <karni> :D
[11:31] <Saviq> Cimi, what do you mean "doesn't work either way"?
[11:33] <Cimi> Saviq, I don't have click apps, or camera app, or other features
[11:33] <Cimi> Saviq, I just run on the phone everytime since this sbuild thing you told me, so fast
[11:34] <Cimi> Saviq, all I need is a script to automatically push and dpkg -i packages from sbuild
[11:34] <Saviq> Cimi, well, run_on_device works still
[11:34] <Cimi> and I will be the happiest dude
[11:34] <Cimi> Saviq, yes, with no space on device :)
[11:34] <Saviq> Cimi, yeah, that's not greeat
[11:35] <Cimi> Saviq, I wasn't able to install the infographgics branch
[11:35] <Cimi> Saviq, I have clean phone, no userdata
[11:35] <Saviq> Cimi, there's nothing there
[11:35] <Cimi> still no enough space
[11:35] <Saviq> Cimi, I just removed the old infographics system
[11:35] <Cimi> yes I saw
[11:36] <Cimi> Saviq, i tried loading the new plugin but I am losing time compiling and such
[11:36] <Cimi> using sbuild now
[11:36] <Cimi> let's see
[11:38] <Cimi> Saviq, no luck in utopic too
[11:38] <Cimi>  qtdeclarative5-ubuntu-ui-toolkit-plugin:armhf : Depends: libqt5qml-graphicaleffects:armhf but it is not installable or
[11:38] <Cimi>                                                           libqt5graphicaleffects5:armhf but it is not installable
[11:38] <Cimi>                                                  Depends: qtdeclarative5-qtquick2-plugin:armhf but it is not installable
[11:38] <Cimi>                                                  Depends: qtdeclarative5-window-plugin:armhf but it is not installable
[11:38] <Cimi> looks like we need to wait a bit
[11:39] <Saviq> Cimi, you should have mentioned that before
[11:39] <Saviq> Cimi, that's a cross-build problem indeed
[11:39] <Cimi> Saviq, so I only have option to use run on device
[11:40] <Saviq> Cimi, the above transitional packages are not correct multi-arch I'm afraid
[11:40] <Cimi> which goes out of space now
[11:40] <Saviq> Cimi, do you have stuff on your phone? it works fine here
[11:40] <Cimi> I don't
[11:40] <Saviq> Mirv, what's the plan to fix the transitional packages?
[11:40] <mzanetti> Saviq: is there a know issue with the qmltest runner currently?
[11:40] <Cimi> maybe I need to run apt-get clean after run_on_device -s
[11:40] <mzanetti> https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/1787/console
[11:41] <Saviq> mzanetti, ↑
[11:41] <Saviq> see the "trusty" part? ;)
[11:41] <Saviq> should be sorted later today
[11:41] <mzanetti> ack
[11:53] <Mirv> Saviq: I'm landing a change to make them multi-arch, but longer term I guess all packages should just get updated to use the new dependencies
[11:53] <Mirv> oh right, and that graphicaleffects is unmodified from Debian so it's not getting fixed by that
[11:53] <Mirv> Saviq: maybe we should start by proposing a branch to UITK (a rare user of graphicaleffects)
[11:54] <Saviq> Mirv, I'll ask around
[12:03] <Cimi> cannot find -llightdm-qt5-2
[12:04] <Cimi> Saviq, on the phone
[12:05] <paulliu> mzanetti: hi
[12:05] <paulliu> mzanetti: what's up?
[12:05] <mzanetti> paulliu: testZoomableImage fails for me all the time
[12:06] <paulliu> mzanetti: hmm. Any error messages for me?
[12:06] <mzanetti> one sec. I'll grab some logs
[12:06] <karni> Tricky question. If I want to _ensure_ an initial request is made by a scope to some API before any other API call, I either have to make a blocking request from scope's start() method (before run() is called), or make that request from scope query class itself, before I allow the query API call. Is that right?
[12:07] <karni> Imagine I need some metadata before any search / surfacing is allowed.
[12:07] <mzanetti> paulliu: http://paste.ubuntu.com/7410037
[12:08] <karni> Saviq: mhr3: Is Scope's start() method called when the scope is instantiated, or when it is first shown to the user (when user swipes to it)?
[12:08] <mhr3> karni, the former of course
[12:09] <karni> mhr3: how about my previous "tricky" question, any ideas?
[12:09] <paulliu> Seems I cannot use absolute value for the test cases.
[12:09] <Cimi> weird had to install manually
[12:09] <karni> mhr3: say I only need one initial request, and want to avoid making that request before each search is issued
[12:10] <mhr3> karni, doing anything time consuming in start() isn't a good idea, scopes are killed and started as needed, if you do something that takes long in start(), the registry might assume that the scope is dead, cause it's taking too long to start it
[12:10] <mhr3> karni, plus the whole thing of delaying the actual startup and therefore searches
[12:10] <karni> mhr3: I could do it in no blocking manner, but that wouldn't ensure it ends before any search is issued
[12:11] <karni> mhr3: right, but in this case a search wouldn't make sense before the initial search completes. say, you don't know what currency you want to displays items with.
[12:11] <mhr3> karni, i'd suggest doing it in Scope::run() and ensuring that queries wait for the result of that run()
[12:12] <karni> mhr3: ok, thanks
[12:12] <mhr3> karni, note that Query::run will be invoked in a different thread than Scope::run
[12:13] <mhr3> karni, and the runtime will not wait for Scope::run() to finish before issuing queries
[12:13] <karni> right.. hrm..
[12:14] <mhr3> karni, still, should be pretty simple with a promise and future
[12:16] <mhr3> hmm, although i'm not sure if you can use the same future in multiple threads
[12:17] <mhr3> ah, looks like there's shared_future for that
[12:19] <karni> I see
[13:04] <Cimi> pete-woods, hi!
[13:05] <Cimi> pete-woods, I installed the infographics plugin, then added InfographicList in unity8... but says Element is not creatable
[13:06] <dandrader> greyback, https://code.launchpad.net/~dandrader/platform-api/window_get_size/+merge/218034 seems ready to go now, finally
[13:07] <greyback> dandrader: great, thank you!
[13:08] <pete-woods> Cimi: hi, okay, you're trying to create a InfographicList right?
[13:08] <pete-woods> hmm
[13:08] <pete-woods> sorry, just read that you said you are
[13:08] <Cimi> pete-woods, just added InfographicList { }
[13:13] <pete-woods> Cimi: okay, yes I have the same thing, let me fix that :$
[13:20] <dandrader> Saviq, so we're all to upgrade to utopic but the phone images are "still" on trusty
[13:26] <dandrader> ah, they changed the channel names. nevermind
[13:29] <pete-woods> Cimi: it's a singleton type, and it is supposed to be defined under the name Infographics.InfographicList
[13:29] <pete-woods> but my QML-foo is weak
[13:29] <Cimi> mm maybe singletones must be defined in the c++? Saviq?
[13:30] <pete-woods> Cimi: it is defined in the C++, I copied how the old plugin did it
[13:30] <pete-woods> it's just I don't really know how to do the QML side
[13:30] <Cimi> I don't remember either, I did once
[13:31] <Cimi> I think the plugin needs some specific code
[13:31] <pete-woods> Cimi: this is what I would expect should work http://paste.ubuntu.com/7410425/
[13:31] <Cimi> so you always connect to the same instance
[13:31] <Cimi> I'll try with that
[13:38] <mterry> Saviq, can you please rekick silo 002?  I *think* we're all ready now.  autopilot passes and seems to work fine
[13:40] <Cimi> Saviq, on https://code.launchpad.net/~unity-team/ubuntu-system-settings/wizard.wifi/+merge/212675/comments/520585
[13:40] <Cimi> were you running the latest mir with my variables landed?
[13:40] <mterry> tedg, so are indicators basically ready for split greeter?  I wasn't worried about alarms before, since they didn't work anyway, but do they have a greeter story?
[13:41] <mterry> tedg, I guess they don't need to, the user session will still be running
[13:43] <Cimi> Saviq, added test https://code.launchpad.net/~cimi/unity8/preview-text-summary-bottom-padding/+merge/217903
[13:46] <tedg> mterry, Yeah, the answer is "generally yes" -- not all of them export data, but we've not been asked for those that don't to at this point.
[13:46] <tedg> mterry, I imagine that there'll be some of "we didn't realize" once split greeter lands... but, it has to land for that :-)
[13:47] <pete-woods> Cimi: http://paste.ubuntu.com/7410479/ this loads for me
[13:47] <pete-woods> the "as Infographics" part fixed it for me
[13:48] <Cimi> pete-woods, thanks, tgrying now
[13:52] <Cimi> pete-woods, and the model is a list of svgs?
[13:52] <pete-woods> Cimi: yep
[13:57] <pete-woods> Cimi: this does the basics for me: http://paste.ubuntu.com/7410537/
[13:57] <Cimi> pete-woods, so uid is required?
[13:57] <Cimi> what else?
[13:58] <Cimi> pete-woods, do you know all the model rules?
[13:58] <pete-woods> Cimi: that's it, the only property
[13:58] <Cimi> like display etc etc..
[13:59] <pete-woods> Cimi: I just inherited from QStringListModel, as far as I can tell, that just sets the display role
[13:59] <pete-woods> but I could be wrong
[13:59] <pete-woods> I know very little about QML
[13:59] <Cimi> pete-woods, and I know very little of c++ :D
[13:59] <Cimi> we're best match :D
[13:59] <pete-woods> :D
[13:59] <Cimi> don't worry
[13:59] <Cimi> I'll have a look
[14:00] <Cimi> just to get all info you knew so I can go
[14:00] <pete-woods> that example, I just pasted at least shows the list of all the files
[14:01] <mhall119> mhr3: didrocks: I'll be a minute, seems I need to reboot
[14:01] <mhall119> hangouts don't recognize my mic or camera
[14:05] <Cimi> dednick, I see a nice merge conflict here from the diff https://code.launchpad.net/~nick-dedekind/unity8/indicator.call-hint/+merge/218627
[14:06] <dednick> Cimi: thanks
[14:15] <mterry> mzanetti, hey...  don't we sync launcher items with AccountsService?  Or did we stop doing that?
[14:19] <mzanetti> mterry: pong
[14:19] <mzanetti> mterry: so... I prepared a branch a while ago but there were some issues so I dropped it again
[14:19] <mterry> mzanetti, I found the problem -- the desktop file is inside ~/.local/share
[14:19] <mterry> mzanetti, oh?  I see data in AS for them
[14:20] <mhr3> mhall119, would also make sense to put the docs-extraction scripts somewhere on lp, so when things change, people can just update those
[14:20] <mzanetti> mterry: I think the issue is just that if the user changes the config in a running session it wouldn't sync it to the currently running instance or something
[14:20] <mzanetti> mterry: but its really a while ago. can't recall details
[14:20] <Cimi> pete-woods, only camera app does provide an infographics?
[14:20] <karni> Saviq: Can I join the meeting in 10"? (I am invited, just being polite ;D)
[14:21] <Cimi> where is this stored?
[14:21] <mterry> mzanetti, ah ok.  So perhaps a bit wonky.  But right now, no click apps are appearing, presumably because the desktop files aren't readable
[14:21] <mzanetti> mterry: yes... we shouldn't require to find the desktop files tho...
[14:21] <mzanetti> mterry: only on updates
[14:21] <mterry> The desktop files should be in XDG_GREETER_DATA_DIR
[14:22] <mzanetti> mterry: I think the plan was to have all info in accountsservice and not need to see the desktop files
[14:22] <mterry> mzanetti, oh...  OK.  So maybe it's something else.  There is a public icon and id here in AS
[14:22] <mhall119> mhr3: you mean https://code.launchpad.net/~api-website-devs/ubuntu-api-website/importers
[14:22] <mterry> mzanetti, I'll dig
[14:23] <mzanetti> mterry: thanks
[14:23] <mhr3> mhall119, indeed :)
[14:29] <karni> Saviq: is the product review meeting on mumble or hangout?
[14:50] <mterry> kgunn, I would add "locking greeter" to RTM list
[15:03] <Wellark> mzanetti: around?
[15:03] <mzanetti> Wellark: in a hangout
[15:03] <Wellark> ok
[15:03] <Wellark> mzanetti: could you ping me once you are available?
[15:04] <mzanetti> yes
[15:04] <Wellark> thanks!
[15:21] <mzanetti> Wellark: pong
[15:22] <kgunn> mterry: thanks
[15:22] <Wellark> mzanetti: pong^2
[15:22] <Wellark> mzanetti: having a conversation. will be with you in a minute
[15:22] <mzanetti> ack
[15:25] <didrocks> Saviq: hey, any idea btw why the unity8 crash on stop disappeared?
[15:26] <didrocks> (image 14)
[15:29] <Wellark> mzanetti: ok.
[15:29] <Wellark> hangout?
[15:29] <mzanetti> ok
[15:32] <Wellark> mzanetti: https://plus.google.com/hangouts/_/76cpinpe3g6sqvj8qi3dh5r9l0
[15:45] <paulliu> mzanetti: https://code.launchpad.net/~paulliu/unity8/fix-zoomableimage-test1/+merge/218649
[15:49] <mhr3> dpm, ping? is there a way to have lp push the translations as "pkgname.langcode.po"?
[16:04] <dpm> mhr3, there isn't sorry, langcode.po is what the standard gettext layout expects, and LP only supports that
[16:05] <dpm> mhr3, but you can have several templates per package
[16:05] <dpm> i.e.
[16:05] <dpm> pkgname1/template1.pot
[16:05] <dpm> pkgname2/template2.pot
[16:05] <dpm> and then the .po files would be committed under each template's dir, i.e.
[16:05] <dpm> pkgname1/template1.pot
[16:06] <dpm> pkgname1/ca.po
[16:06] <dpm> pkgname1/it.po
[16:06] <dpm> ...
[16:06] <mhr3> dpm, right, nevermind, i misread the cmake module
[16:06] <dpm> ok
[16:12] <mhr3> dpm, most annoying thing - there's a gettext macro shipped with cmake, but it runs msgmerge --update on the po files, which sorts the translations, and therefore might update them with each build
[16:14] <dpm> argh
[16:22] <mhr3> hm, launchpad seems to keep the order from the pot, so if i just regen the pot, it might be all great
[16:36] <Saviq> tooth--
[16:38] <dandrader> Saviq, the one in the far back of the jaw?
[16:38] <Saviq> dandrader, I didn't grow those, no
[16:38] <Saviq> N°6 is the winner here
[16:39] <Saviq> mterry, whole silo or just unity8?
[16:39] <Saviq> dandrader, phone images are on utopic, if you choose an utopic channel
[16:40] <Saviq> devel might not be linked to utopic yet indeed
[16:41] <dandrader> Saviq, yeah, how channels are named changed. I expected to use just utopic-proposed but it's now ubuntu-touch/utopic-proposed
[16:41] <Saviq> dandrader, right, there was an email about that
[16:41] <Saviq> I thought they were still aliases, though
[16:41] <dandrader> don't really read ubuntu phone mailing list. too high volume
[16:42] <Saviq> I know....
[16:42] <dandrader> was told about "ubuntu-device-flash --list-channels" quite interesting
[16:43] <dandrader> so "devel (alias to ubuntu-touch/utopic)"
[16:43] <dandrader> should we use ubuntu-touch/utopic or ubuntu-touch/utopic-proposed?
[16:45]  * greyback happy with 'ubuntu-device-flash --channel=devel-proposed'
[16:45] <greyback> dandrader: ^^
[16:45] <greyback> which gives you utopic-proposed right now
[16:45] <didrocks> Saviq: you probably didn't see my pings here (you will find out on the phone ML) :)
[16:46] <didrocks> Saviq: basically unity8 stopped to crash on stop from image #14. I don't know why and we didn't update unity-mir. Would be nice to figure out why…
[16:46] <Saviq> didrocks, just reading through the logs
[16:46] <dandrader> greyback, yeah, nice alias
[16:47] <Saviq> greyback, any idea for didrocks?
[16:47] <didrocks> other than "proposing my MP was enough, my code is so good that it didn't need to be released to fix the issue" :)
[16:48] <Saviq> dandrader, yeah, devel-proposed is best, it will only break around new distro openings
[16:49] <greyback> Saviq: didrocks: I skimmed the phone ML, is this the prob: bug 1315251  ?
[16:49] <didrocks> greyback: right, I guess that's the one
[16:49] <Saviq> greyback, the sudden lack of it, rather ;)
[16:49] <didrocks> yeah ;)
[16:50] <didrocks> the image diff is: http://people.canonical.com/~ogra/touch-image-stats/14.changes
[16:50] <greyback> didrocks: I'm mystified...
[16:51] <didrocks> ok, nothing obvious I'm missing :)
[16:51] <didrocks> greyback: and image #15 confirmed the crash is gone as told on the ML
[16:51] <didrocks> it's not just a one time thing
[16:51] <didrocks> lightdm changed its way of dealing with greeter
[16:51] <didrocks> so, maybe that helped
[16:52] <greyback> didrocks: well you'll see I've a branch ready to fix that very issue, so how it just went away on its own is a real mystery to me
[16:52] <greyback> maybe, not sure how, but maybe
[16:52] <didrocks> greyback: ok, no worry, I don't really like when that happens as most of the times, it's kicking us back in a worse shape, but if the real fix is coming, no issue
[16:55] <greyback> didrocks: sure
[16:56] <Cimi> Saviq, which unity-mir package version did you test the wizard?
[17:11] <mterry> Saviq, I meant the whole silo, but I found an issue with Unity8's syncing of launcher items, so don't bother yet
[17:13]  * greyback gone to cinema, maybe back in a few hours
[17:58] <josharenson> Is there a design doc that briefly explains the components in unity8? For example, what are scopes, dash, launcher, etc?
[19:03] <mterry> Saviq, still around?  If so, I fixed the launcher item syncing.  Could you kick a full build of silo 002 off?
[19:11] <Saviq> mterry, doing now
[19:12]  * Saviq is amazed what a bowl of soup and some ketoprofenum can do
[19:19] <mterry> Saviq, you feeling shitty?
[19:19] <mterry> I missed that
[19:19] <Saviq> mterry, not any more fortunately
[19:19] <Saviq> mterry, tooth--
[19:19] <mterry> Saviq, ah.  Eh, you got some to spare
[19:20] <Saviq> mterry, indeed, and I'll be 0.000001% cyborg soon ;)
[19:20] <mterry> he
[19:20] <Saviq> (POP goes the bonus...)
[19:20] <Saviq> ;)
[19:22] <mterry> :)
[19:28] <kgunn> no kidding dental is killer $
[19:28] <kgunn> dandrader: do you have a quick opinion on this one https://bugs.launchpad.net/platform-api/+bug/1317243
[19:29] <dandrader> kgunn, sounds fair
[19:31] <Saviq> kgunn, just commented, too
[19:32] <dandrader> kgunn, ah, you mean an answer to question in comment #1.
[19:33] <kgunn> dandrader: yeah, but seemed saviq agreed effectively...either apps gotta decide or you build in some tuning delay in platform-api (or lower)
[19:42] <mterry> How come tst_ZoomableImage.qml fails for me in trunk?
[19:43] <kgunn> it just doesn't like you
[19:43]  * mterry grumbles about not liking it either
[19:45] <dandrader> talking about rotation: in the future would't it be better if apps don't rotate themselves (so no need to listen directly to sensors unless they're a game or something)
[19:45] <dandrader> and they simply respond to a resize (from portrait to landscape and vice-versa)
[19:46] <dandrader> and the actual rotation being done by unity8
[20:14] <Saviq> dandrader|afk, that's actually something we decided against (but is apparently under discussion again)
[20:14] <Saviq> dandrader|afk, we wanted to let the apps be smart about reflowing when rotating, which meant letting them do the rotation themselves
[20:14] <Saviq> mterry, failed here, too, please file a bug and assign to Paul
[20:15] <Saviq> mterry, and I'll slap Albert on the wrist tomorrow
[20:15] <mterry> Saviq, I have quite a few failures actually.  Components/ZoomableImage, Dash/Dash, and Dash/Previews/PreviewZoomableImage
[20:16] <Saviq> mterry, confirmed, fallout of us not being able to trust CI probably :|
[20:16] <mterry> Saviq, I'm guessing the zommable ones are Paul's.  What about Dash/Dash?
[20:16] <Saviq> mterry, the last one is probably a result of the first one
[20:16] <Saviq> mterry, Albert
[20:17] <mterry> Saviq, OK, will file bugs
[20:17] <Saviq> mterry, and hopefully in a day or two we'll be on utopic for qmluitests
[20:18] <Saviq> mterry, actually https://code.launchpad.net/~paulliu/unity8/fix-zoomableimage-test1/+merge/218649
[20:20] <mterry> Saviq, sigh, just had pressed commit on that bug.  Will link bug to branch
[20:20] <Saviq> mterry, good anyway, it doesn't look like it fixes the PZI fail