=== cute is now known as EphraimB [08:28] Saviq: in https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1511072 you linked the bug to itseldf [08:28] Launchpad bug 1511072 in unity8 (Ubuntu) "Language selector scrolling performance is poor in welcome wizard" [Medium,Triaged] [08:49] tsdgeos, oops [08:54] frozen scopes :/ https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1511063 [08:54] Launchpad bug 1511063 in unity8 (Ubuntu) "Scopes freeze after few times slide on Bq 4.5" [Undecided,New] [08:56] Saviq: we did disable the crash generation on ota7 right? so this can't be a "it's crashing but getting the info", no? [08:57] tsdgeos, well, it's disabled by default, but doesn't mean people can't enable it [08:58] right [09:04] Saviq: would that be the "App crashes and errors" in System Settings->Diagnostics? [10:07] tsdgeos, power back up? and yes, that'd be that setting [10:07] Saviq: yep, poewr back up [10:07] tsdgeos, I just realized something... we should probably update the dash header to match uitk 1.3? [10:08] hmm or can we [10:08] and the splash header, thought we were using UITK there... [10:09] Saviq: it's done on the sdk13 branches [10:10] hmm hmm [10:10] tsdgeos, I've silo 21, with both sdk13 and qtquick24 branches, both dash and the default splash screen have the thick header bar [10:10] in dash I don't think we can get rid of it straight away because we have the horizontal pills there [10:11] ah the thick bar is different too? [10:11] i checked the height is smaller [10:11] didn't realize the thick bar changed [10:11] yeah it's gone [10:11] it's weird the splash screen doesn't adjust though [10:11] since we actually use the sdk thing in there [10:11] splash is also higher [10:12] so we must be doing something to it [10:12] tsdgeos, anyway, next landing, won't block that silo for it [10:12] oki [10:12] but we can't say we have that bug fixed when that lands [10:12] Saviq, just noticed on latest image, open contacts and messaging (and other apps) the splash is inconsistent with the app. See http://people.canonical.com/~alan/screenshots/device-2015-10-29-101145.png vs http://people.canonical.com/~alan/screenshots/device-2015-10-29-101200.png [10:12] is that known? [10:13] popey, bug #1508363 [10:13] bug 1508363 in unity8 (Ubuntu) "Coordinated migration to UITK 1.3" [High,In progress] https://launchpad.net/bugs/1508363 [10:13] popey, workin' on it [10:13] okay [10:15] cimi, looks like the new shape branch added an overlay background to the store card https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d#//screenshot20151029_111418354.png [10:15] that cleared with design? [10:15] Saviq, let me see [10:16] Saviq, nope that's new [10:16] not intended [10:17] * cimi investigates [10:19] Saviq, hey, I've a fix for the issue that kgunn found (windows storage saves 0,0,0,0) [10:19] should I propose a new branch or push it to panel-button-fixes? [10:20] mzanetti, push [10:20] ack [10:20] mzanetti, or well, [10:20] :) [10:20] mzanetti, depends where it fits ;) [10:20] mzanetti, we'll have a u8 rebuild in silo 21 for sure [10:20] yes, it does fit there [10:20] question was really how the silo state is [10:21] ok. just running some tests and will push in a minute [10:24] cimi, did design ack https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d# ? that's full-width video on tablet [10:26] Saviq, I think the ubuntu store might specify overlay color but never worked? :) [10:26] cimi, it specifies one with 0 alpha IIRC [10:26] cimi, to get around it [10:26] ah ok let me see [10:27] cimi, anywhere I can try preview sharing? [10:27] Saviq, there are no scopes done I think [10:27] Saviq, I'd like to have one too so we can see it live [10:28] cimi, tryPreview works, at least? [10:28] mmm either that or previewSharing [10:28] ack [10:28] don't remember let me see [10:29] yeah PreviewSharing [10:30] doesn't look like much... pstolowski, on that note, how do scopes know if a feature like preview sharing is supported? or is it ok because if it isn't, we just ignore it? [10:30] (I mean in different versions of the dash) === nudtrobert1 is now known as nudtrobert [10:32] tsdgeos, ok, so since we'll need a rebuild anyway, can I ask you to make the splash screen use new header? [10:32] Saviq: yes, having a look [10:32] Saviq, they don't know it. if it not available, shell will just ignore unknown attributes. in general you're expected to be running up-to-date phone i guess [10:33] Saviq, I am just using UbuntuShapeOverlay with overlayColor: cardData["overlayColor"], while before we were reading overlayColor.r,g,b,a [10:33] pstolowski, as long as they work... [10:33] Saviq, might be something in UITK [10:33] or I can workaround with opacity: cardData["overlayColor"].a MAYBE [10:34] pstolowski, what I mean is, when we introduce an incompatible change, we can't let scopes use it until a new framework is defined [10:34] pstolowski, otherwise you can install a scope that won't work [10:35] Saviq, pushed [10:35] mzanetti, ack, tx [10:35] mzanetti, +test? [10:35] Saviq, yes, absolutely [10:36] pstolowski, so long as older phones will just ignore it, fine [10:36] pstolowski, but before we make any changes like that public, we need to determine what's what [10:38] Saviq, yes, added atest too [10:38] mzanetti, great [10:39] cimi, if you can, please do, but find out what's going on and check if/file a bug in uitk [10:39] Saviq, for overlay right? no focus thingy [10:41] cimi, yes [10:44] mzanetti, when you close an app, focus not going to the next window is known, right? [10:45] hmm... not really... need to check if ltinkl has that fixed, he was mocking around with focus [10:45] reboot [10:46] no external screen either, just messing about with maximizing dash in windowed mode [10:48] mzanetti, noticed, also, that minimize clears the maximize state [10:49] mzanetti, i.e. maximize → minimize → launcher should be maximized, but is restored [10:49] really [10:49] that was intentional [10:49] ah no [10:49] that was with close in between [10:49] yes launcher always restores so far [10:49] still, maximize should be stored along with geometry on close, IMO [10:50] until you restore manually, it should always be maximized [10:51] hmm... indeed [10:51] Saviq, ack, will fix, but in a new branch [10:51] mzanetti, sure [10:54] dandrader, any pointer on testing the upsidedown fix? is there no bug for it? [10:56] Saviq, this is actually a bug fix [10:56] dandrader, I know, just wondering how to test it fixes ;) [10:56] Saviq, bug description should say it [10:56] * dandrader looks [10:57] right, bug not linked [10:57] ah bug #1478637 [10:57] bug 1478637 in unity8 (Ubuntu) "X-Ubuntu-Supported-Orientations=landscape causes app to be upside down on devices with nativeOrientation=landscape" [Undecided,In progress] https://launchpad.net/bugs/1478637 [10:57] dandrader, ↑ [10:57] it was linked to the superseded branch [10:58] Saviq, that's the one [10:58] Saviq, and Nexus 7 is the device [10:58] yup [11:01] Saviq, fixed the bug title [11:01] dandrader, yeah, Josh's branch doesn't fix the bug, though, I wonder if the fix for rotating external screen causes that [11:02] Saviq, the bug when focus is lost when you either minimize or close an app is fixed in my branch [11:02] Saviq, or should be :) [11:02] ltinkl, ack [11:03] Saviq, wonderful :). bitrotting at its best [11:03] Saviq, looking into it [11:03] Saviq, also when you focus/activate a minimized window from the spread [11:04] kk [11:08] dandrader, fix for desktop doesn't matter, it's as if the branch didn't really change anything, landscape apps always go to Landscape, not InvertedLandscape [11:08] dandrader, except the power-button workaround no longer works, either ;) [11:09] dandrader, FWIW the branch is waiting for your vote anyway, since it was resubmitted https://code.launchpad.net/~unity-team/unity8/new_fix_upsidedown/+merge/275683 [11:09] Saviq, I don't get it. this bug fixes an issue that appears exclusively on the nexus 7 builtin display [11:09] dandrader, oh and yeah, card for tests for this is good [11:09] dandrader, yes [11:09] Saviq, when you are on tablet stage [11:10] dandrader, yeah, ignore my "desktop" comment, doesn't really bring anything into the discussion [11:10] was just grasping at straws [11:13] dednick, how can I verify bug #1475678? [11:13] bug 1475678 in unity8 (Ubuntu) "Unity8 not informing clients that they are not visible and thus can stop rendering" [High,In progress] https://launchpad.net/bugs/1475678 [11:13] Saviq: ok, it's not as trivial as i thought, there's a PageHeadStyle.qml "copied with large modifications from Ubuntu UI Toolkit's Ambiance's theme" in our source code [11:14] tsdgeos, sounds about right [11:14] Saviq: erm, kinda a pain to do. i did it by logging when the client switched buffers [11:14] Saviq: so i'm going to work on it but may still want to land it since maybe i don't get it done today :D [11:14] but need to modify code [11:14] tsdgeos, waiting for a few other bits, so we'll see [11:15] dednick, wonder if I could get scenegraph to tell me in a small qml app [11:16] greyback_, how difficult to turn on scenegraph logging? [11:16] greyback_, to test whether it's rendering or not (thinking occlusion here) [11:16] Saviq: oh, yeah probably can [11:16] should just be a env var [11:17] QSG_RENDERER_DEBUG=render [11:17] let's try tha [11:17] t [11:17] Saviq: QSG_VISUALIZE=changes can go nice visual [11:17] greyback_, well, I've to put the app in the back ;) [11:18] Saviq: ah, I hadn't read up [11:18] yeah, QSG_RENDER_TIMING=1 is similar [11:19] ok, worky [11:20] mzanetti, /me has a worry about mterry's isTouchApp... if we start displaying non-touch apps in launcher/dash unconditionally, dropping that line from the .desktop file will get your app around lifecycle [11:21] Saviq, well would also not allow to launch it in staged mode, no? [11:22] just display a message that this app can only be used in with external screen etc [11:23] but I see your concern, yes. will talk with mike about it when he comes on [11:23] tx [11:26] when you use PropertyChanges and a Transition to animate a value change in a state, does the property always change to its final value before starting the animation? ie changing from 0 -> 10 goes: 10, 0, 1, 2, 3...10 [11:27] mzanetti: ^ ? [11:27] I've seen that before too... [11:28] but don't remember what it was. I think I had been fiddling with the order of transitions/propertyactions [11:28] it's not always like that, but easy to get into that state [11:33] dednick, sounds wrong [11:34] mzanetti, one more thing came to mind... what happens in unity8-desktop-session-mir... if we stop filtering on touch, we'll show all .desktop files, and they won't run [11:35] Saviq, shouldn't they run eventually? [11:36] mzanetti, maybe, eventually, not in the PD timeframe ;) [11:36] Saviq, well, the only thing we can do there is to add yet another key like: X-Ubuntu-Touch-Legacy [11:36] and filter on both [11:37] so the ones we support already would need to be patched for this key [11:37] mzanetti, yeah I'm starting to think we'll need that [11:37] mzanetti, well, that defaults to false, which means we don't need to change, we only need to add to new, legacy apps [11:37] yes [11:37] mess : [11:37] :/ [11:38] but what can you do [11:38] yes... not sure if it's worth it tbh [11:38] is unity8-desktop-session-mir something we officially support for endusers? [11:38] it definitely is worth it, otherwise people who install desktop session will get all the apps that they can't run [11:38] people don't ask ;) [11:38] but will complain [11:43] Saviq: pushed something that looks quite good to me, can you have a look? [11:43] code is still not totally optimal as there's some copied stuff but much less than before [11:44] tsdgeos, ack [11:46] ok, time for a rebuild [11:47] tsdgeos, looks fine IMO [11:47] tsdgeos, got a conflict in the removal of PageHeadStyle.qml, but that's likely bzr being dumb again, silo should be fine [11:48] Saviq: sorry i forgot to push use_quick_24 [11:48] i had merged it in there since otherwise there's a "you changed this file that is now removed" conflict [12:09] tsdgeos, well, silo built fine so you made it in time [12:09] tsdgeos, was conflict for me because I merged on top of quick_24 [12:10] k === dandrader is now known as dandrader|afk [12:17] any ideas who to blame when with scale factor 2 the external-monitor-only display mode is corrupted, this is in both vivid & wily at least [12:18] only the top-left part of screen is normal, then moving windows around leave traces on rest of desktop [12:19] I've only intel gfx to test with [12:20] so is it compiz/unity or intel dri driver, or.. [12:23] bregma: any ideas for tjaalton? [12:24] the laptop panel needs to have scale factor 2, external 1 [12:25] any scale factor >= 2 will cause weird and bizarre problems in any GTK-based software [12:25] oh [12:25] is that documented somewhere? [12:25] and why is it selectable :) [12:25] some oem projects use that as the default... [12:25] on some models [12:25] which is also a trigger for some crashers it seems [12:26] I believe I may have opeened bugs somewhere a few years ago [12:26] it first manifested as running videos "full screen" in totoem would only be a quarter of the screen [12:26] I'm not sure where in the stack any of that happens [12:26] maybe Trevinho has an idea [12:27] tjaalton: it's nautilus issue [12:27] tjaalton: kill it and reload, it should fix it. [12:27] seb128: ^ [12:28] Trevinho: ah [12:32] Trevinho, tjaalton, see #ubuntu-desktop backlog from 9:57 utc [12:33] seb128: hehe, what a coincidence :) [12:34] tjaalton, or same people applying nag on different groups ;-) [12:34] that too [12:46] greyback_, what editor do you use? [12:47] mterry: QtCreator mostly [12:47] hmph [12:48] mterry: since you understand the problem, could you look at https://code.launchpad.net/~unity-team/qtmir/1510571.ms-timestamp-compression/+merge/276112 and compare with your own approach? [12:48] dednick proposed something equivalent to your fix [12:48] mterry, hey, time for a quick mumble with mzanetti and me re: isTouchApp? [12:48] greyback_, so the line ending issue in that branch I submitted? My editor (gedit) inserted a newline character at the end of the file. But doesn't render it. vi doesn't render it or let me delete it. Nor does QtCreator (I can delete it, but it will insert it again when saving). I don't know how you got your file in that state. I'm going to have to hexedit to get it back [12:49] mterry: nah, don't bother, it's not worth that kind of trouble [12:49] Saviq, sure [12:50] mterry, greyback_, files should have a newline at the end, but that should show up everywhere, maybe it's just \r or something? === dandrader_ is now known as dandrader [12:50] mterry, ok, we're there [12:51] Saviq, no it's ascii 12 [12:54] bad gedit [12:58] Saviq, no... it's enforcing that files have a newline at the end. As is QtCreator here. I don't know how greyback_ made the file [12:59] ;) [12:59] wasn't me, blame dednick [12:59] he's the vi guy. There's tab chars in there too [13:01] greyback_, speaking of, comparing the two branches, I think the outcome is the same. dednick just makes the ulong type more "c++" by using a 'duration' type which knows how to convert to other time types. So that's nice I guess === alan_g is now known as alan_g|lunch [13:01] Seems better than my branch [13:01] my branch rules [13:01] :) [13:02] dednick, :) [13:02] sorry, i had the branch for awhile waiting to propose. didnt know it was causing an issue at the time. [13:03] * mterry shakes fist at dednick [13:04] These branches have had me looking at the API for these C++ time types... And I love the specified sizes. milliseconds is at least 45 bits. microseconds at least 55 bits. /me can't wait for the 55 bit processors of the future [13:09] yeah, it's a bit odd [13:12] gotta love the C++ specs, types are defined "at least" bits [13:15] mterry: if you're happy with dednick's branch, please +1 it and I'll do the test [13:15] rest [13:18] dednick, I'm testing your branch to double confirm it fixes the problem in my u8 branch that noticed this. That way you can tick off the manually-tested checkbox :) [13:21] mterry: ta [13:28] dednick, looks good [13:51] Saviq, fixed lp:~unity-team/unity8/new_fix_upsidedown [13:51] dandrader, great, thanks [13:59] mzanetti, updated https://code.launchpad.net/~lukas-kde/unity8/activateWindows/+merge/275706 [13:59] yep, saw it, thanks === alan_g|lunch is now known as alan_g [14:05] greyback_, shall I add https://code.launchpad.net/~unity-team/qtmir/1510571.ms-timestamp-compression/+merge/276112 to silo? [14:05] 3... [14:05] 2... [14:05] 1... [14:05] adding [14:07] Saviq: yes [14:07] just testing on device now [14:07] greyback_, ok, building in silo, too [14:17] /food [14:30] Saviq: how can a client check if it should be using single-surface mode or not? === Guest42341 is now known as francksolo [15:02] attente, today, anything that has X-Ubuntu-Touch=true in its .desktop file needs to launch single-surface [15:03] attente, we'll allow multi-window for the browser at some point in the near future, and for Xmir, but that's multi-window, not multi-surface, menus, tooltips etc. will need to be single-surface for now [15:03] Saviq: isn't that used for unity 8 desktop too though? [15:03] attente, that's still single-surface today [15:03] attente, we don't really have window management in unity8 yet [15:03] but at some point in the future we have to differentiate, right? [15:04] attente, yes, at that point the app will likely get a hint in what usage scenario the device is working in, what input methods are available etc. === dandrader is now known as dandrader|lunch === dandrader|lunch is now known as dandrader === davidcalle is now known as davidcalle|afk [16:51] dednick, looks like https://code.launchpad.net/~nick-dedekind/qtmir/lp1475678.surface-occlude/+merge/273426 is missing a prerequisite [16:52] dednick, lp:~mterry/qtmir/no-touch-no-lifecycle [16:53] dandrader, no need [16:54] dandrader: if you mean because it's in the unity8 branch, it was just to get to to bind together in the silo [16:54] dednick, Saviq, It won't compile without it because of unity-api [16:54] dandrader, that doesn't really mean it's a prerequisite in qtmir [16:55] Saviq: mzanetti: greyback_: https://code.launchpad.net/~aacid/unity8/dash_backgroud_source_size_rework/+merge/276157 [16:55] dandrader, if unity-api gets rebuilt without no-lifecycle for some reason [16:55] dandrader, it will build [16:55] Saviq, yes. but's not the current situation [16:55] dandrader, but that doesn't mean the qtmir branch has the other as prerequisite, you could say the opposite just as well [16:56] dandrader, and then, if it happens, we'd need to resubmit again [16:58] Saviq, the fact is it won't build with the branches mentioned in the checklist. So it should at least mention in the checklist what it needs to build [17:00] dandrader, truth is the unity-api branches shouldn't be prerequisites either [17:01] because the only conflicting change there is the changelog, which could be solved easily by having the same change in both [17:01] but I wasn't fast enough saying that to dednick before he already resubmitted :P [17:02] :) [17:04] dednick, Saviq so here's the thing: I'm building those branches on my N7 to test them. the *only* way I can do it is by manually merging lp:~mterry/qtmir/no-touch-no-lifecycle on top of dednick's one. [17:04] becasue unity-api and unity8 also got rebased [17:05] dandrader, right, I can agree mentioning those in description would be usefuly [17:05] -y [17:06] dandrader: in which one? qtmir or unity8 [17:06] dandrader, but they kind-of-are, since qtmir/occlude → unity8/occlude → unity8/lifecycle → qtmir/lifecycle ;) [17:07] dandrader, but sure, I agree, not ideal [17:07] I know this is just bureaucracy now since all people involved know the situation, but better not make an habit of it. this can get out of hand... [17:07] well i just added it to the mp list [17:08] dandrader, luckily it's not often we land two unity-api changes in one silo [17:08] dandrader, and we only made it prereq because they actually conflicted [17:08] (unity8, that is) === boiko_ is now known as boiko === alan_g is now known as alan_g|EOD [18:10] mzanetti, ping [18:12] dandrader, hey [18:14] mzanetti, John Lea is tesing the mouse edge push, playing with parameters. But he's suffering with the slow mouse and asked for a way to adjust its speed. was thinking about adding a gsettings option for it so that we apply a multiplier for the relative movement we get from mir. that's as a temporary measure until mir's mouse relative movement has acceleration applied [18:14] mzanetti, what do you think? [18:15] dandrader, what's the ETA on the proper solution? [18:15] mzanetti, was going to aske anpok about it. but he didn't reply to my ping yet [18:15] *ask [18:16] dandrader, well, you could certainly just put together a testing silo for John with that hack... whether we should land it or not, really depends on anpok's answer [18:17] mzanetti, so far I'm doing old school and providing debian packages in a .zip + instructions :) [18:18] hehe, well, still, for testing that's probably ok... does the mouse have any acceleration atm? [18:18] because even if you double the speed, without some progressive acceleration he won't get the real feeling [18:18] mzanetti, no. that interim solution would just serve to adjust speed. no acceleration at all [18:18] mzanetti, right [18:19] I'd say it depends on him. if he wants to test it right now and is ok with no accel, give him some dpkg's but let's try to get the proper solution prioritized for the landing [18:21] mzanetti, or, conversely, land the mouse edge push without the fine tuning and only do so once we get proper mouse acceleration from mir [18:22] mzanetti, maybe it's not worth doing the fine tuning with the mouse the way it is today... [18:22] yes, works for me too [18:22] that's a good point [18:41] real feel .. hmm [18:42] i even got some push back because the mouse is now too fast.. with libinputs acceleration [18:43] brb swithcing networks === davidcalle|afk is now known as davidcalle [21:00] Saviq, I see you added the timestamp branch to silo 21. I'll add my shutdown dialog branch back in too then [21:01] mterry, right, should've done that [21:02] mterry, I committed the timezone fixes to the wizard, can you please rebuild the oobe silo? thx [21:03] ltinkl, rebuilding now [21:40] ltinkl, looks like I need to update my branch from trunk. will do that in a bit and rebuild [22:17] ltinkl, updated my branch and rebuilt the silo. seems to be building fine so far [22:17] mterry, great, thx :)