[00:47] <Saviq> 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] <Saviq> pero, and a post to a mailing list is simply more persistent than a question on IRC
[02:13] <pero> Saviq: thx
[07:27] <Mirv> 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] <Mirv> Saviq: I'm adjusting it now but just unsure if it's completely correct
[07:32] <Mirv> 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] <Mirv> syncing up, the other patches were merged upstream
[08:36] <tsdgeos> damn it seems my scopeview/genericscopeview merge is causing segfaults in the tests :-/
[08:37]  * tsdgeos tries to reproduce locally
[09:24] <om26er> man this MR is hanging for a long time :/
[09:24] <om26er> https://code.launchpad.net/~om26er/unity8/unlocker_fix_non_working_code/+merge/194850
[09:24] <om26er> should we disable that qmltest ?
[09:26] <tsdgeos> no
[09:27] <tsdgeos> i'm going to fix it
[09:27] <tsdgeos> as stated 1 hour ago
[09:30] <tsdgeos> dednick: https://code.launchpad.net/~aacid/unity8/LVWPH_do_not_do_stuff_if_parent_gone/+merge/196070
[09:30] <tsdgeos> om26er: ↑↑↑
[09:31] <tsdgeos> 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] <tsdgeos> well they're still there
[09:31] <tsdgeos> so i'm "more correctly" bypassing them than with a wait
[09:33] <dednick> tsdgeos: ok
[09:34] <dednick> tsdgeos: huh. why is there no parent context?
[09:35] <tsdgeos> dednick: because the parent was just destroyed
[09:35] <tsdgeos> and we''ll be destroyed asap
[09:35] <tsdgeos> but somehow a painting/layout operation sneaked in
[09:35] <tsdgeos> that's why we never see this crash "in real life"
[09:35] <tsdgeos> because we don't destoy scopes there
[09:35] <dednick> tsdgeos: hm ok. do you know why is the parent destroyed before the child?
[09:36] <tsdgeos> but it happens a lot in the tests
[09:36] <dednick> i c
[09:36] <tsdgeos> not really :-/
[09:36] <tsdgeos> my only guess is that the qml stuff is not great
[09:36] <tsdgeos> and hence the comment for 5.2 checking
[09:37] <tsdgeos> since lots of stuff improved there and don't want to spend time chasing something that may have been already fixed
[09:37] <tsdgeos> if not fixed in 5.2
[09:37] <tsdgeos> we need to put more time in understanding why this is happening
[09:38] <dednick> tsdgeos: ok. well i guess it's the parentContext, not the actual parent. fine by me.
[09:39] <tsdgeos> dednick: if you can approve that'd be great, this is blocking other merges from happening since it fails regularly in jenkins
[09:39] <dednick> tsdgeos: done
[09:39] <mhr3> dednick, if you're able to reproduce the dee criticals, just do G_DEBUG=fatal_criticals and attach gdb
[09:39] <tsdgeos> thumbsup!
[09:39] <mhr3> dednick, it will SIGTRAP when you get a critical
[09:39] <mhr3> or SIGABRT?... one of those
[09:39] <dednick> mhr3: i can do it every time. :)
[09:40] <tsdgeos> Mirv: you ended up in https://plus.google.com/104580575722059274792/posts :D
[09:40] <mhr3> dednick, you got me wondering now, are you running the glib-events dee-qt branch?
[09:40] <dednick> mhr3: nope.
[09:40] <mhr3> hmm, weird then
[09:41] <dednick> mhr3: leave it too me. I have some debugging in there. I'll sort it out.
[09:41] <mhr3> k
[09:41] <dednick> there may be some finger pointing involved a bit later ;)
[09:41] <mhr3> now i'll be scared the whole day
[09:41] <mhr3> damn you!
[09:41] <dednick> hehe
[09:43] <mhr3> 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] <Mirv> tsdgeos: yeah, I noticed, now I wish I'd have had something slightly better to show off :)
[09:46] <dednick> 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] <mhr3> oh well, i'll let you do som more debug
[09:59] <Saviq> 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] <tsdgeos> Saviq: Mirv: which one?
[10:00] <Saviq> tsdgeos, delegate range
[10:00] <tsdgeos> ah sure
[10:00] <Saviq> tsdgeos, Mirv dropped it from 5.2 'cause thought it's merged
[10:01] <tsdgeos> 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] <tsdgeos> it's one of those sad situations
[10:02] <tsdgeos> the gatekeeper is overworked and is basically saying no to anythinng that may make him more overworked in the future
[10:12] <Mirv> Saviq: tsdgeos: yeah it's now just copied to the qt5-beta2 PPA so feel free to try out
[10:12] <Mirv> (~test10)
[10:14] <Saviq> Mirv, cool, that's what caused there to be no results in the dash
[10:14] <tsdgeos> ah, yeah, probably
[10:14]  * Saviq upgrades
[10:24] <om26er> tsdgeos, great :)
[10:25] <Mirv> Saviq: it's better now (and yay! we've reached "just upgrade from PPA"!), but most icons look corrupted
[10:25] <Saviq> Mirv, yeah I saw that yesterday
[10:26] <Saviq> Mirv, they're all UbuntuShape, so that's probably why
[10:26] <Saviq> Mirv, was hoping we don't have it rebuilt against 5.2, but unfortunately it seems we do :/
[10:27] <Saviq> Mirv, will verify and file a bug against UITK
[10:28] <tsdgeos> Saviq: there's a bug already
[10:28] <Saviq> tsdgeos, ah ok
[10:28] <tsdgeos> florian opened it
[10:28] <Saviq> bug ##1252736
[10:28] <tsdgeos> https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1252736
[10:29] <tsdgeos> yess
[10:30] <Saviq> yesterday they looked alarmingly like a spread-ed Ubuntu desktop (4 visible workspaces)...
[10:30] <dednick> 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] <Saviq> oh, there's a fix already
[10:32] <dednick> tsdgeos: ie. if we're in the same cycle or not.
[10:32] <tsdgeos> dednick: /me thinks
[10:32] <mhr3> dednick, break on g_main_context_dispatch
[10:33] <mhr3> dednick, or on poll :)
[10:33] <Cimi> can I define enums in qml?
[10:34] <Cimi> tsdgeos, wanted to add an enum with the type of the dashrenderer
[10:34] <Saviq> Cimi, no
[10:34] <Saviq> Cimi, https://bugreports.qt-project.org/browse/QTBUG-14861
[10:34] <Cimi> strings then?
[10:35] <dednick> mhr3: break?
[10:35] <Saviq> Cimi, yeah, no other way
[10:35] <mhr3> dednick, oh you do printfs instead of gdb? :P
[10:35] <Cimi> Saviq, you know what makes the opacity of the elements outside the preview (down) work?
[10:36] <Saviq> Cimi, mzanetti
[10:36] <dednick> mhr3: well if i break on dispatch, i'm going to get a hell of a lot of breaks
[10:36] <mhr3> dednick, https://sourceware.org/gdb/onlinedocs/gdb/Thread_002dSpecific-Breakpoints.html
[10:37] <Cimi> dednick, I don't remember if you asked me to review something I didn't
[10:37] <mzanetti> Cimi: Components/Tile.qml, line 31
[10:38] <mzanetti> Cimi: and Components/Carouse.qml, line 296
[10:38] <Cimi> mzanetti, it looks very weird with the carousel
[10:38] <mhr3> pstolowski, not what i meant
[10:38] <Cimi> mzanetti, I'd change the global opacity
[10:38] <Cimi> of the whole carousel instead
[10:38] <mhr3> pstolowski, i wanted the move inside the lib internals
[10:39] <dednick> Cimi: https://code.launchpad.net/~nick-dedekind/unity8/lp1238182/+merge/192965
[10:39] <mzanetti> Cimi: well, you need to keep the current one highlighted
[10:39] <mzanetti> opaque, that is
[10:39] <Cimi> mzanetti, it is on the carousel though
[10:39] <mzanetti> Cimi: so?
[10:40] <Cimi> mzanetti, I mean, you see which one is highlighted because it's bigger
[10:40] <mzanetti> hmm... the previews with the carousel seem broken in trunk
[10:40] <dednick> mhr3: i need a break on dispatch after a condition in the deelistmodel becomes true. possible?
[10:40] <Cimi> mzanetti, I have a branch
[10:40] <mhr3> pstolowski, do you know what i mean? cause otherwise the copy is happening there
[10:40] <mzanetti> Cimi: well, you also see that in the row because the arrow points to it. still it's what design wants
[10:40] <mhr3> dednick, sure
[10:40] <Cimi> mzanetti, ~unity-team/unity8/dash-renderers
[10:41] <mhr3> dednick, breakpoints are numbered, when you add one it'll be "1", you can then do enable / disable 1
[10:41] <Cimi> mzanetti, design doesn't want that on the carousel
[10:41] <Cimi> mzanetti, I bet they don't
[10:41] <Cimi> mzanetti, let me change the opacity of the highlighted index to 1.0
[10:41] <Cimi> global opacity to 0.6
[10:42] <mzanetti> Cimi: I don't think this should differ between grid and carousel...
[10:42] <Cimi> mzanetti, then the other elements to 0.333
[10:42] <Cimi> 1*0.6 = 0.6 for highlighted index
[10:43] <Cimi> 0.333*0.6 = 0.2 for not highlighted
[10:43] <Cimi> while keeping the selected index fully opaque
[10:43] <mhr3> dednick, also "info breakpoints"
[10:43] <Cimi> mzanetti, try the branch and see how weird it is
[10:44] <Cimi> mzanetti, the highlighted index overlaps
[10:44] <mzanetti> Cimi: the design spec says 0.6 for the active one, 0.2 for the others
[10:44] <Cimi> mzanetti, ok so I'll do as I said
[10:44] <Cimi> the end result is the same
[10:44] <tsdgeos> dednick: so
[10:45] <tsdgeos> 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] <tsdgeos> not sure how good that is
[10:45] <dednick> tsdgeos: yeah, that's what i was trying
[10:46] <mzanetti> Cimi: there seems to ba Bhavior on opacity missing too
[10:46] <Cimi> Saviq, do we have a preference for using == or [10:46] <Cimi> mzanetti, we can add that
[10:46] <Saviq> Cimi, [10:46] <mzanetti> Cimi: you should use whatever is correct in the particular case :D
[10:46] <dednick> tsdgeos: actually, i was trying a looping postEvent. So every time i handle a posted event, I post another
[10:46] <mzanetti> but yeah, if unsure [10:46] <Cimi> Saviq, you mean the opposite
[10:47] <Saviq> Cimi, no, I mean that
[10:47] <Cimi> Saviq, == doesn't care of the type
[10:47] <Cimi> unless I completely misunderstood the two
[10:47] <Saviq> Cimi, yes, so [10:47] <Saviq> r
[10:47] <Saviq> Cimi, because it checks for the type
[10:47] <Saviq> Cimi, it's not safer for *you*, but it's safer for the code ;)
[10:47] <Cimi> hah
[10:48] <Cimi> code, you owe me a beer then
[10:50] <tsdgeos> argg, my stuff failed in autoland too
[10:50] <tsdgeos> at least it did not crash like with the others :D
[10:51] <tsdgeos> s/autoland/ci
[10:51]  * tsdgeos tries to reproduce
[10:51] <Cimi> this is weird
[10:52] <Cimi> so if I change the opacity of a parent
[10:52] <Cimi> it changes the opacity of all children's?
[10:52] <Cimi> like multiplying the opacity of each childrens with the opacity of the parent?
[10:53] <Cimi> I supposed it was simply composing the opacity
[10:53] <tsdgeos> it does multiply yes
[10:53] <tsdgeos> what do you mean with composing the opacity?
[10:54] <Cimi> tsdgeos, compiz transparency
[10:54] <Cimi> tsdgeos, it changes the transparency of everything
[10:55] <Cimi> tsdgeos, makes the texture containing the elements transparent, the parent
[10:55] <Cimi> not changing the opacity of each of them
[10:55] <tsdgeos> isn't this the same?
[10:56] <Cimi> nope
[10:56] <tsdgeos> it doesn't change the opacity of the children
[10:56] <tsdgeos> it just changes its opacity
[10:56] <tsdgeos> happens that children are inside
[10:56] <Cimi> it changes the opacity of each children I believe
[10:56] <Cimi> let me play with gimp
[10:56] <tsdgeos> no
[10:56] <tsdgeos> their opacity is still 1
[10:56] <Cimi> it's not
[10:56] <Cimi> I have to see in gimp
[10:56] <tsdgeos> of course they are painted at the 0.5 opacity if the parent is at 0.5
[10:56] <tsdgeos> but that's becuause you changed the opacity of the parent
[10:56] <Cimi> this is wrong
[10:57] <tsdgeos> no its not
[10:57] <Cimi> it should be composited
[10:57] <tsdgeos> it's totally reasonable
[10:57] <tsdgeos> otherwise if i want to make something 0.5 transparent
[10:57] <tsdgeos> i should go to all its children and make them 0.5 transparent
[10:57] <tsdgeos> which makes no sense at all
[10:58] <Cimi> I want a carousel semi transparent
[10:58] <Cimi> I don't want all the children to be transparent!!
[10:58] <Cimi> this is quay qml does
[10:58] <Cimi> *what
[10:58] <tsdgeos> what measn "a carousel semi transparent"
[10:58] <tsdgeos> if you don't change the opacity of the children?
[10:58] <Cimi> the whole component
[10:58] <Cimi> I change the opacity of the texture of the carousel
[10:59] <Cimi> not of all the damn children!
[10:59] <tsdgeos> am i the only one here not understanding what Cimi is saying?
[10:59] <Cimi> 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] <tsdgeos> yes
[11:00] <tsdgeos> and that's how it should be
[11:00] <tsdgeos> otherwise you won't see anything transparent
[11:00] <Cimi> of course I would
[11:00] <Cimi> if it was composited
[11:00] <tsdgeos> what would be transparent?
[11:00] <tsdgeos> if the carousel draws nothing by itself
[11:00] <tsdgeos> it's only the children that draw stuff
[11:00] <Saviq> 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] <Cimi> so I need a shader
[11:01] <tsdgeos> Cimi: don't think so
[11:01] <Cimi> I think so, I need to composite
[11:01] <tsdgeos> Saviq: don't think so either
[11:01] <tsdgeos> Saviq: testing
[11:01] <Saviq> tsdgeos, didn't see that failure yet
[11:02] <Cimi> tsdgeos, ~unity-team/unity8/dash-renderers
[11:02] <Saviq> tsdgeos, and landing failed the same test
[11:02] <Cimi> tsdgeos, test the carousel preview
[11:02] <Cimi> tsdgeos, see how badly the carousel tiles overlap with transparency
[11:02] <Cimi> tsdgeos, this is because they are painted with the opacity of their parent
[11:03] <tsdgeos> i don't see any problem
[11:04] <tsdgeos> what would you expect to see?
[11:04] <tsdgeos> ah wait i think i'm starting to understand you
[11:04] <Cimi> tsdgeos, the tiles to be at 1 opacity with a global opacity set by the parent
[11:05] <Cimi> tsdgeos, you can do this with a shader I believe
[11:05] <Cimi> taking the texture of the whole carousel and painting with opacity of the parent
[11:07] <Saviq> 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] <tsdgeos> Cimi: ok yes, sorry was not understanding you
[11:07] <Saviq> Cimi, btw, your branch conflicts with trunk
[11:08] <Cimi> Saviq, thanks!
[11:08] <Cimi> Saviq, layer works!
[11:09] <Saviq> Cimi, it needs to be used sparingly, though
[11:09] <Cimi> Saviq, carousel?
[11:09] <Saviq> Cimi, layer
[11:09] <Cimi> Saviq, yeah, in carousel when highlight index is not -1?
[11:09] <Cimi> can I?
[11:09] <Saviq> Cimi, yeah, definitely only when the preview is happening
[11:10] <Saviq> Cimi, what it does is render the whole item off-screen and then mapped as a whole to the right place
[11:10] <Saviq> Cimi, which means it uses more memory
[11:10] <tsdgeos> it's weird because http://paste.ubuntu.com/6452734/ breaks when enabling layer.enabled :S
[11:10] <tsdgeos> ah, no geometry
[11:10] <tsdgeos> silly me
[11:11] <tsdgeos> yeah that's what cimi was describing and the stubborn in me wasn't understanding
[11:11] <Cimi> Saviq, it looks like it clips outside though
[11:11] <tsdgeos> Cimi: make sure the geometry of the item is defined correctly
[11:12] <tsdgeos> or even use the layer.something property that is about the geometry of the layer
[11:12] <Saviq> Cimi, it might indeed
[11:13] <tsdgeos> Saviq: so that test that failed is one of the "hard" ones
[11:13] <tsdgeos> basically we flick and then test that it's still moving
[11:13] <tsdgeos> but what if the thing is ultra slow and it's not moving anymore?
[11:13] <tsdgeos> the test fails
[11:14] <Saviq> tsdgeos, are there simple ones? ;)
[11:14] <Saviq> tsdgeos, right
[11:14] <tsdgeos> anything that is not time dependant
[11:14] <Saviq> tsdgeos, those are, unfortunately, run on VMs indeed
[11:17] <mhr3> sil2100, how far are we with unity-scopes-shell?
[11:17] <tsdgeos> 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] <dednick> mhr3: WTF is going on?!
[11:18] <mhr3> dednick, ehm, sounds like fun is?! :)
[11:19] <Saviq> tsdgeos, real solution would be to override the time source
[11:19] <dednick> mhr3: does the dee proxy post all the dbus events at same time?
[11:19] <Saviq> tsdgeos, but that's something we won't do now - so if you can find a reliable workaround, do
[11:19] <mhr3> dednick, yes, that's what i said in the mp
[11:20] <mhr3> dednick, cause dbus-wise a transaction is a single signal
[11:20] <dednick> server as well as proxy i mean.
[11:20] <dednick> oh. hm
[11:20] <dednick> ok
[11:20] <dednick> mhr3: is it on a sep thread?
[11:20] <mhr3> dednick, nope, main
[11:21] <dednick> mhr3: AHHH!!?!!
[11:21] <dednick> wtf
[11:21] <tsdgeos> Saviq: i'll try
[11:22]  * tsdgeos sees tryCompareFunction and thinks we should contribute it upstream
[11:22] <dednick> 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] <dednick> mhr3: it's all in the same damn loop number.
[11:23] <mhr3> dednick, so you believe me now? :)
[11:23] <dednick> mhr3: you mean that something funky is going on?
[11:24] <dednick> mhr3: no, i don't believe you that it's all in same cycle. will not believe it!
[11:25] <mhr3> dednick, despite all the evidence?! did you start believing in unicorns and lepricons too? :P
[11:25] <sil2100> mhr3: unity-scopes-shell? We're in universe already with that
[11:25] <dednick> more likely....
[11:25] <sil2100> mhr3: I guess it's time for unity-scopes-api now, no?
[11:26] <mhr3> sil2100, yep
[11:27] <mhr3> sil2100, fwiw the control file should be cleaned up, i added some workarounds there since the zmqpp-dev was broken
[11:28] <sil2100> mhr3: will do that then ;)
[11:28] <Mirv> Saviq: I filed bug #1253603 which should be retraced properly
[11:29] <Saviq> Mirv, will it know to use the PPA? also, unfortunately that's not going to give us much, I'm afraid ;/
[11:30] <Saviq> 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] <Saviq> but I'll keep an eye on it
[11:30] <mhr3> dednick, when do you print the "processing changes end"?
[11:30] <mhr3> dednick, inside flushChanges()?
[11:31] <dednick> mhr3: at the end of processChange()
[11:31] <Mirv> Saviq: yes, it failed out until I added the PPA deb+src url:s to the daisy configuration
[11:31] <Saviq> Mirv, ok, let's see
[11:32] <mhr3> dednick, say what now?
[11:32] <dednick> mhr3: "processing changes" is printed at start of processChange() function, and "processing changes end" is at the end of the function
[11:32] <mhr3> dednick, so all the invalid data() calls somehow happen between processChanged() and flushChanges()?
[11:33] <dednick> mhr3: well, in between processChanged and the "changeset-finished" signal
[11:34] <Mirv> 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] <mhr3> dednick, so what's the "flushing changes"?
[11:34] <dednick> the changeset end.
[11:34] <Saviq> Mirv, ah, you mean you retraced it locally, got it ;0
[11:34] <mhr3> but there is "changeset end"
[11:34] <Mirv> :)
[11:34] <dednick> mhr3: but the print "changeset end " comes before flushChanges
[11:36] <mhr3> dednick, perhaps just pastebin the printing diff
[11:36] <Saviq> tsdgeos, looking at https://launchpadlibrarian.net/157087510/Stacktrace.txt
[11:36] <Saviq> tsdgeos, that's from bug #1253603
[11:37] <Saviq> tsdgeos, it failed assert "m_nodes.contains(node)"
[11:40] <tsdgeos> Saviq: that file has changed considerably since beta1
[11:40] <Saviq> tsdgeos, ok
[11:41] <Saviq> tsdgeos, that's good news
[11:41] <Saviq> Mirv, ↑↑
[11:41] <tsdgeos> Mirv: any chance you package the rc1 snapshot?
[11:41] <tsdgeos> http://download.qt-project.org/snapshots/qt/5.2/5.2.0-rc1/2013-11-21_160/
[11:41] <tsdgeos> it's not official rc1
[11:41] <tsdgeos> but it's much better than what we have for testing
[11:41] <Saviq> tsdgeos, how far away would 'official rc1' be/
[11:41] <Saviq> mooooom I want my rshift back ;9
[11:42] <Mirv> tsdgeos: yeah I'd hope for the real one which should be still out this week, originally Tuesday, but still..
[11:42] <tsdgeos> Saviq: "this week"
[11:42] <tsdgeos> but today is thursday already :D
[11:42] <dednick> mhr3: i think this will do it. http://pastebin.ubuntu.com/6452852/
[11:43] <Saviq> tsdgeos, Mirv, FWIW, the changes between the snapshot and official rc1 will probably be minimal
[11:43] <Saviq> if any
[11:43] <tsdgeos> Saviq: "a bit" was a bit of understatment :D
[11:43] <tsdgeos> see http://pastebin.kde.org/pmkjmy8pc
[11:43] <tsdgeos> 109 files changed, 3193 insertions(+), 1492 deletions(-)
[11:43] <greyback> Saviq: that assert error fixed since beta1: https://bugreports.qt-project.org/browse/QTBUG-34311
[11:43] <Saviq> tsdgeos, right
[11:43] <Cimi> Saviq, this clip is annoying... might use a shadereffect
[11:44] <Saviq> Cimi, that will clip, too
[11:44] <Cimi> why?
[11:44] <Cimi> because it's ouseide the item?
[11:44] <Saviq> Cimi, because ShaderSource only looks within the bounds of the item it's sourcing from
[11:44] <Saviq> Cimi, yes
[11:44] <Cimi> Saviq, so if I use a container?
[11:45] <Mirv> it'll be easier if it's enough to build qtbase + qtdeclarative or such
[11:45] <mhr3> dednick, but, but... that's impossible!
[11:45] <Saviq> Cimi, if everything will be within the bounds of the item, layer will work just the same
[11:45] <dednick> mhr3: I KNOW!
[11:45] <Saviq> Cimi, layer is effectively just a shortcut to shadersource
[11:45] <mhr3> dednick, can you get full stacktrace of the "No row..."?
[11:46] <mhr3> who the hell calls that
[11:46] <Cimi> mmm ok
[11:46] <dednick> mhr3: er, yeah, but it sucks, so i'm currently building debug symbols for qtbase/declarative
[11:46] <Saviq> Mirv, that would be a start, sure
[11:46] <Saviq> Mirv, it's what we're using most anyway
[11:46] <Cimi> Saviq, I'm not convinced of that
[11:46] <mhr3> dednick, why don't you just apt-get them?
[11:46] <dednick> mhr3: um. where from?
[11:46] <Cimi> Saviq, if I put layer.enabled = true
[11:47] <Cimi> Saviq, on a container
[11:47] <Cimi> it doesn't seem to apply layers on the children's too
[11:47] <Cimi> so I can't really do that
[11:47] <mhr3> dednick, https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages
[11:47] <dednick> mhr3: yeah, just looking now
[11:47] <Saviq> Cimi, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-item.html#layer.sourceRect-prop
[11:48] <Cimi> Saviq, :D
[11:48] <Cimi> Saviq, just now that I was happy to play with shaders :D
[11:48] <Saviq> Cimi, tsdgeos told you to look over those before
[11:49] <Cimi> Saviq, I missed that, yeah he told me
[11:50] <Saviq> Mirv, so bug #1253603 is fixed past beta1, want to mark it somehow for that?
[11:51] <Saviq> we need a way to track upstream JIRA bugs in LP
[11:53] <Saviq> /food
[11:58] <dednick> mhr3: hm.. still not much help. http://pastebin.ubuntu.com/6452903/
[11:58] <mhr3> dednick, that does not look like the main thread
[11:59] <mhr3> dednick, info threads
[11:59] <mhr3> where's the *?
[11:59] <Cimi> Saviq, mmm no
[11:59] <Cimi> Saviq, I'll tell you after your lunch
[12:00] <dednick> mhr3: thread 1. "unity8"
[12:00] <mhr3> wtf just got wtf-er
[12:01] <mhr3> dednick, let's just say that your computer is broken, k? :P
[12:01] <tsdgeos> lol
[12:02] <dednick> mhr3: sounds like a plan to me
[12:02] <ScopeParking> #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] <ScopeParking> leaves.
[12:08] <dednick> mhr3: something else a bit odd. This all happens on the first event cycle that the object is alive.
[12:09] <dednick> mhr3: i mean, the first cycle it exists.
[12:10] <mhr3> dednick, object == the dee model, or the DeeListModel?
[12:10] <dednick> mhr3: the DeeListModel
[12:11] <mhr3> hmmmm
[12:12] <mhr3> but that means that the model is already synchronized
[12:14] <Mirv> Saviq: marked, and trying a build of qtbase snapshot now
[12:22] <tsdgeos> grrr, now the test failed somewhere else
[12:24] <tsdgeos> actually a different test
[12:26] <mhr3> dednick, idea - i think the read to this model is coming because of a change in a different model
[12:26] <mhr3> dednick, can you pastebin an unfilitered output?
[12:26] <mhr3> unfiltered*
[12:27] <mhr3> cause things are complicated in category models
[12:28] <mhr3> 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] <mhr3> 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] <dednick> mhr3: http://pastebin.ubuntu.com/6453015/
[12:29] <mhr3> and that would totally explain it
[12:29] <mhr3> exactly, flush in a different model right before the invalid reads
[12:30] <dednick> mhr3: hm. i c
[12:31] <mhr3> dednick, we could update the count after each processChange(), that might actually fix it
[12:32] <mhr3> although a bit nasty
[12:32] <dednick> mhr3: .. dont think so. you need to update the count between start/endAdd/Remove
[12:32] <mhr3> and not just a bit
[12:32] <mhr3> well.. you *should* :)
[12:32] <dednick> i mean startRemoveRows / endRemoveRows
[12:32] <dednick> mhr3: no, i think there are actually issues if you dont.
[12:34] <dednick> hm. but we shouldnt be receiving reads from one model when another is flushed.
[12:35] <mhr3> dednick, well if the flush removes stuff, it might change the position of a different view so it might become visible
[12:35] <mhr3> dednick, more hack ideas - flush inside rowCount()?
[12:36] <dednick> mhr3: rowCount is only called if it changes...
[12:36] <mhr3> dednick, or if it becomes visible :)
[12:36] <dednick> mhr3: well, why are we receiving other model messages between the start/changes/end of a set anyway?
[12:37] <dednick> mhr3: i thought you said it was sync ;)
[12:37] <mhr3> well.. yea :)
[12:37] <dednick> NO!!!
[12:38] <mhr3> disregarded the master shared model thing
[12:38] <dednick> finger pointing!
[12:38] <dednick> mhr3: any way to make it sync?
[12:38] <mhr3> thinking
[12:40] <mhr3> i guess we'd need a demultiplexor that's dee-qt aware
[12:41] <mhr3> so that if a changeset is in progress in one submodel the changes are flushed if the next change is going to affect a different submodel
[12:42] <dednick> um. hm. so the events are coming into the master interleaved?
[12:43] <mhr3> not necessarily, the problem is that the changeset-end is done in all submodels at the same time
[12:44] <mhr3> so the transaction is "shared" in all the submodels
[12:45] <dednick> hm.
[12:47] <mhr3> which means that we'd need to turn the master transaction into multiple transactions in the filtermodels
[12:49] <mhr3> so... a real fix is to implement proper model demultiplexor inside unity-core
[12:49] <mhr3> not trivial, but not too hard either
[12:50] <mhr3> plus all the code could really go there, it'd just transparently work in the upper layers
[12:50] <dandrader> Saviq, when do we get a new unity8 release?
[12:50] <mhr3> all it needs is to serialize and changesets for the submodels
[12:50] <dandrader> Saviq, is CI still messed up
[12:53] <dednick> mhr3: i'm presuming you're talking about the agreggator scope here right?
[12:53] <mhr3> dednick, i'm talking about the ScopeProxy::GetResultsForCategory()
[12:54] <mhr3> dednick, right now it just returns a bunch of DeeFilterModels, which are basically independent and share the transaction
[12:55] <mhr3> if there was this demultiplexor that would feed the data to them, it could make sure the transactions can't be active in parallel
[12:56] <mhr3> dednick, as a bonus it'd even be slightly more efficient ;)
[12:56] <mhr3> dednick, dunno if you want to take a stab at that
[12:57] <dednick> mhr3: why bother with shared transactions in the first place? Seeing as they're going to turn into separate ones anyway.
[12:57] <dednick> mhr3: or is it just a unity thing that it's separating them?
[12:58] <dednick> as in if we just had a view with all the results, it would screw it up.
[12:59] <mhr3> dednick, i guess i didn't really think that through when implementing the changesets, if a FilteredModel is attached to a model, it will emit changeset-being and end when the parent model does
[13:00] <dednick> mhr3: i c
[13:00] <mhr3> so if you have multiple filtermodels there.. yey.. shared transactions
[13:00] <dednick> yeah
[13:04] <mhr3> but i don't really see a general way around that, what helps us is that we really want model demultiplexing - in our scenario you can't have one row present in multiple submodels, so the changesets can be fairly easily serialized
[13:07] <dednick> mhr3: I'll take a look, but don't really get where the demultiplexer would fit in
[13:07] <mhr3> dednick, between the sharedmodel and the filtermodels
[13:08] <mhr3> dednick, right now the filtermodels just connect to the parent's row-added/removed etc, and decide if they want the row on each change
[13:09] <dednick> mhr3: yup, i see that
[13:09] <mhr3> dednick, if a single demultiplexor connected to the row-changes, it could push the data to the filtermodel itself, and keep track on which was pushed to last, and if that changed, emit changeset-end on it
[13:10] <dednick> mhr3: and emit a changeset-start on that one again for it's next change presumably
[13:10] <mhr3> right
[13:10] <dednick> mhr3: ok, i think i get it.
[13:11] <mhr3> fwiw it shouldn't need any new dee api :)
[13:11] <mhr3> unless you want to implement the demultiplexor inside dee itself
[13:12] <mhr3> which would actually be useful :)
[13:13] <dednick> mhr3:  how would i stop the signals being connected between the shared and filters model if i didnt add to dee api?
[13:15] <mhr3> dednick, hm, right... at the very least you could pass null to the notify functions
[13:15] <mhr3> then they wouldn't accept any rows
[13:17] <mhr3> ok NULL wouldn't work, but empty function would
[13:21] <Saviq> dandrader|afk, well, we're still having some issues, but those shouldn't prevent a release
[13:22] <Saviq> didrocks, if we wanted a unity8 release, landing ask as usual, still/
[13:22] <Saviq> ?
[13:22] <didrocks> Saviq: yep
[13:22] <didrocks> Saviq: just with the infra half-working, it's taking delays
[13:22] <didrocks> Saviq: and there is a regression on the phone for wireless which block us FYI
[13:23] <Saviq> didrocks, that's fine, was just wondering - are we ever going back to auto release?
[13:45] <Mirv> Saviq: basically as soon as the CI + autotesting on devices is working, so that we get the same results we now get manually
[13:45] <Saviq> Mirv, ok, looking forward
[13:46] <Mirv> and the current queue needs to be unlocked in a manaed way before, also
[13:46] <Mirv> Saviq: me too :)
[13:48] <Saviq> mzanetti, https://code.launchpad.net/~saviq/unity8/raise-sigstop/+merge/191212 has the test added
[13:48] <mzanetti> Saviq: ack
[13:48] <nic-doffay> tsdgeos, think this is ok now: https://code.launchpad.net/~nicolas-doffay/unity8/category-transition-speed-fix/+merge/195203
[13:48] <nic-doffay> I updated the FilterGrid test.
[13:49] <Saviq> mzanetti, bear in mind it depends on https://code.launchpad.net/~gerboland/unity-mir/listen-for-server-start-stop-ready/+merge/191224 for Mir
[13:52] <tsdgeos> nic-doffay: i'll review
[13:52] <nic-doffay> ta tsdgeos
[13:52] <Cimi> Saviq, the clipping is annoying
[13:53] <Cimi> Saviq, I tried changing the rect of the layer, but it scales the texture
[13:53] <Cimi> Saviq, I think I need to use a shader
[13:53] <Cimi> well
[13:53] <Cimi> actually no...
[13:53] <Cimi> depends on what the shader gets
[13:53] <Saviq> Cimi, I'm just trying to tell you that ShaderSource behaves exactly the same as layer does
[13:54] <Cimi> Saviq, but why?
[13:54] <Saviq> Cimi, or well, not exactly
[13:54] <Cimi> Saviq, if I take a container
[13:54] <Cimi> Saviq, the content of this container is like a texture, no?
[13:54] <Cimi> like an image
[13:54] <Saviq> Cimi, just stop drawing outside of the item bounds ;0
[13:55] <Cimi> Saviq, I am trying :-\
[13:55] <Saviq> grrrrr rshift
[13:55] <Cimi> Saviq, it's the up scaling of the selected tile
[13:55] <Cimi> it's scaled up by 1.1, 1.5 etc
[13:55] <Cimi> *1.15
[13:56] <Cimi> so it goes outside the bounds
[13:56] <Saviq> Cimi, using a transform?
[13:56] <Cimi> Saviq, currently I have top and bottom margin
[13:56] <Saviq> Cimi, you can override the ShaderEffect of the layert
[13:56] <Cimi> let me try with transform
[13:56] <Saviq> -t
[13:57] <Cimi> I want to try with the shadereffect
[13:57] <Cimi> in any case
[13:57] <Cimi> let me realise I'm stupid
[14:11] <dandrader> tsdgeos, do you know when qt 5.2 is going to be releases (upstream I mean)
[14:11] <dandrader> released
[14:11] <tsdgeos> dandrader: before end of year is the target i think
[14:11] <dandrader> ok
[14:11] <tsdgeos> http://qt-project.org/wiki/Qt-5.2-release
[14:12] <tsdgeos> that's not true anymore
[14:12] <tsdgeos> since the RC isn't there yet
[14:12] <tsdgeos> but yeah
[14:12] <dandrader> tsdgeos, interesting
[14:12] <tsdgeos> it's supposed to be now-ish
[14:23] <dandrader> tsdgeos, was reading the IRC log, the RC should be decided next Monday
[14:24] <tsdgeos> ok
[14:31] <tsdgeos> hmmm
[14:31] <tsdgeos> has qtubuntu stopped linking?
[14:31] <tsdgeos> Saviq: greyback: can you check?
[14:32] <greyback> tsdgeos: which qt version?
[14:32] <tsdgeos> 5.0.x
[14:32] <greyback> ok, checking...
[14:32] <tsdgeos> greyback: trusty up-to-date
[14:32] <tsdgeos> /home/tsdgeos_work/phablet/qtubuntu/qtubuntu/src/platforms/base/context.cc:59: undefined reference to `eglDestroyContext'
[14:32] <tsdgeos> seems we don't link to egl when we should
[14:32] <greyback> hmm
[14:33] <greyback> I had similar yesterday on my phone
[14:33] <greyback> thoght it was my fault
[14:33] <tsdgeos> probably mir or something stopped pulling it
[14:34] <tsdgeos> but if we use it direcrly
[14:34] <tsdgeos> we should be linking to it
[14:34] <tsdgeos> not expect others to pull it
[14:34]  * tsdgeos does a MR
[14:35] <Saviq> tsdgeos, sorry, in session, but see you're handling
[14:35] <tsdgeos> yep
[14:42] <tsdgeos> greyback: https://code.launchpad.net/~aacid/qtubuntu/egl_link/+merge/196120
[14:43] <greyback> tsdgeos: ta, but would that be set in a pkgconfig file somewhere?
[14:43] <tsdgeos> greyback: why?
[14:44] <tsdgeos> we're using it ourselves and not exposing it to anyone else (afaics)
[14:44] <dandrader> tsdgeos, I was getting this linking error as well
[14:44] <tsdgeos> so doesn't make much sense for it to be in an input pkgconfig nor in an output one, no?
[14:44] <dandrader> tsdgeos, my solution was to manually modify the build files to refer to the missing lib
[14:45] <tsdgeos> dandrader: getting it in qtubuntu or where?
[14:45] <dandrader> tsdgeos, qtubuntu
[14:45] <tsdgeos> ok
[14:46] <dandrader> tsdgeos, I wondered why other people were not getting this error as well but did not investigate further
[14:46] <tsdgeos> new mir landed yesterday, so probably changed the game
[14:47] <dandrader> tsdgeos, that's what I had to do to have it working: http://paste.ubuntu.com/6453587/
[14:47] <greyback> tsdgeos: well that switch is set in /usr/lib/x86_64-linux-gnu/pkgconfig/egl.pc which is supplied by libegl1-mesa-dev, so let's just use that
[14:48] <tsdgeos> greyback: ah you mean using the pkg-config of egl
[14:48] <tsdgeos> sure, can do that
[14:48] <greyback> tsdgeos: indeed. Sorry
[14:50] <dandrader> is Dash::test_show_scope_on_load qmltest know to be unstable?
[14:50] <dandrader> known
[14:51] <dandrader> hmm, seems so. My MP is not the only one getting this failure...
[14:53] <tsdgeos> dandrader: i'm on it
[14:53] <tsdgeos> if you guys stop approving stuff
[14:53] <tsdgeos> mine will get jenkins cycles faster
[14:54] <tsdgeos> and we'll all be happier once it's merged
[14:54] <dandrader> tsdgeos, ah, cool. you already have an MP for it?
[14:54] <tsdgeos> dandrader: yessir
[14:54] <dandrader> tsdgeos, link please
[14:54] <tsdgeos> https://code.launchpad.net/~aacid/unity8/LVWPH_do_not_do_stuff_if_parent_gone
[14:54] <tsdgeos> it's actually more about a different one
[14:54] <tsdgeos> but i added some extra code for this one too
[14:55] <tsdgeos> greyback: https://code.launchpad.net/~aacid/qtubuntu/egl_link/+merge/196120
[14:55] <dandrader> man, looks tricky
[14:55] <greyback> tsdgeos: nice
[14:56] <tsdgeos> dandrader: it is :-/
[14:57] <tsdgeos> let's hope my MR actually fixes it or at least gives good enough info of what's going on
[15:01] <Saviq> tsdgeos, it's merging here http://s-jenkins:8080/job/unity8-autolanding/754/console
[15:01] <tsdgeos> yep, following at http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-trusty/362/console
[15:33] <tsdgeos> dandrader|lunch: did my reasoning convince you?
[15:43] <tsdgeos> merged \o/
[15:43] <tsdgeos> now let's see if others merge too
[15:43] <tsdgeos> and it's not only one time luck
[15:46] <Saviq> tsdgeos, unity8 crash on shutdown https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1253685
[15:46] <Saviq> tsdgeos, seen earlier? worth looking at at all?
[15:49] <tsdgeos> Saviq: digging
[15:49] <tsdgeos> don't remember it at first sight
[15:58] <tsdgeos> Saviq: so it seems that the InputArea that received the destroyed signal was also destroyed, since its internal dptr is 0 ( isSignalConnected (signal_index=28, this=0x0) )
[15:59] <tsdgeos> but had a look at the code and can't see how that can happen
[15:59] <tsdgeos> since when the inputarea is destroyed it says the world they don't care about them anymore
[15:59] <Saviq> tsdgeos, mhm
[16:00] <tsdgeos> or something else got borked in memory and what we're seeing is stuff that was already crashed before
[16:00] <Saviq> tsdgeos, ok, let's see what happens under 5.2
[16:01] <tsdgeos> Saviq: i guess not reproduceable?
[16:01] <Saviq> tsdgeos, easily
[16:01] <Saviq> tsdgeos, just stop unity8
[16:01] <tsdgeos> really?
[16:01] <tsdgeos> interesting
[16:01] <Saviq> tsdgeos, run from the console
[16:01] <tsdgeos> that used to work a while ago
[16:01] <Saviq> tsdgeos, Ctrl+C
[16:01] <Saviq> → crash
[16:02] <tsdgeos> Saviq: want me to dig or wait for 5.2 update?
[16:03] <Saviq> tsdgeos, nah
[16:03] <Saviq> tsdgeos, got another one from 5.2, let's see how that looks like ;)
[16:06] <tsdgeos> he he
[16:30] <Cimi> Saviq, shader effect works btw
[16:31] <Cimi> I don't like the code though :)
[16:32] <tsdgeos> 3 CI successes in a row
[16:32] <tsdgeos> \o/
[16:33] <Saviq> tsdgeos, kudos
[16:48] <Cimi> Saviq, http://paste.ubuntu.com/6454131/
[16:51] <dandrader> tsdgeos, on the qtubuntu egl thing? Yeah, I don't have a strong option there to be honest
[16:52] <Cimi> this one is probably easier to read http://paste.ubuntu.com/6454148/
[16:52] <tsdgeos> oki
[16:52] <Cimi> Saviq, can I do that or it sucks? ^
[16:52] <Saviq> Cimi, not gonna be able to look at this today
[16:55] <Saviq> Mirv, ping
[17:02] <kgunn> alan_g: worked like a champ
[17:02] <kgunn> i even verified what i built was really installed
[17:02] <kgunn> alan_g: oops...wait a minute
[17:03] <Mirv> Saviq: popong
[17:03] <Saviq> Mirv, you somehow managed to get apport-cli to file a bug against 5.2
[17:03] <Saviq> Mirv, or well, apport, not necessarily 5.2
[17:03] <Saviq> Mirv, I got the retrace, but couldn't get apport to file the bug
[17:05] <Saviq> Mirv, did you use some trick to get it up?
[17:05] <Mirv> Saviq: vim file.crash, remove the line that has the message about why it can't be submitted :)
[17:06] <Saviq> Mirv, lol
[17:06] <Saviq> Mirv, nice one
[17:07] <Mirv> you're welcome. I'd prefer some --project unity8 or such ie "just file it, just not against Ubunti"
[17:49] <Cimi> tsdgeos, does finally 5.2 fix the flick velocity and deceleration?
[17:49] <Cimi> otherwise let's patch!!!