[00:47] pero, I meant that most people who can answer your question are sleeping, or at least enjoying their evening, so won't be able to answer you here [00:47] pero, and a post to a mailing list is simply more persistent than a question on IRC [02:13] Saviq: thx === _salem is now known as salem_ === salem_ is now known as _salem === duflu_ is now known as duflu === tvoss_ is now known as tvoss|test === tvoss|test is now known as tvoss [07:27] Saviq: regarding the patch you mentioned yesterday, upstream has some new delegateValidated related additions which prevent the patch from applying cleanly and also sound a bit related? [07:29] Saviq: I'm adjusting it now but just unsure if it's completely correct [07:32] Saviq: and the reason for it being "dropped" is simply that the last three releases to 5.0.2 have not been merged to the 5.1/5.2 packaging branch [07:37] syncing up, the other patches were merged upstream === iahmad is now known as iahmad|afk [08:36] damn it seems my scopeview/genericscopeview merge is causing segfaults in the tests :-/ [08:37] * tsdgeos tries to reproduce locally === iahmad|afk is now known as iahmad [09:24] man this MR is hanging for a long time :/ [09:24] https://code.launchpad.net/~om26er/unity8/unlocker_fix_non_working_code/+merge/194850 [09:24] should we disable that qmltest ? [09:26] no [09:27] i'm going to fix it [09:27] as stated 1 hour ago [09:30] dednick: https://code.launchpad.net/~aacid/unity8/LVWPH_do_not_do_stuff_if_parent_gone/+merge/196070 [09:30] om26er: ↑↑↑ [09:31] dednick: remember the crashes we had in make testDash when i removed the fake scopeview from the tests and used the real one? [09:31] well they're still there [09:31] so i'm "more correctly" bypassing them than with a wait [09:33] tsdgeos: ok [09:34] tsdgeos: huh. why is there no parent context? [09:35] dednick: because the parent was just destroyed [09:35] and we''ll be destroyed asap [09:35] but somehow a painting/layout operation sneaked in [09:35] that's why we never see this crash "in real life" [09:35] because we don't destoy scopes there [09:35] tsdgeos: hm ok. do you know why is the parent destroyed before the child? [09:36] but it happens a lot in the tests [09:36] i c [09:36] not really :-/ [09:36] my only guess is that the qml stuff is not great [09:36] and hence the comment for 5.2 checking [09:37] since lots of stuff improved there and don't want to spend time chasing something that may have been already fixed [09:37] if not fixed in 5.2 [09:37] we need to put more time in understanding why this is happening [09:38] tsdgeos: ok. well i guess it's the parentContext, not the actual parent. fine by me. [09:39] dednick: if you can approve that'd be great, this is blocking other merges from happening since it fails regularly in jenkins [09:39] tsdgeos: done [09:39] dednick, if you're able to reproduce the dee criticals, just do G_DEBUG=fatal_criticals and attach gdb [09:39] thumbsup! [09:39] dednick, it will SIGTRAP when you get a critical [09:39] or SIGABRT?... one of those [09:39] mhr3: i can do it every time. :) [09:40] Mirv: you ended up in https://plus.google.com/104580575722059274792/posts :D [09:40] dednick, you got me wondering now, are you running the glib-events dee-qt branch? [09:40] mhr3: nope. [09:40] hmm, weird then [09:41] mhr3: leave it too me. I have some debugging in there. I'll sort it out. [09:41] k [09:41] there may be some finger pointing involved a bit later ;) [09:41] now i'll be scared the whole day [09:41] damn you! [09:41] hehe [09:43] dednick, one thing that i started wondering is whether we're passing correct changePos when inside the more complex transactions, that could indeed be a root cause of the failures [09:45] tsdgeos: yeah, I noticed, now I wish I'd have had something slightly better to show off :) [09:46] mhr3: hmm. i dont think so. when i was debugging before, it seemed that we were getting the correct thing through. As much as I could tell from the updating result count anyway. [09:49] oh well, i'll let you do som more debug [09:59] Mirv, re: the patch, it's tsdgeos's, and well tested, so we should be able to easily verify that it works (or not) [10:00] Saviq: Mirv: which one? [10:00] tsdgeos, delegate range [10:00] ah sure [10:00] tsdgeos, Mirv dropped it from 5.2 'cause thought it's merged [10:01] Mirv: ah no, unfortunately they don't want minor features in listview, will only accept a full rewrite with all the features + whatever we need [10:01] it's one of those sad situations [10:02] the gatekeeper is overworked and is basically saying no to anythinng that may make him more overworked in the future [10:12] Saviq: tsdgeos: yeah it's now just copied to the qt5-beta2 PPA so feel free to try out [10:12] (~test10) [10:14] Mirv, cool, that's what caused there to be no results in the dash [10:14] ah, yeah, probably [10:14] * Saviq upgrades [10:24] tsdgeos, great :) [10:25] Saviq: it's better now (and yay! we've reached "just upgrade from PPA"!), but most icons look corrupted [10:25] Mirv, yeah I saw that yesterday [10:26] Mirv, they're all UbuntuShape, so that's probably why [10:26] Mirv, was hoping we don't have it rebuilt against 5.2, but unfortunately it seems we do :/ [10:27] Mirv, will verify and file a bug against UITK [10:28] Saviq: there's a bug already [10:28] tsdgeos, ah ok [10:28] florian opened it [10:28] bug ##1252736 [10:28] https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1252736 [10:29] Ubuntu bug 1252736 in Ubuntu UI Toolkit "[Qt5.2] UbuntuShape content is incorrect, garbage shown" [High,Confirmed] [10:29] yess [10:30] yesterday they looked alarmingly like a spread-ed Ubuntu desktop (4 visible workspaces)... [10:30] tsdgeos: you know anyway you can determine from a random object if we've gone back to the event loop between function calls? [10:31] oh, there's a fix already [10:32] tsdgeos: ie. if we're in the same cycle or not. [10:32] dednick: /me thinks [10:32] dednick, break on g_main_context_dispatch [10:33] dednick, or on poll :) [10:33] can I define enums in qml? [10:34] tsdgeos, wanted to add an enum with the type of the dashrenderer [10:34] Cimi, no [10:34] Cimi, https://bugreports.qt-project.org/browse/QTBUG-14861 [10:34] strings then? [10:35] mhr3: break? [10:35] Cimi, yeah, no other way [10:35] dednick, oh you do printfs instead of gdb? :P [10:35] Saviq, you know what makes the opacity of the elements outside the preview (down) work? [10:36] Cimi, mzanetti [10:36] mhr3: well if i break on dispatch, i'm going to get a hell of a lot of breaks [10:36] dednick, https://sourceware.org/gdb/onlinedocs/gdb/Thread_002dSpecific-Breakpoints.html [10:37] dednick, I don't remember if you asked me to review something I didn't [10:37] Cimi: Components/Tile.qml, line 31 [10:38] Cimi: and Components/Carouse.qml, line 296 [10:38] mzanetti, it looks very weird with the carousel [10:38] pstolowski, not what i meant [10:38] mzanetti, I'd change the global opacity [10:38] of the whole carousel instead [10:38] pstolowski, i wanted the move inside the lib internals [10:39] Cimi: https://code.launchpad.net/~nick-dedekind/unity8/lp1238182/+merge/192965 [10:39] Cimi: well, you need to keep the current one highlighted [10:39] opaque, that is [10:39] mzanetti, it is on the carousel though [10:39] Cimi: so? [10:40] mzanetti, I mean, you see which one is highlighted because it's bigger [10:40] hmm... the previews with the carousel seem broken in trunk [10:40] mhr3: i need a break on dispatch after a condition in the deelistmodel becomes true. possible? [10:40] mzanetti, I have a branch [10:40] pstolowski, do you know what i mean? cause otherwise the copy is happening there [10:40] Cimi: well, you also see that in the row because the arrow points to it. still it's what design wants [10:40] dednick, sure [10:40] mzanetti, ~unity-team/unity8/dash-renderers [10:41] dednick, breakpoints are numbered, when you add one it'll be "1", you can then do enable / disable 1 [10:41] mzanetti, design doesn't want that on the carousel [10:41] mzanetti, I bet they don't [10:41] mzanetti, let me change the opacity of the highlighted index to 1.0 [10:41] global opacity to 0.6 [10:42] Cimi: I don't think this should differ between grid and carousel... [10:42] mzanetti, then the other elements to 0.333 [10:42] 1*0.6 = 0.6 for highlighted index [10:43] 0.333*0.6 = 0.2 for not highlighted [10:43] while keeping the selected index fully opaque [10:43] dednick, also "info breakpoints" [10:43] mzanetti, try the branch and see how weird it is [10:44] mzanetti, the highlighted index overlaps [10:44] Cimi: the design spec says 0.6 for the active one, 0.2 for the others [10:44] mzanetti, ok so I'll do as I said [10:44] the end result is the same [10:44] dednick: so [10:45] dednick: the only way i can think of, is posting yourself an event (or a timer single shot 0) (or a qmetaobject call queued) and see what comes first if that call or the other function [10:45] not sure how good that is [10:45] tsdgeos: yeah, that's what i was trying [10:46] Cimi: there seems to ba Bhavior on opacity missing too [10:46] Saviq, do we have a preference for using == or === ? let's use === when possible? [10:46] mzanetti, we can add that [10:46] Cimi, === is type-safer [10:46] Cimi: you should use whatever is correct in the particular case :D [10:46] tsdgeos: actually, i was trying a looping postEvent. So every time i handle a posted event, I post another [10:46] but yeah, if unsure === is probably the better choice [10:46] Saviq, you mean the opposite [10:47] Cimi, no, I mean that [10:47] Saviq, == doesn't care of the type [10:47] unless I completely misunderstood the two [10:47] Cimi, yes, so === is type-safe [10:47] r [10:47] Cimi, because it checks for the type [10:47] Cimi, it's not safer for *you*, but it's safer for the code ;) [10:47] hah [10:48] code, you owe me a beer then [10:50] argg, my stuff failed in autoland too [10:50] at least it did not crash like with the others :D [10:51] s/autoland/ci [10:51] * tsdgeos tries to reproduce [10:51] this is weird [10:52] so if I change the opacity of a parent [10:52] it changes the opacity of all children's? [10:52] like multiplying the opacity of each childrens with the opacity of the parent? [10:53] I supposed it was simply composing the opacity [10:53] it does multiply yes [10:53] what do you mean with composing the opacity? [10:54] tsdgeos, compiz transparency [10:54] tsdgeos, it changes the transparency of everything [10:55] tsdgeos, makes the texture containing the elements transparent, the parent [10:55] not changing the opacity of each of them [10:55] isn't this the same? [10:56] nope [10:56] it doesn't change the opacity of the children [10:56] it just changes its opacity [10:56] happens that children are inside [10:56] it changes the opacity of each children I believe [10:56] let me play with gimp [10:56] no [10:56] their opacity is still 1 [10:56] it's not [10:56] I have to see in gimp [10:56] of course they are painted at the 0.5 opacity if the parent is at 0.5 [10:56] but that's becuause you changed the opacity of the parent [10:56] this is wrong [10:57] no its not [10:57] it should be composited [10:57] it's totally reasonable [10:57] otherwise if i want to make something 0.5 transparent [10:57] i should go to all its children and make them 0.5 transparent [10:57] which makes no sense at all [10:58] I want a carousel semi transparent [10:58] I don't want all the children to be transparent!! [10:58] this is quay qml does [10:58] *what [10:58] what measn "a carousel semi transparent" [10:58] if you don't change the opacity of the children? [10:58] the whole component [10:58] I change the opacity of the texture of the carousel [10:59] not of all the damn children! [10:59] am i the only one here not understanding what Cimi is saying? [10:59] so If I change the opacity of the parent, it recurses in all children and multiply the opacity of the parent for the parent of the children [10:59] yes [11:00] and that's how it should be [11:00] otherwise you won't see anything transparent [11:00] of course I would [11:00] if it was composited [11:00] what would be transparent? [11:00] if the carousel draws nothing by itself [11:00] it's only the children that draw stuff [11:00] tsdgeos, think that failure could be unearthed by your "do-not-do-if-parent-gone" fix https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/349/? [11:01] so I need a shader [11:01] Cimi: don't think so [11:01] I think so, I need to composite [11:01] Saviq: don't think so either [11:01] Saviq: testing [11:01] tsdgeos, didn't see that failure yet [11:02] tsdgeos, ~unity-team/unity8/dash-renderers [11:02] tsdgeos, and landing failed the same test [11:02] tsdgeos, test the carousel preview [11:02] tsdgeos, see how badly the carousel tiles overlap with transparency [11:02] tsdgeos, this is because they are painted with the opacity of their parent [11:03] i don't see any problem [11:04] what would you expect to see? [11:04] ah wait i think i'm starting to understand you [11:04] tsdgeos, the tiles to be at 1 opacity with a global opacity set by the parent [11:05] tsdgeos, you can do this with a shader I believe [11:05] taking the texture of the whole carousel and painting with opacity of the parent [11:07] Cimi, tsdgeos not sure it applies here but qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-item.html#layer.enabled-prop layer helps with opacities doing unexpected things [11:07] Cimi: ok yes, sorry was not understanding you [11:07] Cimi, btw, your branch conflicts with trunk [11:08] Saviq, thanks! [11:08] Saviq, layer works! [11:09] Cimi, it needs to be used sparingly, though [11:09] Saviq, carousel? [11:09] Cimi, layer [11:09] Saviq, yeah, in carousel when highlight index is not -1? [11:09] can I? [11:09] Cimi, yeah, definitely only when the preview is happening [11:10] Cimi, what it does is render the whole item off-screen and then mapped as a whole to the right place [11:10] Cimi, which means it uses more memory [11:10] it's weird because http://paste.ubuntu.com/6452734/ breaks when enabling layer.enabled :S [11:10] ah, no geometry [11:10] silly me [11:11] yeah that's what cimi was describing and the stubborn in me wasn't understanding [11:11] Saviq, it looks like it clips outside though [11:11] Cimi: make sure the geometry of the item is defined correctly [11:12] or even use the layer.something property that is about the geometry of the layer [11:12] Cimi, it might indeed [11:13] Saviq: so that test that failed is one of the "hard" ones [11:13] basically we flick and then test that it's still moving [11:13] but what if the thing is ultra slow and it's not moving anymore? [11:13] the test fails [11:14] tsdgeos, are there simple ones? ;) [11:14] tsdgeos, right [11:14] anything that is not time dependant [11:14] tsdgeos, those are, unfortunately, run on VMs indeed [11:17] sil2100, how far are we with unity-scopes-shell? [11:17] Saviq: not sure what we can do here, other than flick again if when i am asking if it's moving it's not [11:18] mhr3: WTF is going on?! [11:18] dednick, ehm, sounds like fun is?! :) [11:19] tsdgeos, real solution would be to override the time source [11:19] mhr3: does the dee proxy post all the dbus events at same time? [11:19] tsdgeos, but that's something we won't do now - so if you can find a reliable workaround, do [11:19] dednick, yes, that's what i said in the mp [11:20] dednick, cause dbus-wise a transaction is a single signal [11:20] server as well as proxy i mean. [11:20] oh. hm [11:20] ok [11:20] mhr3: is it on a sep thread? [11:20] dednick, nope, main [11:21] mhr3: AHHH!!?!! [11:21] wtf [11:21] Saviq: i'll try [11:22] * tsdgeos sees tryCompareFunction and thinks we should contribute it upstream [11:22] mhr3: http://pastebin.ubuntu.com/6452782/ the incrementing number in the middle is the event loop count (static object posting event every cycle [i hope]). addr on right is just for grep [11:23] mhr3: it's all in the same damn loop number. [11:23] dednick, so you believe me now? :) [11:23] mhr3: you mean that something funky is going on? [11:24] mhr3: no, i don't believe you that it's all in same cycle. will not believe it! [11:25] dednick, despite all the evidence?! did you start believing in unicorns and lepricons too? :P [11:25] mhr3: unity-scopes-shell? We're in universe already with that [11:25] more likely.... [11:25] mhr3: I guess it's time for unity-scopes-api now, no? [11:26] sil2100, yep [11:27] sil2100, fwiw the control file should be cleaned up, i added some workarounds there since the zmqpp-dev was broken [11:28] mhr3: will do that then ;) [11:28] Saviq: I filed bug #1253603 which should be retraced properly [11:28] bug 1253603 in unity8 (Ubuntu) "Qt 5.2: unity8 crashed with SIGABRT in raise()" [Undecided,New] https://launchpad.net/bugs/1253603 [11:29] Mirv, will it know to use the PPA? also, unfortunately that's not going to give us much, I'm afraid ;/ [11:30] Mirv, SIGABRT always retrace to _GI_raise with no real info on what happened, or what the message was (as it's usually an assert) [11:30] but I'll keep an eye on it [11:30] dednick, when do you print the "processing changes end"? [11:30] dednick, inside flushChanges()? [11:31] mhr3: at the end of processChange() [11:31] Saviq: yes, it failed out until I added the PPA deb+src url:s to the daisy configuration [11:31] Mirv, ok, let's see [11:32] dednick, say what now? [11:32] mhr3: "processing changes" is printed at start of processChange() function, and "processing changes end" is at the end of the function [11:32] dednick, so all the invalid data() calls somehow happen between processChanged() and flushChanges()? [11:33] mhr3: well, in between processChanged and the "changeset-finished" signal [11:34] Saviq: oh right, with "which should be retraced properly" I meant that theoretically I retraced it properly with my current know-how (using view on device once, then retracing with lp:daisy and PPA sources added on host machine, then sending) [11:34] dednick, so what's the "flushing changes"? [11:34] the changeset end. [11:34] Mirv, ah, you mean you retraced it locally, got it ;0 [11:34] but there is "changeset end" [11:34] :) [11:34] mhr3: but the print "changeset end " comes before flushChanges [11:36] dednick, perhaps just pastebin the printing diff [11:36] tsdgeos, looking at https://launchpadlibrarian.net/157087510/Stacktrace.txt [11:36] tsdgeos, that's from bug #1253603 [11:36] bug 1253603 in Unity 8 "Qt 5.2: unity8 crashed with SIGABRT in raise()" [Undecided,New] https://launchpad.net/bugs/1253603 [11:37] tsdgeos, it failed assert "m_nodes.contains(node)" [11:40] Saviq: that file has changed considerably since beta1 [11:40] tsdgeos, ok [11:41] tsdgeos, that's good news [11:41] Mirv, ↑↑ [11:41] Mirv: any chance you package the rc1 snapshot? [11:41] http://download.qt-project.org/snapshots/qt/5.2/5.2.0-rc1/2013-11-21_160/ [11:41] it's not official rc1 [11:41] but it's much better than what we have for testing [11:41] tsdgeos, how far away would 'official rc1' be/ [11:41] mooooom I want my rshift back ;9 [11:42] tsdgeos: yeah I'd hope for the real one which should be still out this week, originally Tuesday, but still.. [11:42] Saviq: "this week" [11:42] but today is thursday already :D [11:42] mhr3: i think this will do it. http://pastebin.ubuntu.com/6452852/ [11:43] tsdgeos, Mirv, FWIW, the changes between the snapshot and official rc1 will probably be minimal [11:43] if any [11:43] Saviq: "a bit" was a bit of understatment :D [11:43] see http://pastebin.kde.org/pmkjmy8pc [11:43] 109 files changed, 3193 insertions(+), 1492 deletions(-) [11:43] Saviq: that assert error fixed since beta1: https://bugreports.qt-project.org/browse/QTBUG-34311 [11:43] tsdgeos, right [11:43] Saviq, this clip is annoying... might use a shadereffect === _salem is now known as salem_ [11:44] Cimi, that will clip, too [11:44] why? [11:44] because it's ouseide the item? [11:44] Cimi, because ShaderSource only looks within the bounds of the item it's sourcing from [11:44] Cimi, yes [11:44] Saviq, so if I use a container? [11:45] it'll be easier if it's enough to build qtbase + qtdeclarative or such [11:45] dednick, but, but... that's impossible! [11:45] Cimi, if everything will be within the bounds of the item, layer will work just the same [11:45] mhr3: I KNOW! [11:45] Cimi, layer is effectively just a shortcut to shadersource [11:45] dednick, can you get full stacktrace of the "No row..."? === MacSlow is now known as MacSlow|lunch [11:46] who the hell calls that [11:46] mmm ok [11:46] mhr3: er, yeah, but it sucks, so i'm currently building debug symbols for qtbase/declarative [11:46] Mirv, that would be a start, sure [11:46] Mirv, it's what we're using most anyway [11:46] Saviq, I'm not convinced of that [11:46] dednick, why don't you just apt-get them? [11:46] mhr3: um. where from? [11:46] Saviq, if I put layer.enabled = true [11:47] Saviq, on a container [11:47] it doesn't seem to apply layers on the children's too [11:47] so I can't really do that [11:47] dednick, https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages [11:47] mhr3: yeah, just looking now [11:47] Cimi, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-item.html#layer.sourceRect-prop [11:48] Saviq, :D [11:48] Saviq, just now that I was happy to play with shaders :D [11:48] Cimi, tsdgeos told you to look over those before [11:49] Saviq, I missed that, yeah he told me [11:50] Mirv, so bug #1253603 is fixed past beta1, want to mark it somehow for that? [11:50] bug 1253603 in Unity 8 "Qt 5.2: unity8 crashed with SIGABRT in raise()" [Undecided,New] https://launchpad.net/bugs/1253603 [11:51] we need a way to track upstream JIRA bugs in LP [11:53] /food [11:58] mhr3: hm.. still not much help. http://pastebin.ubuntu.com/6452903/ [11:58] dednick, that does not look like the main thread [11:59] dednick, info threads [11:59] where's the *? [11:59] Saviq, mmm no [11:59] Saviq, I'll tell you after your lunch [12:00] mhr3: thread 1. "unity8" [12:00] wtf just got wtf-er [12:01] dednick, let's just say that your computer is broken, k? :P [12:01] lol [12:02] mhr3: sounds like a plan to me [12:02] #ubuntu-unity, If someone could tell me what avant-window-navigator on WPD8 is ? seriously (I check the logs for this channel later - so tell myself) , that'd be great .. bye .. off for date night : avant-window-navigator | http://www.webupd8.org/2013/11/avant-window-navigator-gets-new.html [12:02] leaves. [12:08] mhr3: something else a bit odd. This all happens on the first event cycle that the object is alive. [12:09] mhr3: i mean, the first cycle it exists. [12:10] dednick, object == the dee model, or the DeeListModel? [12:10] mhr3: the DeeListModel [12:11] hmmmm [12:12] but that means that the model is already synchronized [12:14] Saviq: marked, and trying a build of qtbase snapshot now [12:22] grrr, now the test failed somewhere else [12:24] actually a different test [12:26] dednick, idea - i think the read to this model is coming because of a change in a different model [12:26] dednick, can you pastebin an unfilitered output? [12:26] unfiltered* [12:27] cause things are complicated in category models [12:28] all the data is one sharedmodel, but that shared model has data for all categories, so results are split up by category in a filteredmodel [12:29] so it's possible that one category emits flush, but that somehow triggers read in a different category which is in middle of transaction [12:29] mhr3: http://pastebin.ubuntu.com/6453015/ [12:29]