=== cyphase_ is now known as cyphase | ||
Mirv | kgunn: yes sure I can skip more tests manually | 04:47 |
---|---|---|
Mirv | as long as the reason is understood like in those cases | 04:47 |
kgunn | ta Mirv | 05:03 |
=== shiznix_ is now known as shiznix | ||
tsdgeos | mzanetti: seen you broke qmluitest? | 08:39 |
mzanetti | tsdgeos: nope, not yet. will fix | 08:41 |
mzanetti | tsdgeos: fixed | 08:50 |
tsdgeos | k | 08:52 |
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:11 |
mzanetti | I guess it is | 09:12 |
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:20 |
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:21 |
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:22 |
Saviq | tsdgeos, as far as compilation goes... gotta build natively, there's no x-build capabilities in rtm at all :/ | 09:23 |
tsdgeos | mzanetti: fixed, but pushed? | 09:47 |
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:48 |
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:49 |
mzanetti | tsdgeos: now it should be better :) | 09:55 |
tsdgeos | correct | 09:58 |
=== dandrader is now known as dandrader|afk | ||
mzanetti | Cimi: fixed | 10:17 |
mzanetti | good catch btw | 10:17 |
tsdgeos | larsu: https://code.launchpad.net/~larsu/unity8/stop-using-statusicon/+merge/234502 | 10:26 |
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:35 |
Cimi | mzanetti, https://code.launchpad.net/~mzanetti/unity8/launcher-snap-after-drag/+merge/241679 ? | 10:39 |
larsu | tsdgeos: this is getting ridiculous | 10:46 |
larsu | and horribly inefficient | 10:49 |
=== dandrader|afk is now known as dandrader | ||
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:53 |
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:54 |
dandrader | mzanetti, the dash shows through while you rotate an app | 10:55 |
mzanetti | not here | 10:55 |
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:56 |
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:57 |
dandrader | mzanetti, you can also see a bit of the dash when switching between apps with different orientations | 10:58 |
mzanetti | I can't... | 10:58 |
greyback | possibly relevant: with an app open, dash is being drawn underneath it | 11:00 |
greyback | which is a bug | 11:00 |
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:01 |
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:02 |
Cimi | mzanetti, with the second comment for that branch, you still think we should not use else if_ | 11:10 |
Cimi | ? | 11:10 |
mzanetti | Cimi: doesn't really make a difference. But I added it. You do have a (theoretical) point. :) | 11:12 |
mzanetti | greyback: I just verfied it. The dash behind is only visible when the app is not at x==0 | 11:15 |
=== _salem is now known as salem_ | ||
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:15 |
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:16 |
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:17 | |
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:18 |
greyback | good, on same page | 11:19 |
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:20 |
mzanetti | dandrader: for example it looks crap if it has a trusted session on top | 11:21 |
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:22 |
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:23 |
mzanetti | I tend to agree the dash should be optimized away when not needed | 11:24 |
mzanetti | still transparent window surfaces has issues | 11:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
dandrader | mzanetti, yeah... | 11:30 |
=== Trevinho_ is now known as Trevinho | ||
=== MacSlow is now known as MacSlow|lunch | ||
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 | 11:54 |
mzanetti | yeah... we about 30 threads around now :D | 12:05 |
mzanetti | which does sound scary indeed | 12:05 |
tsdgeos | guys a quick one at https://code.launchpad.net/~aacid/unity8/undefined_warning_less/+merge/242061 ? | 12:08 |
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:19 |
=== alan_g is now known as alan_g|lunch | ||
Saviq | pstolowski, what's the deal with https://code.launchpad.net/~stolowski/unity-scopes-shell/feeds/+merge/239396 ? | 12:31 |
pstolowski | Saviq, it's done, forgot to change status, doing | 12:32 |
Saviq | pstolowski, ok thanks | 12:33 |
pstolowski | Saviq, btw, this should still only target vivid, correct? | 12:35 |
Saviq | pstolowski, yes | 12:35 |
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:36 |
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 | 12:37 |
=== dandrader is now known as dandrader|afk | ||
=== MacSlow|lunch is now known as MacSlow | ||
mzanetti | this is fun :) http://notyetthere.org/data/out-1.ogv | 13:40 |
mzanetti | greyback: ^ | 13:41 |
Saviq | mzanetti, fun indeed :) | 13:42 |
greyback | mzanetti: thought you'd enjoy it :) | 13:43 |
mzanetti | so far 20 mins of work :D | 13:43 |
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 | 13:44 |
=== alan_g|lunch is now known as alan_g | ||
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:28 |
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:29 |
tsdgeos | but i don't see where UNITY_SCOPES_LIST could be defined | 14:30 |
=== dandrader|afk is now known as dandrader | ||
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:31 |
Saviq | pstolowski, didn't we leave it around for the scope-tool registry? | 14:32 |
pstolowski | Saviq, no, for the scope tool I added UNITY_SCOPES_NO_FAVORITES flag | 14:33 |
tsdgeos | pstolowski: then why the difference? | 14:35 |
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:38 |
pstolowski | tsdgeos, /usr/share/glib-2.0/schemas/com.canonical.Unity.gschema.xml | 14:40 |
tsdgeos | somebody is doing some black magic somewhere | 14:41 |
tsdgeos | thtt file also defines only the 3 default scopes | 14:41 |
pstolowski | tsdgeos, ah right, there are overrides somewhere made by PS | 14:42 |
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:43 |
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:55 |
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:56 |
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:57 |
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:58 |
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 | 14:59 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
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:10 |
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:11 |
kgunn | i did....killer Saviq | 15:12 |
mzanetti | kgunn: this is a second video already, one step further | 15:13 |
mzanetti | maximize/minimize sort of working | 15:13 |
ChrisTownsend | mzanetti: Can't wait for that to land!:) | 15:20 |
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:21 |
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:26 |
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:27 |
tsdgeos | d | 15:28 |
tsdgeos | yeah need to investigate after the standup | 15:28 |
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:40 |
tsdgeos | moreAsyncDash$ bzr merge ../photoscopeimprovements/ | 15:41 |
tsdgeos | Nothing to do. | 15:41 |
Saviq | or something... | 15:41 |
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:42 |
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 | 15:43 |
tsdgeos | Mirv: any eta on https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1384776 ? | 16:29 |
ubot5 | Launchpad bug 1384776 in qtbase-opensource-src (Ubuntu) "Occasional hang in unity 8 dash on the phone" [High,New] | 16:29 |
elopio | is there a way to open unity on the desktop with the indicators working? | 16:47 |
elopio | initctl start unity8 gives me just something that looks like a background image. No real indicators. | 16:48 |
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:51 |
elopio | greyback: with that, I get a black screen after logging in. | 16:53 |
greyback | elopio: try with a new user account. mzanetti had a similar issue, and that fixed it for him | 16:54 |
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. | 16:57 |
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:00 |
balloons | mzanetti, oO what's that? | 17:02 |
mzanetti | balloons: it's working! that's what it is :D | 17:03 |
balloons | pretty sweet | 17:04 |
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:06 |
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:07 |
mzanetti | elopio: this is not landed yet | 17:08 |
elopio | ah | 17:08 |
mzanetti | elopio: atm you'd get the tablet mode | 17:08 |
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:09 |
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:10 |
elopio | greyback: I saw your queries about UPSTART_SESSION. Will try that later. Thanks. | 17:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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 | 17:21 |
=== alan_g is now known as alan_g|EOD | ||
=== boiko_ is now known as boiko | ||
=== salem_ is now known as _salem | ||
mzanetti | popey: can we upload amd64 clicks to the store yet? | 21:24 |
popey | mzanetti: yeah, we have always been able to | 21:32 |
mzanetti | where does unity7 store window state information? | 22:02 |
mzanetti | like last open position/size etc | 22:02 |
greyback_ | mzanetti: often apps themselves save that data, and request position/size on startup. | 22:12 |
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:13 |
greyback_ | we've a lot of plumbing to do still | 22:14 |
thetoxicarcade | hello all :D is this the old unity or the new unity as in broken lxc container unity | 22:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!