=== _salem is now known as salem_ === salem_ is now known as _salem === shiznix_ is now known as shiznix [07:28] tsdgeos, o/ [07:28] tsdgeos, how was it? [07:28] good [07:28] a bit too rainy [07:29] damn central europe and it's crazy weather [07:29] ;) [07:29] my sneakers are of perfectly brown color now cause of the mud [07:30] but nothing a whashing machine can't fix [07:30] * tsdgeos reading emails [07:48] Saviq: karni: there's a bug complaining about seemore/less but it hasn't been merged :S or has it? [07:48] tsdgeos, no, mhr3 is resurrecting it with the new designed behaviour [07:49] Saviq, eh, yea.. about that [07:49] ok, so he said last week, i was just surprised we got a bug for something wasn't merged [07:49] tsdgeos, which one? [07:49] ...just a sec, in meeting [07:49] tsdgeos, ah that one [07:49] tsdgeos, it was in Preview I imagine [07:49] ah [07:49] may be [08:14] Saviq, tsdgeos, so i have a branch that has the see more button (based on tsdgeos' one) and adds support for the expansion queries, but there are issues with the see more that i wasn't able to fix... clipping in the section headers and on the see more widget itself [08:15] was hoping you could finish it, cause there's just too much lvwph magic [08:15] it's all in lp:~unity-team/unity8/grid-see-more [08:20] Saviq: do we have an easy way to reproduce https://bugs.launchpad.net/unity8/+bug/1337408 ? [08:20] Ubuntu bug 1337408 in Unity 8 "veritcal-journal with single result does not display" [High,Triaged] [08:20] tsdgeos, probably in tryDash, after modifying fake_categories? [08:20] i meant realworld code, but sure, that should do it [08:20] let's see [08:22] tsdgeos, there's the store button, that's the only category with a single result [08:22] tsdgeos, or well, you could probably search so that you get one result [08:22] tsdgeos, and override the category in scopetool then [08:50] mhr3, btw, karni reported yesterday, not sure he caught you, that if he has a canned query in a preview button, but one with empty searchQuery, it doesn't execute → only after he started typing did the new department etc. get loaded [08:52] actually, I didn't type, I just tested with CannedQuery with set department and 1) unset query string 2) query string set to " " -- 1) only updated departments dropdown, not the results [08:52] Saviq: https://code.launchpad.net/~aacid/unity8/verticalJournalSingleResultHeightBug/+merge/225937 [08:52] 2) did update the results (as if it forced refresh), but I had this ugly search box at the top. AND, when I press back I was actually at the top, not in subdepartment [08:53] Saviq: unfortunately we do not really have tests for CardVerticalJournal [08:54] tsdgeos, I know :| [08:55] karni, bug? [08:55] mhr3: https://bugs.launchpad.net/unity-scopes-api/+bug/1338616 [08:55] Ubuntu bug 1338616 in unity-scopes-api "CannedQuery unreliable" [Undecided,New] [08:57] karni, didn't you hit this btw? https://bugs.launchpad.net/unity-scopes-shell/+bug/1335761 [08:57] Ubuntu bug 1335761 in Unity 8 "[Dash] Activating a preview with a scope URI for the current scope doesn't send you back to the results view" [Undecided,New] [08:58] mhr3: that too, then I pinned the scope, like you suggested. [08:59] karni, oh does your result take you to a new scope? [08:59] not the original one? [08:59] oh my... messages is now a bell button :| [08:59] s/button/icon/ [08:59] karni, also, you didn't read it :) [08:59] mhr3: I'm not sure where it takes me, to be honest. may be my scope, but search rather than subdepartment (even though these work) [09:00] mhr3: huh? [09:00] karni, that bug says that activating a scope query doesn't close the preview [09:00] doesn't say anything about pinning [09:00] mhr3: which bug? [09:01] my or yours [09:01] *mine [09:01] mine [09:02] mhr3: true. I read the title, so I thought you're referencing "Activating a preview with a scope URI for the current scope doesn't send you back to the *proper results* view, just back to where you were" [09:03] mhr3: so if that helps, no - that's not one of the two bugs that I found. It's a different one. [09:03] Saviq: did you ever reproduce https://bugs.launchpad.net/unity8/+bug/1330899 ? [09:03] Ubuntu bug 1330899 in Unity 8 "Grid view collapses if no title used" [Critical,Triaged] [09:03] tsdgeos, yes [09:04] tsdgeos, it was enough to just go down to art alone in a grid layout [09:04] karni, ok, anyway, yep, definitely a bug, will need fixing [09:04] Saviq: so art only in a grid made that happen? [09:04] weird [09:05] let's see if i can reproduce [09:05] Saviq, could i land u8 today? want to push latest unity-api, so will need to fix u8's ftbfs [09:06] mhr3, I wanted to land, yes, waiting for silo 4 to clear up [09:15] tsdgeos, no opinion on the other points in scope-customizations discussion? name was kinda easy to decide on ;) [09:15] Saviq: well i'd personally vote on just pass down all stuff individually [09:15] which is what kind of what my first patch had [09:15] but if you both agree we don't want that [09:15] i guess what we have now is the only other option i can think of [09:19] tsdgeos, yeah, there's going to be too much passed individually, and would mean that everything in between would need a useless property [09:19] Saviq: or alias, but i see why you don't like it [09:21] tsdgeos, so what do you think about the default objects to avoid init warnings? I like those more than `foo ? foo.bar : "baz"` TBH [09:21] especially because suddenly "baz" needs to be hardcoded everywhere [09:22] it's weird (in the sense we don't do it anywhere else) [09:22] but kind of works [09:23] tsdgeos, yeah, we don't do it 'cause we didn't think of it ;) [09:23] tsdgeos, I agree we should stick to one approach or the ohter [09:23] other [09:24] sure sure [09:24] tsdgeos, so what we say here will have bearing on what we do later [09:25] one surprising thing for me was that with `property ScopeStyle scopeStyle: null` it still created the ScopeStyle object (I think we saw that before somewhere) [09:25] with var it doesn't do it [09:25] oh crap, stupid tags again [09:26] mhr3, there's a .py script now [09:26] mhr3, down to a second locally [09:26] mhr3, 3 minutes remotely [09:26] how the hell did get infected [09:26] Saviq: yes, that's kind of related to the fact that "`property ScopeStyle scopeStyle: null" fails if ScopeStyle is uncreatable c++ type [09:26] mhr3, http://people.canonical.com/~msawicz/unity8/strip-u8-tags.py [09:26] frickin tag virus :P [09:26] simon said the parser is smart enough and should not do it [09:26] Saviq, yea, thx running it already [09:26] but it's a bug [09:26] Saviq, nice touch putting it in the checklist ;) [09:26] mhr3, indeed, the only thing the checklist is useful for ;) [09:28] tsdgeos, yup, understood - still I would not like to have to use an object of the actual type if I can help it [09:29] tsdgeos, any idea whether what I did, which does after all require creation of an (small, but still) object is more performance heavy than "if (foo)" everywhere? [09:29] on the one hand it's only creation time, on the other that's when 99% of the bindings would get evaluated anyway [09:29] it's probably more startup heavy [09:29] which i guess we can take [09:29] over runtime heavy [09:29] in this case [09:30] tsdgeos, well, not only startup, delegate creation, too :| [09:30] right [09:30] tsdgeos, since we have this in every card in the dash [09:30] * Saviq runs benchmark [09:30] Saviq: does maketryCardBencharmrk say any difference? [09:31] tsdgeos, just trying out === vrruiz_ is now known as rvr [09:36] tsdgeos, http://pastebin.ubuntu.com/7764637/ [09:36] :| [09:37] vesar: hangout? [09:37] Saviq: just adding the property makes it slow? [09:37] that's weird [09:37] is it reproducible? [09:37] tsdgeos, slow? [09:38] tsdgeos, the differences are .05msec [09:38] cardTitleArtSubtitleModel went from 708 to 743 [09:38] tsdgeos, well, not just the property [09:38] tsdgeos, had to add "if (foo) bar" [09:38] right [09:38] tsdgeos, http://paste.ubuntu.com/7764642/ [09:39] tsdgeos, tbh on second try it went up for null as well [09:39] * Saviq runs under xvfb [09:40] may not be stablest benchmark ever [09:40] lol, it's faster under xvfb [09:40] you may be on the verge of it not being exact enough [09:40] for stuff like 10 msec [09:40] but only 128 iterations for some reason [09:41] tsdgeos, ok, I'd say negligible [09:42] tsdgeos, difference, that is [09:42] ok [09:43] Saviq: you can't have subtitle without title on a card, right? [09:43] tsdgeos, even trunk is getting higher at times than either solution [09:43] tsdgeos, nope [09:43] good [09:43] then i guess it's ok [09:43] how come you're not computing stddev when running the benchmarks? :) [09:44] mhr3, pfft [09:45] it can actually spot changes in cache behaviour surprisingly well [09:46] not that you should care about that too much :P [09:46] mhr3, truth is we rely on Qt doing the benchmark [09:46] mhr3, not doing anything special there [09:46] greyback, you should switch to in-header gpg sig [09:46] Saviq: why? [09:46] greyback, people get scared by things like that if they don't know what it's about [09:47] greyback, I get it displayed as part of the mail body, is all [09:48] Saviq: I'm using pgp default settings, assumed it was sensible [09:50] can't find setting in the UI [09:50] greyback, somewhere there's a setting for PGP/MIME, trying to find it, too [09:50] greyback, I think it might be per account [09:51] greyback, yeah, go to accounts settings → OpenPGP, "Use PGP/MIME by default" [09:52] tsdgeos, btw, did we not have previews in tryDash at some point? [09:52] we had previews somewhere [09:52] either tryDash or GSV or somewhere [09:53] Saviq: want me to find them? [09:53] tsdgeos, looks like we lost them, is all [09:53] tsdgeos, got loads of warnings on the console when trying to activate [09:54] weird [09:54] Saviq: https://code.launchpad.net/~aacid/unity8/implicitHeightCardArtOnly/+merge/225943 [09:54] Saviq, are you ok with bumping u8's build-dep on latest unity-api, yet not bumping the -impl dep yet? will allow us to land the changes separately [09:55] Saviq: testDashContent has a few preview related tests too [09:55] mhr3, sounds fine, yes [09:55] Saviq, coolio, quick review of https://code.launchpad.net/~mhr3/unity-api/expansion-queries/+merge/225938 pls (just interface changes) [09:55] tsdgeos, yeah, the tests are there, and pass, but previews never actually load [09:55] oh [09:57] mhr3, I'm just not too happy about "expansionQuery" [09:57] mhr3, since it's not expansion any more [09:58] Saviq, hm, well designs have either that OR the see more button.. so it kinda is [09:58] but of course that can change too easily [09:58] mhr3, will we enforce that? [09:58] we might have to actually [09:58] mzanetti, maybe setting live true only when the launcher is not hidden? https://code.launchpad.net/~mzanetti/unity8/make-launcher-icons-live/+merge/224116 [09:59] mikenagle_, ^? [09:59] mhr3, will the expansion query always be in-scope, btw? [09:59] mhr3, can it not open another scope? [09:59] Saviq, it can, yes [09:59] mhr3, shouldn't performQuery be on Scopes instead of Scope, then? [09:59] Cimi: we figured that even when live: true it only updates rendering if the icon changes, which basically never happens [09:59] Cimi: so I guess we can always leave it live: true in this case [10:00] Saviq, no, if it does change the current scope, you don't want to loose that info, or to keep track of where to build a stack for that matter [10:00] Cimi: well, it happens only in one case that the icon changes, when the user longpresses it, and that's when we really want to update it... so no need to fiddle with the live property [10:00] mzanetti, fine then [10:03] tsdgeos: Saviq: so we're ok with this? https://code.launchpad.net/~unity-team/unity8/scope-customizations/+merge/225823 [10:04] mzanetti, unless you tell me otherwise, nobody convinced me this is a bad approach [10:04] mzanetti, benchmarking showed negligible difference [10:04] Saviq: difference between? [10:04] non-object vs object or object vs ScopeStyle? [10:04] mzanetti, between trunk, default: null and default: Object({ }) [10:05] mzanetti, can try with actual ScopeStyle, sec [10:05] Saviq: as you have that running already, what would be the difference to using ScopeStyle {} ? [10:05] Saviq: did you fix the comment about it not applying to previews and to departments? [10:06] tsdgeos, yes, but need add a tryPreview to actually show it, we've no other way [10:08] mzanetti, that branch doesn't build for me anyway [10:08] Cimi: which one? [10:08] issues with scopes [10:09] might be trunk [10:09] which branch? the launcher ones? [10:09] yes [10:09] yeah needs merge trunk [10:09] but is fine [10:09] hmm,,, yeah. they might require a merge with trunk by now [10:09] with trunk works [10:10] Cimi: want me to merge them? or hall we let CI do that? [10:11] ci will do that [10:11] Saviq: ok, so yeah no hard disagreement, i think i still prefer the null + if [10:11] actually no [10:11] mzanetti, sorry [10:12] but it's a matter of style [10:12] is launcher dnd that requires trunk [10:12] since it seems we can't prove it's faster/slower [10:15] Cimi: ok, let me merge all of those laucnher branches with trunk [10:15] wasn't initctl set-env GRID_UNIT_PX=18 to change pixel grid? [10:16] global [10:16] Cimi: yeah, well, for things you start with init after this [10:16] Cimi: won't affect your current session I'd say [10:16] mzanetti, tsdgeos, ScopeStyle has some impact http://pastebin.ubuntu.com/7764824/ [10:17] like .15 msec [10:17] is that 50ms on 1000 cards? [10:18] mzanetti, 150ms on 1000 cards I'd say [10:18] compared to trunk, yes [10:19] anyways [10:19] tsdgeos, so... I hate the if (foo) approach because of verbosity and the fact that you need to hardcode the default values in every single binding [10:19] so yeah... I gave my opinion, won't force you into anything [10:19] if you prefer to keep as is, I will approve [10:20] Saviq: are such tags bad? [10:20] 7.90+14.10.20140701.2-0ubuntu1 ? [10:20] 7.90+14.10.20140703.1-0ubuntu1 ? [10:21] mzanetti, where'd you get them from? [10:21] mzanetti, looks like you got tags and not merged trunk or so? [10:22] mzanetti, those tags are valid in trunk [10:22] I got them after merging with trunk [10:23] mzanetti, interesting, should not be ? [10:23] yeah... that's why I ask [10:25] mzanetti, not sure how you got there, try deleting them and merging trunk again [10:25] Saviq: heh... I pushed to the branch, did a bzr tags again and the ? are resolved now [10:26] Saviq: except one in the middle [10:26] mzanetti, yeah, that one's in trunk [10:26] ah ok [10:26] mzanetti, not sure how that one happened either, but never got around to clearing it up [10:28] mzanetti, I don't know if it a trunk issue or not merged with trunk [10:28] Cimi: I'm currently merging all the branches with trunk [10:28] mzanetti, but https://code.launchpad.net/~mzanetti/unity8/launcher-update-item-glow/+merge/224266 [10:28] mzanetti, looks clip at top and bottom [10:29] icons don't fill ubuntushape [10:29] on the phone [10:29] oh. yeah... that might be an issue indeed, now that suru theme has landed [10:29] let me check [10:30] mzanetti, so your opinion is we should use real ScopeStyle objects for the default? I'm worried that the impact will get bigger and bigger as ScopeStyle gets more things [10:30] ffs! If run.sh wouldn't kill my init all the time... [10:31] Saviq: nah... that seems to make too much of a difference indeed [10:31] mzanetti, putting pressure on this bug would probably help 1222705 [10:31] bug #1222705 [10:31] bug 1222705 in upstart (Ubuntu) "init assert failure: alloc.c:633: Assertion failed in nih_unref: ref != NULL" [Medium,Confirmed] https://launchpad.net/bugs/1222705 [10:31] mzanetti, tsdgeos, if you both dislike my approach, I'm losing here, so unless I get a third opinion I'll have to fold [10:32] Saviq: i think having the null actaully helps in reading the code, knowing the object will come from somewhere [10:32] +1 [10:32] but yes the default in the if branch is not cool [10:33] that's where qml should have a "whatever your default is" [10:33] tsdgeos, I'd be fine with null if QML didn't fucking complain all the time [10:33] :D [10:33] this has worked sometimes [10:33] thoough it's also evil [10:33] color: foo ? foo.bar : color [10:33] yeah, that makes my eyes hurt [10:34] I'm not saying that I love this, but I think its less confusing than dummy objects with some properties. Unless they are clearly marked as such... [10:35] mzanetti, as said, I will comment them of course [10:36] mzanetti, the "context property" approach could be something, but other than reaching out of scope can't see how it'd help, and then I don't think it'd help with not having if(foo) anyway [10:36] tsdgeos, btw, one thing I thought about for language changes, "inline components" is something I could use [10:36] tsdgeos, like in a file declaring "here's the Label I want, but with those as defaults" [10:37] tsdgeos, and then using that MyLabel in the same file (without a Loader) [10:39] and without having to bind props in onLoaded or wherever [10:40] tsdgeos, so, about readability... would a comment for the scopeStyle defaults be enough to help it? [10:40] * Saviq considers `foo ? foo.bar : "baz"` much less readable... [10:40] Saviq: why? [10:40] it's pretty clear on what it does [10:41] tsdgeos, because it's useless [10:41] and makes it usable from the outside [10:41] :D [10:41] in case we ever need it [10:41] sure deciding on a proper default is hard [10:41] tsdgeos, my approach makes it just as usable from the outside [10:41] true [10:41] but less obvious it will be changed (even you can see it's not readonly) [10:41] * Saviq must look really desperate to justify his approach [10:42] honestly i think you should move to the pattern we've been using everywhere [10:42] and then calmly discuss what approach we want to follow as a guideline [10:42] not as part of this review in particular [10:42] stalls stuff unneededly [10:46] needlessly [10:46] * greyback had to check that 'unneededly' was actually not a word, but thinks it deserves to be one [10:46] tsdgeos, yeah, like that will ever happen :P [10:46] greyback: tx ;) [10:47] Saviq: ^_^ [10:47] * Saviq folds :| [10:49] Saviq: i do honestly think we should have this discussion [10:49] we can have it now if you want, but don't think it's the best time [10:49] tsdgeos, we are, aren't we? ;) [10:58] tsdgeos, btw, `property var foo: bar ? bar.baz : foo` doesn't really work well either, as results in stuff changing needlessly just after initialization [10:58] Saviq, s/expansionQuery/linkQuery/ ? [10:58] Saviq: what do you mean changing after initialization? [10:58] mhr3, headerLink? [10:59] fine [11:00] tsdgeos, create → bar is null, foo gets default value; bar gets non-null, foo gets bar.baz value [11:00] mhr3 - have emailed [11:00] mikenagle_, yep, thx [11:00] tsdgeos, if default and bar.baz are different (which they will often be), it will need new render [11:00] Saviq: well that's the same that happens with your approach, no? [11:01] tsdgeos, only if bar.baz is different than the value I said is default for the component I'm creating, not for the component I'm using [11:01] i mean it will change from defaultObject.something to newObject.something [11:01] ah sure [11:01] so you're cheating ;) [11:01] pete-woods: it's the second time I see this, any ideas? https://pastebin.canonical.com/113111/ [11:02] means we need to keep default synced to get this "benefit" [11:02] pete-woods: rm'ing the directory fixes the problem, I'm just worried it's something worse then a "one time happened" [11:02] tsdgeos, yeah, how's that cheating? [11:02] tsdgeos, granted, if the default is coming from the theme in any case, probably doesn't matter [11:03] Saviq: well part of your approach is that makes code easier to read/mantain, and you also say a benefit is less propperty changes, but that means we need to manually sync defaults everywhere which makes it less easy to read/mantain [11:03] karni: you'll need to talk to the click guys (I think mainly cjwatson) about that, package installation is out of my hands [11:04] tsdgeos, we need to sync them manually anyway [11:04] tsdgeos, just in one place per file with the default object [11:04] pete-woods: thanks [11:04] np [11:04] tsdgeos, vs. however-many-per-file with null (unless you go for a proxy property) [11:05] but then you end up with: [11:05] property var foo: null [11:05] property color bar: foo ? foo.baz : "default" [11:06] * Saviq doesn't get how's that better than putting the default in foo directly ;P [11:06] Cimi: I've merged https://code.launchpad.net/~mzanetti/unity8/launcher-update-item-glow/+merge/224266 with trunk [11:06] Cimi: looks good imo [11:06] mzanetti, waiting jenkins [11:07] mzanetti, on desktop I don't have suru [11:07] Cimi: yeah, same here.... icons are empty (although I think I saw them already some days ago) [11:07] but on the phone its fine now [11:07] mzanetti, Cimi wdym you don't have suru? [11:08] Saviq: using./run.sh the launcher icons are empty [11:08] not sure why [11:08] or I simply have normal icons [11:08] not suru [11:09] circulas icons [11:09] no suru theme [11:09] so I can't test if they fill [11:09] Saviq: let's not block on this, for me you can get it merged as it is if it works (which i haven't tried, i can if you want) [11:09] and then discuss later if we want this everywhere or just here [11:09] ok? [11:10] tsdgeos, already changed [11:10] Cimi: all launcher branches merged with trunk [11:10] Saviq: doh :/ [11:10] ok [11:10] tsdgeos, but that's fine [11:10] mzanetti: all yours then? [11:10] mzanetti, almost all approved apart item glow [11:11] tsdgeos: ? [11:11] mzanetti, I reverted to foo ? foo.bar : "baz" [11:11] mzanetti, in the scope customs branch [11:11] ack [11:11] mzanetti: i mean you were doing the review, no? [11:11] yeah [11:12] mzanetti, I need to do a tryPreview, though, otherwise we can't see the previews being "affected" by the style [11:12] Saviq: why? [11:12] or you mean on tryXYZ? [11:12] tsdgeos, yes [11:12] tsdgeos, since we have no real preview anywhere in the tests... [11:13] tsdgeos, I want one that will be mostly manual (the widgets themselves are tested fine) [11:13] err [11:13] what broke? [11:13] Error: Unknown method return type: unity::shell::scopes::PreviewModelInterface* [11:13] Saviq, updated unity-api and u8 branches, do you have a silo where the api changes could go, or should i ask for one? [11:13] this used to work [11:13] mhr3, I'll take care of that today, K? [11:13] Saviq, awesome, thx [11:14] mhr3, unless you really want it *now*, then have at it [11:14] tsdgeos, yeah, that's what I meant, we managed to break the mock previews somehow [11:14] Saviq, nope, but i need to leave for a few hours, so wanted to sort it out before i do [11:14] mhr3, ok, I'll take care of it [11:16] Saviq, here's mp list for -api http://paste.ubuntu.com/7765051/ [11:16] mhr3, ah, you didn't reply whether performQuery should be on Scopes, and not Scope instead? [11:16] Saviq, i did ^^^^ [11:16] hmm [11:17] mhr3, not sure what info? you mean where it came from? [11:17] yep [11:17] Saviq: is silo 004 something big? [11:17] Saviq, really the associated scope instance [11:18] sil2100, transfer indicator, I wouldn't call it big [11:18] Saviq: I guess it's not regression prone? [11:18] Saviq, can't build much of a stack without that [11:18] sil2100, not at all [11:18] Love it [11:19] mhr3, still not sure we need it, but your call, easier for me this way anyway :P [11:19] Saviq, i think we do, plus openScope is emitted on the scope instance anyway [11:20] not on ScopeS [11:20] mhr3, ah, nasty :P [11:20] s/nasty/makes sense/ [11:20] ftfy [11:20] mhr3, we just need to forward it up anyway ;) [11:21] /food [11:21] do you? i thought you associate it with the view it came from [11:27] Holas [11:28] Saviq: https://code.launchpad.net/~aacid/unity8/fake_scopes_plugin_register_previewmodel/+merge/225956 === alan_g is now known as alan_g|lunch [12:05] * greyback going into mir land, may be offline a while [12:15] tsdgeos, thanks, wonder how that broke [12:15] mhr3, nope, we just push it up and put it on top of the list of scopes [12:31] Saviq: re: Not sure unity8 should do anything here. Libusermetrics should just not give up any data if it's disabled. [12:31] Saviq: I think that's what happens, which causes the infographics to dispay "No data sources available" [12:33] mzanetti, ah then that's gonna be fixed by https://code.launchpad.net/~cimi/unity8/infographics-new-lightdm/+merge/223221 [12:34] ah ok [12:44] mhr3: do you know how works on libunity-scopes2 package? === _salem is now known as salem_ [12:47]