=== redj_ is now known as redj === _salem is now known as salem_ === salem_ is now known as _salem === jhodapp is now known as jhodapp|afk [09:44] Saviq: so what's the plan? first land 5.2 then new-scopes? [09:44] tsdgeos, yeah [09:44] ok [09:44] tsdgeos, today is review day [09:44] tsdgeos, please start looking at mterry's split greeter [09:45] so https://code.launchpad.net/~unity-team/unity8/new-scopes-cleanup-5.2 is the "top branch" we want to merge [09:45] tsdgeos, I'll go through that [09:45] ok, i'll read mterry's code [09:49] Saviq, found the cause of the card hiccup? [09:49] mhr3_, not yet, let me look at it now [09:50] tsdgeos, we still have fails in qmltests [09:50] mhr3_, can't get it to work still ;/ [09:50] tsdgeos, testLauncher [09:50] mhr3_, src/capnp/layout.c++:1822: requirement not met: expected ref->kind() == WirePointer::STRUCT; Message contains non-struct pointer where struct pointer was expected. [09:50] I don't think the launcher is flicking [09:50] mhr3_, and restarting scope registry doesn't help [09:50] Saviq, restart smart-scope-proxy & scope-registry [09:50] Cimi: it's on you then, i'm reading mterry's code now [09:51] Saviq, policy libunity-scopes0? [09:51] mhr3_, right, so not only registry now... [09:51] mhr3_, yeah, that helped [09:51] ok [09:52] marcustomlinson, hey [09:53] seb128: hey [09:53] marcustomlinson, what do you mean by "silo: "? you are talking about landing/CI train? === sil2100_ is now known as sil2100 [09:54] seb128: yeah, I assume we still haven't got a silo. That branch fixes the issue and is complete. [09:54] marcustomlinson, I can put a landing ask/get a silo for the hud, but the merge request is still "needs review" and CI seems unhappy [09:54] e.g https://code.launchpad.net/~unity-api-team/hud/lp-1288025/+merge/209449/comments/496003 [09:54] seb128: pete-woods just commented on the MR ;) [09:55] oh [09:55] seb128: ci is only unhappy because there's a dependent change in libdbusmenu-qt [09:55] pete-woods, marcustomlinson: qt5.2 is in trusty-proposed now, so should be fine to land hud soon ;-) Is the CI being unhappy on that merge request "normal"? [09:56] whaaat? 5.2 in proposed? [09:56] mhr3_, yups [09:56] mhr3_, found issue [09:56] how come i didn't get a OMG! mail? [09:56] pete-woods, if you need a libdbusmenu-qt change/update, you should update the build-depends on the version you need at least? [09:56] seb128: I have done [09:56] it's not just a single MR [09:57] oh, right [09:57] there is a pre-require branch [09:57] good [09:57] yes [09:57] or three :) [09:57] marcustomlinson, pete-woods: thanks ;-) [09:57] let's hope we can land soon [09:57] LTS coming :p [09:57] seb128: and don't worry, I will make sure I can search for préférences :) [09:57] (btw you might want to change the status to "approved" if it's approved) [09:57] pete-woods, thanks ;-) [09:59] seb128: I can't change them to approved, as I don't have a silo yet, so no-one can test them for me [10:00] (the rules say I have to test the builds that come from the silo) [10:00] Cimi, tsdgeos, there's an issue with the dynamic carousel merge, there's a few places that reference "template" directly, not through cardTool still (i.e. CardFilterGrid.qml:27) [10:00] pete-woods, I don't see how changing to "approved" conflicts with the silo? [10:00] pete-woods, there is no automerging of approved branches anymore with CI train [10:00] I understand that [10:00] but isn't it wrong to approve them until they have been tested via the silo? [10:01] pete-woods, on other projects (e.g indicators, settings) we use approved as the list of things that are ready to be pushed through CI train [10:01] your project, your call [10:01] Cimi, tsdgeos, results in broken apps card when searching (i.e. install click scope, restart scope-registry, ./builddir/tools/unity-scope-tool, search in Apps → no titles) [10:01] I understand/use it as [10:01] "approved = got review, should be ready to land" [10:01] review the approved changes [10:01] put them in silo [10:01] then we test the silo [10:01] and if it's green we press the land button [10:02] * Saviq reverts [10:02] which then upload/merge back [10:02] seb128: okay, if that's how you understand the process, then I will do that in future [10:02] Saviq, let me fix it instead revert [10:02] pete-woods, thanks, but feel free to keep your workflow if it works for you, I'm not saying mine is the only valid one ;-) [10:03] Cimi, k, let me know [10:03] pete-woods, the main advantage with the way I described is that +activereview give you a nice overview of what is ready to be put in a silo (= the approved changes) [10:03] otherwise you need to keep track mentally of what got reviewed/approved [10:04] that's a good point, and I would definitely prefer to do it this way, I just got a different interpretation of the rules when I read them [10:04] but if other teams are doing this, then I am happy [10:04] pete-woods, there's no rule on that [10:04] pete-woods, ci train doesn't even care about LP status, if you put the MP in it, it will merge it even if it's rejected [10:04] Saviq: hmmm i think i had fixed that [10:04] but maybe not [10:05] E_TOO_MANY_BRANCHES [10:05] Saviq: I understand that, I just don't like getting blamed for breaking things because I didn't follow the Process [10:05] tsdgeos, doesn't look like it, at least not in branches I'm looking at [10:05] pete-woods, remember the process is yours, not anyone else's :) [10:05] pete-woods, as said, we do it this way for indicators and settings, so feel free to do it as well, it's fine by the rules ;-) [10:06] new-scopes-cleanup is fine [10:06] new-scopes-cleanup-5.2 is fine too [10:06] Saviq: which branch are you on? [10:06] tsdgeos, hmm tried on cleanup, maybe didn't pull [10:07] tsdgeos, nothing to pull, did you search? [10:07] Saviq: no, but it's not referencing template directly [10:07] tsdgeos, ok, that doesn't fix the issue though [10:07] that's a different thing :D [10:08] tsdgeos, sure ;) /me pulls the fix to clean-to-trunk [10:08] Cimi: can you have a look at it? [10:08] or shall we both? [10:10] Cimi, please fix on clean-to-trunk, not -cleanup, I was hoping for cleanup to only really do test fixes... [10:11] * Saviq reviews cleanup so that it gets in new-scopes sooner rather than later [10:12] tsdgeos, I can [10:12] ah, but we need 5.2-fixes on trunk first... [10:12] I'll look at both [10:12] having a coffee, had insomnia last night [10:13] this friday seems like a classic monday :) [10:13] but we all know that engineers have best ideas when they have lack of sleep, it's out environment [10:13] *our environment [10:15] mzanetti, review https://code.launchpad.net/~unity-team/unity8/fix-5.2-tests/+merge/209058 please? [10:17] MacSlow, qml/Notifications/Notification.qml: bad whitespace in lines 42, 48 [10:17] MacSlow, in modal snaps [10:17] Saviq, already fixed [10:17] MacSlow, ok [10:17] MacSlow, what editor do you use? [10:18] ah... insensible or whatever it's called [10:18] MacSlow, sounds like you need to enable whitespace checks :) [10:18] mmm [10:18] Saviq, sublime... as I can't stand QtCreators text-rendering :) [10:18] Saviq, is there any way to tweak Qt-text-rendering in some way... it always looks a bit "fuzzy" [10:19] MacSlow, no idea, check out 3.0 from -proposed, maybe that's better? [10:19] Cimi, ^ maybe you know [10:20] MacSlow, my guess is using other ways to render text [10:20] with qtquick it might use the distance maps [10:20] Cimi, sure... it using a distance-field based texturing approach... compared to gtk+'s cairo/pango one [10:21] MacSlow, http://blog.qt.digia.com/blog/2012/08/08/native-looking-text-in-qml-2/ [10:21] QtCreator is not QML guys [10:21] I thought parts of it are qml scenes.. [10:21] the welcome screen [10:21] anpok, also regular Qt-desktop apps look like they use the same technique... text on the desktop doesn't look as crisp as in gtk+-apps [10:22] get bad glasses .. distance based fonts are a lot faster :) [10:22] Cimi, ah... interesting... thannks for the link! [10:23] if it works, we should enable on our desktop [10:25] Saviq: yep, can do that now [10:26] MacSlow, some more data here https://bugreports.qt-project.org/browse/QTCREATORBUG-9751 [10:26] Saviq, thanks [10:27] mzanetti, did you ever get to the behemoth 7k diff of new scopes cleanup? [10:27] Saviq: yeah, I've read through it, Albert is already fixing my comments. Still have to do the functional test [10:28] mzanetti, I meant https://code.launchpad.net/~unity-team/unity8/new-scopes-cleanup/+merge/209642 [10:28] ah no... that was the clean-to-trunk [10:28] no didn't get to the other yet [10:28] mzanetti, ok, I might actually get on it if you don't, let's see who's first [10:28] * tsdgeos can't stand subpixel hinted fonts [10:29] i want black you fool not green! [10:29] * Saviq slows down work to let mzanetti review the bitch... [10:29] * mzanetti still hopes gerry comes back soon and approves the right-edge branch :P [10:30] ;D [10:30] mzanetti, did you write launcher tests? [10:30] Cimi: yes [10:30] let's merge right edge and new scopes on a Friday, what's the worst that can happen! ;D [10:30] * mzanetti doesn't see why not :P [10:31] who has qt 5.0? [10:31] Saviq: worst case, we instruct people to flash the mwc image for the weekend [10:31] first of all [10:31] Saviq: shall i ask mterry to rebase his branch on top of new-scopes-cleanup-5.2? it doesn't merge cleanly there [10:31] * mzanetti 5.2 [10:31] tsdgeos, can you run testLauncher and see if it fails for you? [10:31] with 5.2 [10:31] or mzanetti [10:31] Cimi: new-scopes or trunk? [10:31] * mzanetti runs [10:31] tsdgeos, maybe review against trunk for now [10:32] Saviq: ok [10:32] tsdgeos, ns [10:32] tsdgeos, we have right edge that might still get in before new-scopes [10:32] * Saviq got a u8 crash on 5.2, let's hope it's a known sig [10:33] Cimi: trunk testLauncher passed here with 5.2 [10:33] Cimi: same with launcherbackendtest and launchermodeltest [10:34] Cimi: http://paste.ubuntu.com/7089382/ [10:34] Cimi: i think i had a look at this one, flick() doesn't seem to be flicking enough [10:34] tsdgeos: is this in xvfb? [10:34] you may want to replace flick() with a mouse press+move+release [10:34] mzanetti: no, regular unity7 [10:34] 8 I assume, trunk? [10:35] mzanetti: no, running 7 [10:35] mzanetti: new-scopes-cleanup-5.2 branch [10:35] let me see what fix-5.2 says [10:35] tsdgeos, ok, have the same issue with flick [10:35] tsdgeos, and I was thinking of doing mouse flick indeed [10:40] MacSlow, there's an "antialias" option under Text Editr / Font & Colors in QtC, not sure, though, that it would get what you want ;) [10:41] Saviq, that was enabled already :) [10:41] MacSlow, yeah, I meant *disabling* it ;) [10:42] Saviq, that would make things worse... but I managed to tweak it a bit for the better already... it didn't pickup the system-wide set monospaced font [10:42] MacSlow, right, it does use the default on [10:42] e [10:42] internal [10:43] Saviq, it's a lot better after the tweaking now [10:47] btw unity7 improved loads this cycle [10:47] it's faster on my slow intel card [10:47] and more stable [10:47] and looks better [10:47] now we need to fix dash scopes that are slow :) [10:47] good we have this unity in the lts [10:50] there seems to be an issue with indicator AP-tests -> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/5830/console [10:50] Saviq, ^ is that to be expected? [10:51] MacSlow, "NoSuchProcess: no process found with pid 8773" [10:51] MacSlow, == crash [10:51] MacSlow, == Qt 5.0 crash that's fixed with 5.2 [10:52] Saviq, so I just have to wait this one out? [10:52] MacSlow, ignore it, yeah [10:52] Saviq, all 12 notification AP passed btw :) [10:52] I hope Qt 5.2 won't affect that ;) [10:54] tsdgeos: http://paste.ubuntu.com/7089478 <-- Qt 5.2, fix-5.2-tests branch [10:56] mzanetti, I have same issues [10:56] mzanetti, as well as launcher [10:56] just tried the launcher again... passed :/ [10:56] I'm looking into launcher [10:56] mzanetti, listview.flick seems to be weird [10:56] mzanetti, might be that you have retina screen [10:56] mzanetti, and speed flicks work on your pc [10:57] Cimi: well, I'm using unity.gu for the flicking. so it *should* not matter [10:57] but who knows [10:57] Cimi: are you sure there isn't just a waitForRendering needed? [10:57] mzanetti, trying with your gu size [10:57] mmm might be too [10:57] * mzanetti uses 18 px/gu [10:57] mzanetti, which gu do you have? [10:57] thx [10:58] and the variable to set? [10:58] * Cimi forgot [10:58] GRID_UNIT_PX [10:58] tst_DragHandle failing for anyone of you? /me suspects a gu issue too [10:59] * Cimi tries [10:59] mzanetti, works [11:00] mzanetti, works with 18 :-\ [11:00] launcher? [11:00] yep [11:01] Cimi: guess what: DragHandle works here with 8 too [11:01] afaics :P [11:01] :) [11:01] mzanetti: weird, let me see [11:02] mzanetti, which test? [11:02] of draghandle [11:02] tsdgeos, I'm looking at it [11:02] tsdgeos, GRID_UNIT_PX=18 make testLauncher works [11:03] Cimi: the lvwph ones too? [11:03] so either listview.flick clamps values [11:03] or units.gu don't work sas speed [11:03] Cimi: the flick() in the launcher only resets it to the beginning, You might just be able to increase the flick value a git and it'll work [11:03] tsdgeos, not those [11:03] Cimi: ok [11:03] this is DragHandle @18: http://paste.ubuntu.com/7089509 [11:05] mzanetti, looking [11:07] mzanetti: lwph passed here [11:08] mzanetti: is it 100% failing for you? [11:08] tsdgeos: yep, just ran it again: http://paste.ubuntu.com/7089521 [11:09] this one is not GU related. fails for 8 here too [11:10] mzanetti: yeah the test doesn't know about gus [11:10] yep.. [11:10] mzanetti: are you using xvfb-run ? [11:10] tsdgeos: no, this was all plain X [11:11] mzanetti: does running it standalone also fails? i.e. http://paste.ubuntu.com/7089534/ [11:12] tsdgeos: yeah, that's what my paste does [11:12] tsdgeos: not in a loop, but standalone [11:12] works here :/ [11:12] i'm on the 12th run already [11:12] ah... you meant the function standalone [11:12] * mzanetti tries [11:13] tsdgeos: http://paste.ubuntu.com/7089545 [11:13] tsdgeos: kwin/compiz ? [11:14] don't think so [11:14] i'd say it's resolution [11:14] i'm basically moving the mouse and expecting stuff to happen [11:14] tsdgeos: interesting. it works in xvfb [11:14] because the dpi there is probably different [11:14] the one i need [11:15] tsdgeos: ah... while thie window is quite small, I still have normal fonts [11:15] http://i.imgur.com/paH4UEo.png [11:15] looks good to me :D [11:15] ok [11:16] I could imagine the test taking less space if the fonts dpi is different [11:16] s/test/text/ [11:16] well the 0 is a bit too big [11:16] but that is just there for you to look at, doesn't play any role [11:17] tsdgeos: you sure the header isn't smaller in height? [11:17] mzanetti: no looks ok [11:17] i can snapshot mine if you want [11:18] yeah, please do [11:18] * mzanetti curious [11:18] there must be a difference... [11:18] http://i.imgur.com/E5x1to3.png [11:19] it's the test that is bogus i guess [11:19] http://paste.ubuntu.com/7089562/ probably doesn't move your high DPI at all [11:20] tsdgeos: ah. the Pageheader and sectionheader have hardcoded pixel sizes? [11:20] ye [11:20] that explains why its correct indeed [11:20] why wouldn't they? [11:21] well as i said the test doesn't use gu [11:21] yeah. [11:23] mzanetti: i'm just not sure how to make this work if indeed the pixels you have to move the mouse are indeed pixel dependant [11:23] maybe the qpa has info about that? [11:23] * tsdgeos checks [11:29] mzanettI, draghandle is not res independent [11:30] debugging that [11:30] some values I'm getting don't change [11:30] Cimi: which ones? [11:30] currently [11:30] dragThreshold of EdgeDragEvaluator [11:31] yeah.. I'm hunting that one too... [11:31] which seems to be maxDragDistance [11:31] haven't found where it's defined [11:31] that should ne res independent [11:31] mzanetti, qml/Components/EdgeDragEvaluator.qml [11:32] doesn't seem to be much in flickable that is dpi dependant or anything [11:32] Cimi: defaultDistanceThreshold: units.gu(1.5) [11:32] seems okayish... [11:32] mzanetti, maxDragThreshold [11:33] *distance [11:33] ../qml/Components/DragHandle.qml:172: maxDragDistance: maxTotalDragDistance [11:33] ../qml/Components/Stage.qml:453: maxDragDistance: stage.width [11:33] yeah... but: distanceThreshold: hintDisplacement > 0 ? 0 : defaultDistanceThreshold [11:34] mzanetti: i guess you don't see the list moving at all, no? [11:34] * mzanetti checks [11:34] nope. frozen like an ice cube [11:35] tsdgeos: ^ [11:35] mzanetti: do the other tests also pass inside xvfb-run? [11:36] trying [11:37] tsdgeos: http://paste.ubuntu.com/7089644 [11:37] so yes [11:38] that 0 != 0 should be randomly passing [11:38] we have that in trunk too [11:38] even i thought i had fixed it [11:38] is that the one you introduced the uFuzzyCompare for? [11:38] /food [11:38] mzanetti: this one and a few others with the same issue yeah [11:39] * tsdgeos let's it run in xvfb-run for a while [11:39] yep, failed [11:39] i should be able to at least make this one pass consistently [11:40] yeah... but its strange. I'm quite sure this was passing at some point here [11:40] well it does pass [11:40] just run it again :D [11:40] no... I mean the DPI related issues [11:40] ah [11:40] mzanetti: yes i think that has changed with 5.2 [11:40] ah ok [11:40] there have been some changes regarding how dpi is handled [11:41] let's fix this one i can repro first [11:41] and care about the others later [11:41] ack [11:41] Cimi: any progress on the launcher or the draghandle? depending on which one you are on, I could take the other [11:42] mzanetti, doing drag handle, no progress, just debugging [11:42] Cimi: ok. /me gets to the launcher [12:05] is there a way in qml to see what sets what? [12:05] like, what set a property width [12:06] Cimi: launcher fixed [12:07] mzanetti, push in that branch [12:07] mzanetti, or in fix-5.2-tests [12:07] mzanetti, can you pastebin diff? [12:07] Cimi: hm... I think you can see that with the profiler... [12:07] Cimi: I've pushed to 5.2-tests [12:07] ok [12:08] Cimi: diff: http://bazaar.launchpad.net/~unity-team/unity8/fix-5.2-tests/revision/751 [12:08] dammit... I accidentally pushed something [12:08] reverted [12:09] mzanetti, looks like a workaround [12:09] mzanetti, don't get me wrong [12:09] Cimi: why? [12:09] it works [12:09] mzanetti, I just wanted to know why flick doesn't work [12:09] :) [12:09] because it always had issues if listview Snapping is enabled [12:10] and now with 5.2. it seems not to be able to flick() over a snap position any more [12:10] mzanetti, you can help me with drag handle [12:10] regardless how big the number in flick(x) is [12:10] mzanetti, basically [12:10] mzanetti, if you put some fancy console.log [12:11] you realise that width of those drag handle is fixed [12:12] ok === MacSlow is now known as MacSlow|lunch === jhodapp|afk is now known as jhodapp [12:31] ahhhh [12:31] waht about make testFoo? [12:31] Saviq: ↑↑ [12:33] mzanetti, there's so much logic in those tests that I'm wondering if they are correct [12:34] Cimi: what's interesting, the DragHandles window is always the same size, regardless the ps/gu [12:34] px/gu [12:34] tsdgeos: what is with make testFoo? [12:34] mzanetti, it's not set [12:34] doesn't work anymore [12:35] huh? does here (unless you really mean "make testFoo" - including the Foo) [12:35] tsdgeos: or did you mean tryFoo? [12:35] Cimi: isn't it set to 70 gu's in tst_DragHandle.qml? === alan_g is now known as alan_g|lunch [12:36] mzanetti, vertical showable and horizontal showable in tst_DragHandle tthey don't have anchors [12:36] mzanetti: ah, yes that :D [12:36] tsdgeos: yeah... that's broken. we need our own QQuickView that registers qttest stuff [12:36] mzanetti: ok, pushed a fix for the 0 != 0 thing [12:36] tsdgeos: nice, thanks [12:37] tsdgeos, you mean make tryFoo? [12:37] mzanetti: the other ones i don't know how to tackle [12:37] Saviq: yes [12:37] tsdgeos, well, it's somewhat lower prio, but yeah we need to come up with something [12:38] Cimi: window->resize(600, 600); [12:39] ouch [12:39] I should have just grep [12:39] xD [12:39] mzanetti, that is it [12:39] haha. commented that away and guess what Totals: 10 passed, 0 failed, 0 skipped [12:39] * mzanetti pushes [12:40] mzanetti: is testlistviewwithpageheadersection the only one that fails? [12:40] i'd expect other variations of LVWPH fail too, no? [12:41] tsdgeos: lemme try [12:41] mzanetti, waiting daniel to ask why resizing? [12:41] http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/43.2.2 [12:43] tsdgeos: http://paste.ubuntu.com/7089916 [12:43] ok [12:43] so same thing [12:43] the tests that move the view with mouse presses don't play nice with your dpi [12:43] Cimi: as everything still works when removing it, I assume he added it just for some testing while developing and forgot to remove [12:43] ok [12:43] but yeah, lets ask him to be sure === _salem is now known as salem_ [13:05] THE 5.2 HAS LANDED [13:05] Mirv, kudos!!! [13:05] prepare yourselves appropriately! [13:06] * Saviq starts porting to 5.3... we should make it in time for 15.04, right? [13:07] tsdgeos: Cimi: https://code.launchpad.net/~unity-team/unity8/fix-5.2-tests/+merge/209058/comments/497520 :/ [13:07] will look into it... [13:07] /food first [13:08] yay for 5.2 :) [13:09] * Saviq imagines Mirv lying in a puddle of high-grade alcohol right now [13:13] will we ever have those ubuntushape binding loop for propery width fixed? [13:14] Saviq: :D thanks. [13:14] Cimi, did you ever try? ;) [13:14] Saviq, nope :D [13:15] I can [13:15] Cimi, then, no [13:15]