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