=== cyphase_ is now known as cyphase [04:47] kgunn: yes sure I can skip more tests manually [04:47] as long as the reason is understood like in those cases [05:03] ta Mirv === shiznix_ is now known as shiznix [08:39] mzanetti: seen you broke qmluitest? [08:41] tsdgeos: nope, not yet. will fix [08:50] tsdgeos: fixed [08:52] k [09:11] tsdgeos: re "Yes, it will break when someone has #111111 has background color, but i guess it's less common than black" [09:11] tsdgeos: there's still a black dropshadow around... [09:11] not sure if that's visible enough though. [09:12] I guess it is [09:20] mzanetti, hey! stop throwing bugs at me and help me with shellRotation instead! :P [09:20] dandrader: you broke it [09:20] you fix it [09:20] :P [09:21] Saviq: so what's the suggested way to compile stuff for rtm now that vivid doesn't compile in rtm? diff the branch to master and manually apply that patch? or? [09:22] tsdgeos, to build the branch I usually merge onto trunk and then merge -c onto rtm [09:22] tsdgeos, that's how I build the staging rtm branch [09:22] okki [09:23] tsdgeos, as far as compilation goes... gotta build natively, there's no x-build capabilities in rtm at all :/ [09:47] mzanetti: fixed, but pushed? [09:48] tsdgeos: hmm... it says there's nothing more to push [09:48] maybe we're talking about different branches :D [09:48] i'm talking about https://code.launchpad.net/~mzanetti/unity8/fix-appdelegate-jumping/+merge/241930 [09:48] interesting [09:49] yeah, I did fix that, but indeed the push doesn't show up in LP [09:49] but my local copy says nothing more to push [09:49] wondering where this got lost [09:49] doesn't show in my branch [09:49] either [09:49] so it's not there [09:49] you sure you pushed to that branch and not somewhere else? [09:49] pushed to wrong branch :/ [09:55] tsdgeos: now it should be better :) [09:58] correct === dandrader is now known as dandrader|afk [10:17] Cimi: fixed [10:17] good catch btw [10:26] larsu: https://code.launchpad.net/~larsu/unity8/stop-using-statusicon/+merge/234502 [10:35] dandrader|afk: fixed the flickering by reverting changes from line 1842 to 1859 [10:35] dandrader|afk: although I guess there was a reason why you did that. not really sure what though [10:39] mzanetti, https://code.launchpad.net/~mzanetti/unity8/launcher-snap-after-drag/+merge/241679 ? [10:46] tsdgeos: this is getting ridiculous [10:49] and horribly inefficient === dandrader|afk is now known as dandrader [10:53] mzanetti, could you point me to the line numbers in PhoneStage.qml? [10:53] I guess those are from the web diff or the whole thing, right? [10:54] mzanetti, yes it fixes the flicker but makes the rotation animation horrible [10:54] dandrader: https://code.launchpad.net/~unity-team/unity8/shellRotation/+merge/241952 [10:54] dandrader: I don't see a difference in the rotation animation [10:55] mzanetti, the dash shows through while you rotate an app [10:55] not here [10:56] mzanetti, have you tried it on the device? [10:56] yes [10:56] dandrader: define "shows through" [10:56] mzanetti, btw, it's very hard to find inline comments in such a big diff [10:57] dandrader: there's a button that scrolls you to the diff [10:57] ah no [10:57] ok.. well [10:57] mzanetti, when rotatting, the opacity of the app is animated, so it gets translucent. since the dash is always behind it, you end up seeing it as well [10:57] dandrader: I can't see it when rotating the settings app [10:57] dandrader: it might depend on the color of the app then [10:58] mzanetti, you can also see a bit of the dash when switching between apps with different orientations [10:58] I can't... [11:00] possibly relevant: with an app open, dash is being drawn underneath it [11:00] which is a bug [11:01] mzanetti, it's not just me. that was the reason of commits 1449 and 1450. reverting that as you suggested caused the bug in row 16 [11:01] greyback, yes, that's what I was trying to fix. fixing had the side-benefit I was looking for which is dash not showing up in rotation animations [11:02] gotcha [11:02] in any case, it's too much hidden now [11:02] greyback, currently it would be just an optimization, but with the rotation animations it turns into a bug fix [11:02] and I still can't see it in while rotating [11:10] mzanetti, with the second comment for that branch, you still think we should not use else if_ [11:10] ? [11:12] Cimi: doesn't really make a difference. But I added it. You do have a (theoretical) point. :) [11:15] greyback: I just verfied it. The dash behind is only visible when the app is not at x==0 === _salem is now known as salem_ [11:15] which is something we need [11:15] mzanetti: with trunk? I can repro it with trunk easily, just launching an app with transparency [11:16] hmm... yeah, with trunk. using the overdraw visualizer [11:16] greyback: it appears when I drag it aside, disappears when it's animated back [11:17] greyback: ah oh... no... that's the dropshadow of the app [11:17] greyback: it's there indeed [11:17] mzanetti, just reverted my buggy dash visibility optimization once again and I can see the dash when rotating system settings [11:17] dandrader: did you just revert those lines (the visible property) or did you revert the whole commits? [11:17] mzanetti, make sure you have just system settings and unity8-dash in the spread [11:17] ah ok... [11:17] * mzanetti tries [11:18] mzanetti, if you switch from some other app to system setting and then rotate you won't see the dash indeed [11:18] dandrader: right... now I can see it too [11:19] good, on same page [11:20] dandrader: so I guess for the rotation animation, the fix would not to make it transparent but to put a black overlay on top [11:20] dandrader: I have the same issue in the spread in some other place. making app surfaces transparent mostly causes nasty stuff [11:21] dandrader: for example it looks crap if it has a trusted session on top [11:22] to repro, open an app with a trusted session and use a right edge drag to move it a bit to the left. that'll make it transparent and look ugly. I've still to fix that [11:22] so we should not make ApplicationWindows tansparent ever I'd say [11:23] mzanetti, yes. wedging a black rectangle does solve it but I was hoping for the "optimization" solution as it would lead to hopefully a simpler scene and more efficient scene and code [11:23] mzanetti, but I will do it if you say so [11:23] mzanetti, you're the PhoneStage man after all :) [11:23] yeah, that's the next thing... but I'd say unrelated [11:24] I tend to agree the dash should be optimized away when not needed [11:24] still transparent window surfaces has issues [11:25] greyback: what did you mean with transparent app? [11:25] greyback: an app with backgroundColor: "transparent" ? [11:25] mzanetti: an app whose surface is not opaque [11:25] there are different ways of doing that [11:25] yep, it's not forbidden - yet [11:25] Hola! [11:25] I was testing pure GL apps [11:26] which often do not set a background colour [11:26] greyback: ok. so if we allow setting an app transparent, wouldn't you expect the dash to shine through? [11:26] mzanetti: no [11:26] after all it's there when you move the app to the left [11:26] so you'd expect the dash to magically appear when you start dragging from left to right? [11:26] it's an app, why is dash visible? [11:26] because the dash is transparent :P [11:27] and if you drag the app to the side, the dash is there [11:27] sure. I'm not saying what we're making the dash do is wholly sensible [11:27] our stages stuff is made in a way that apps don't disappear out of nowhere, but rather are somewhere and are moved around [11:27] I am saying that if an app with transparency is started, and the dash is drawn underneath, it's hard to see the app [11:28] yeah well, if you want to have the app readable, don't make it transparent [11:28] but if you want to make a transparent app? [11:28] mzanetti: it's not my app [11:28] for example that screen crack apps [11:29] ultimately we won't allow most apps to use transparency on the phablet [11:29] mzanetti, actually, the rotation animation changes the opacity of the entire Shell.qml [11:29] but for now, I consider it unnecessary to draw the dash underneath the focsued app [11:29] dandrader: which will cause the said issues with trusted sessions though [11:30] mzanetti, yeah... === Trevinho_ is now known as Trevinho === MacSlow is now known as MacSlow|lunch [11:54] QObject: Cannot create children for a parent that is in a different thread. [11:54] (Parent is QNetworkAccessManager(0x1203ccc), parent's thread is QThread(0xf48500), current thread is QThread(0x1196028) [11:54] too many of those [11:54] makes me scared [12:05] yeah... we about 30 threads around now :D [12:05] which does sound scary indeed [12:08] guys a quick one at https://code.launchpad.net/~aacid/unity8/undefined_warning_less/+merge/242061 ? [12:19] tsdgeos, as you're chasing warnings, could you chase down the implicitHeight binding loop in card delegates maybe? [12:19] ;) [12:19] i'm not chasing warnnings, just fixed an eassy one [12:19] ok :) === alan_g is now known as alan_g|lunch [12:31] pstolowski, what's the deal with https://code.launchpad.net/~stolowski/unity-scopes-shell/feeds/+merge/239396 ? [12:32] Saviq, it's done, forgot to change status, doing [12:33] pstolowski, ok thanks [12:35] Saviq, btw, this should still only target vivid, correct? [12:35] pstolowski, yes [12:36] pstolowski: how do i reset scopes to be the default set of scopes? can i do that by removing/editing some file in $HOME? [12:36] tsdgeos, dconf key, 1 moment [12:37] tsdgeos, gsettings reset com.canonical.unity.Scopes something [12:37] gsettings reset com.canonical.Unity.Dash favorite-scopes [12:37] tsdgeos, ↑ [12:37] yep [12:37] tx === dandrader is now known as dandrader|afk === MacSlow|lunch is now known as MacSlow [13:40] this is fun :) http://notyetthere.org/data/out-1.ogv [13:41] greyback: ^ [13:42] mzanetti, fun indeed :) [13:43] mzanetti: thought you'd enjoy it :) [13:43] so far 20 mins of work :D [13:44] did I ever say that I love QML? [13:44] IMO it's perfect for this kind of job [13:44] yeah === alan_g|lunch is now known as alan_g [14:28] pstolowski: Saviq: any idea why launching unity8-dash from upstart gives me a different set of scopes than if by command line? [14:28] tsdgeos, huh? [14:28] Saviq: on the phone, with upstart i get all the scopes [14:28] tsdgeos, I don't think there's any envvar that could affect it any more... [14:28] ./builddir/src/Dash/unity8-dash --desktop_file_hint=/usr/share/applications/unity8-dash.desktop [14:28] gives me three [14:29] tsdgeos, try comparing environ of the two? [14:29] right [14:29] tsdgeos, hmm looking at data/unity8-dash.conf [14:29] if [ -z "$UNITY_SCOPES_LIST" ]; then [14:29] # FIXME: remove once we have this in dconf [14:29] initctl set-env UNITY_SCOPES_LIST="clickscope;musicaggregator;videoaggregator" [14:29] fi [14:29] yeah [14:30] but i don't see where UNITY_SCOPES_LIST could be defined === dandrader|afk is now known as dandrader [14:31] environ is UNITY_SCOPES_LIST=clickscope;musicaggregator;videoaggregatoranyway [14:31] tsdgeos, yeah, just checked, same here, I've a feeling that's a bug in unity-scopes-shell [14:31] hmm this list shouldn't have any effect afaict [14:32] pstolowski, didn't we leave it around for the scope-tool registry? [14:33] Saviq, no, for the scope tool I added UNITY_SCOPES_NO_FAVORITES flag [14:35] pstolowski: then why the difference? [14:38] tsdgeos, any chance it's picking a customised value of the dconf key in one case and system-wide default value in the other? [14:38] pstolowski: maybe [14:38] where's the system-wide default stored? [14:40] tsdgeos, /usr/share/glib-2.0/schemas/com.canonical.Unity.gschema.xml [14:41] somebody is doing some black magic somewhere [14:41] thtt file also defines only the 3 default scopes [14:42] tsdgeos, ah right, there are overrides somewhere made by PS [14:43] anyway, i did [14:43] /sbin/initctl start unity8-dash BINARY="`readlink -f ./builddir/src/Dash/unity8-dash`" [14:43] and i get all the scopes now [14:43] that's enough for me at this point [14:55] seb128: would you know: I'm playing with unity8 on desktop a lot these days. One thing I don't understand is how it's launched (by gnome-session I guess), and how I could prevent it being launched so I can run it manually [14:55] moar goodness, now with minimize/maximize and pretty window decorations: http://notyetthere.org/data/desktopstage.ogv [14:56] and dropshadow :) [14:56] seb128: I think back in the unity2d days, there was a file I could edit to disable autolaunch/autorelaunch of unity2d. Then I could kill unity2d and launch manually [14:56] greyback, sessions are a bit of a mix of gnome-session and upstart jobs [14:57] greyback: I'd suggest I hook that up to Shell.qml in a way it won't be loaded on phone/tablet but so that it will be loaded when running the desktop session and get it landed so people can start playing around and figure next steps. wdyt? [14:58] I mean, we won't implement the whole thing at once anyways and for the desktop its already now better than the tabletstage [14:59] Saviq: wdyt? We'd be landing kinda raw code for a while? [14:59] first I'm gonna test it with the proper desktop session obviously and make sure you can interact properly with the app surfaces [15:00] seb128: upstart jobs I know how to play with. But I'm not so good with gnome-session stuff. Any tips on stopping unity8 being respawned? [15:00] greyback, mzanetti, how do we differentiate between phone and not-phone? [15:00] greyback, "stop unity8" [15:00] Saviq: not exactly sure yet [15:00] so far we distinguish by size between tablet and phone [15:00] Saviq: until we know better, an env var? [15:00] I guess env var in the session is what I'd go for too [15:01] greyback, if you stop unity8 the session is going on happily [15:01] greyback, as it's not "PID 1" of the session [15:01] Saviq: that's upstart. On desktop, there is no such upstarts ession [15:01] greyback, of course there is [15:01] greyback, you just don't get UPSTART_SESSION in your terminal [15:02] Saviq: yes I have: http://pastebin.ubuntu.com/9073338/ [15:02] greyback, no [15:02] greyback, that's init [15:02] PID 1 [15:03] greyback, initctl defaults to the system upstart if UPSTART_SESSION is unset [15:03] ah that it news to me [15:03] greyback, you can pick up UPSTART_SESSION from unity8's environ [15:04] Saviq: ok done, thanks [15:04] but ideally you'd get the same behaviour you get on the phone (or not get that behaviour on the phone...) [15:04] I thought gnome-session was managing unity8 [15:05] but you're right, pstree showed me [15:05] greyback, what Saviq said [15:05] seb128: thanks :) [15:05] greyback, export `grep -z ^UPSTART_SESSION= /proc/$(pidof unity8)/environ`" [15:05] greyback, you can use that as an alias or in your profile or something [15:06] to set the upstart session env [15:06] already done [15:06] k [15:06] sorry I was looking in my log for th einfo [15:06] while Saviq was replying ;-) [15:10] mzanetti, /me loves, this sh!t just validates our approach so much :) [15:10] yeah... this is sooo amazingly fun atm [15:10] wanna shell? here :P [15:10] yeah :D [15:11] ok. gonna log off and log into the mir-unity8-desktop session now. I hope I'll be back by the standup [15:11] kgunn, did you see http://notyetthere.org/data/desktopstage.ogv ? [15:12] i did....killer Saviq [15:13] kgunn: this is a second video already, one step further [15:13] maximize/minimize sort of working [15:20] mzanetti: Can't wait for that to land!:) [15:21] ChrisTownsend: same here. note that there is *a lot* of stuff missing still... but hey, for 2 hours of work I guess not too bad so far [15:21] mzanetti: Yeah, but still awesome and in 2 hours, that's amazing. [15:26] tsdgeos, moreAsyncDash conflicts in croppedimagesizer.{h,cpp}, think it makes sense to rebase on asyncImageSizer? [15:26] Saviq: don't take it into account for the moment [15:27] i just discovered a way to make it use 100% of the CPU ^_^ [15:27] need to find out why [15:27] tsdgeos, ok [15:27] well actually now that i realize it may not be it but some of the parent merges [15:27] brrr [15:27] that'd be ba [15:28] d [15:28] yeah need to investigate after the standup [15:40] Saviq: but moreAsyncDash has no changes at all on those files ?¿?¿ [15:40] tsdgeos, yeah, you need to remerge photoscopeimprovements into it probably [15:41] moreAsyncDash$ bzr merge ../photoscopeimprovements/ [15:41] Nothing to do. [15:41] or something... [15:42] tsdgeos, does that conflict http://paste.ubuntu.com/9073872/ explain anything? [15:42] tsdgeos, or maybe my staging doesn't have everything actually [15:42] probably that [15:42] i did change those names [15:42] but i think i propagated the merges everywhere [15:43] tsdgeos, yeah, I've a local staging branch that I probably did not merge into, sorry for the noise [15:43] that's ok [16:29] Mirv: any eta on https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1384776 ? [16:29] Launchpad bug 1384776 in qtbase-opensource-src (Ubuntu) "Occasional hang in unity 8 dash on the phone" [High,New] [16:47] is there a way to open unity on the desktop with the indicators working? [16:48] initctl start unity8 gives me just something that looks like a background image. No real indicators. [16:51] elopio: you have unity8-desktop-session-mir installed? [16:51] if you use lightdm to log into a proper unity8 session, the indicators should come up fine [16:53] greyback: with that, I get a black screen after logging in. [16:54] elopio: try with a new user account. mzanetti had a similar issue, and that fixed it for him [16:57] yeah... for some reason my work account doesn't bring it up. works fine with my private account [16:57] right, now it works. [17:00] greyback: mzanetti: now, what I need is to introspect the indicator-messaging with the autopilot vis. I don't think I will be able to do that from the u8 session. [17:00] greyback: Saviq: it's gettin real: http://notyetthere.org/data/unity8-desktop-mode-on-mir.mp4 [17:02] mzanetti, oO what's that? [17:03] balloons: it's working! that's what it is :D [17:04] pretty sweet [17:06] elopio: sure, but I think the first step is to get unity8+indicators working normally. Then you can control unity8 like on the phone (you need to set UPSTART_SESSION first though, scroll up as I had that query earlier today) [17:06] mzanetti: looks good [17:06] mzanetti, can I use mir in the lxc container? [17:07] dunno... I ran it on a second session [17:07] it freezes when I play around with the indicators [17:07] mzanetti: I didn't get the scopes window. [17:07] mzanetti: observations: you are resizing the QQuickItem, but it takes 2 frames until the the application has rendered a new frame at the desired size - and in the mean time we scale the old frames. [17:08] elopio: this is not landed yet [17:08] ah [17:08] elopio: atm you'd get the tablet mode [17:09] mzanetti: I think it's worth playing with a resize(width, height) method on the MirSurfaceItem, and the width/height is tied directly to the actual frame size [17:09] so it only gets resized when the client has drawn at the desired new size [17:09] see what I mean? [17:09] greyback: not exactly sure... [17:10] greyback: but yeah, right now it's just bound to the window's size [17:10] mzanetti: it's mainly due to Mir's triple buffering for clients. When we ask client to draw at new buffer size, it can take a frame or 2 until shell gets that resized buffer to render [17:11] greyback: I saw your queries about UPSTART_SESSION. Will try that later. Thanks. [17:12] greyback: ah, now I understood what you mean [17:12] greyback: I'd leave that for another branch though [17:12] mzanetti: I want to see this in your next video: http://www.phoronix.com/scan.php?page=news_item&px=MTg0MzU [17:12] mzanetti: ofc [17:13] greyback: I'd say as a first step I'd try to get this now landed as is so we can all start building on top [17:13] these are tricky things, but for pixel perfect frames, something we'll have to worry about eventually [17:13] definitely [17:14] greyback: in the video you can see that sometimes I try to scroll but it's not working [17:14] I think that's because the app is still waking up from suspended [17:14] it only happens directly after focusing an app [17:14] mzanetti: yep, phablet lifecycle totally unsuited for this. [17:15] but hey, really didn't think I'd get this far today [17:15] really proves qtmir works [17:15] yep [17:16] the hard bit is getting behaviours right, focus, window placement, workspaces... [17:16] greyback: re video on phoronix: gimme a minute :D [17:17] I like their launcher [17:17] but they don't use multi-touch much [17:17] yeah, that blue thingie might be a bit of work [17:17] but for app surfaces rotating etc, we're pretty much there [17:17] has a lovely animation [17:17] yeah I've a demo which does that, easy [17:18] the fact that indicators freezes the whole shell is nasty... [17:18] do they? [17:18] not on my unity8 on desktop [17:18] yeah, touched them twice so far, after about 5 secs of playing with them it freezes reliably [17:19] might be something with my environment [17:19] like I have a bazillion wifi's in range here [17:19] battery makes it hang for 1-2 seconds [17:21] greyback: and that nemo shell needs at least 1 thing to "make it square" in 1 touch... [17:21] the off kilter windows look cute for a demo...but would quickly piss me off [17:21] kgunn: right. It's fun for a demo - or a multi-user UI - but yeah, the freedom is nutty === alan_g is now known as alan_g|EOD === boiko_ is now known as boiko === salem_ is now known as _salem [21:24] popey: can we upload amd64 clicks to the store yet? [21:32] mzanetti: yeah, we have always been able to [22:02] where does unity7 store window state information? [22:02] like last open position/size etc [22:12] mzanetti: often apps themselves save that data, and request position/size on startup. [22:13] greyback_: I see... I guess we don't have anything like that in place yet [22:13] but I don't know where compiz saves any such data [22:13] mzanetti: nope not yet [22:14] we've a lot of plumbing to do still [22:18] hello all :D is this the old unity or the new unity as in broken lxc container unity