[07:05] <tsdgeos> omg
[07:05] <tsdgeos> qmluitests are back \o/
[07:11] <tsdgeos> FAIL!  : qmltestrunner::PreviewTableTest::test_label_heights() 'verify()' returned FALSE. ()
[07:11] <tsdgeos>    Loc: [/tmp/buildd/unity8-8.10+15.10.20150713bzr1857pkg0wily61/tests/qmltests/Dash/Previews/tst_PreviewTable.qml(65)]
[07:11] <tsdgeos> is failing in CI though
[08:20] <mzanetti> tsdgeos, yeah... saw it last night still. finally...
[08:23] <tsdgeos> we're not that bad!
[08:23] <tsdgeos> only 2 failing tests and 1 we have a MR for :)
[08:23] <tsdgeos> and the other i think why it may be happening
[08:23] <tsdgeos> just need CI to run over my branch and confirm
[09:45] <Mirv> mzanetti: tsdgeos: Qt 5.5.0 is now fully testable on phone https://wiki.ubuntu.com/Touch/QtTesting (and soon hopefully on desktop too without losing eg KDE5 or appmenu). Lots of lots of bugs, although Unity itself seems good.. https://bugs.launchpad.net/bugs/+bugs?field.tag=qt5.5
[09:46] <Mirv> I'll email about it to mailing lists today or tomorrow once I've it at the state it's going to get at this point
[09:46] <mzanetti> nice one!
[09:52] <greyback__> Mirv: the qt3d is the new tech preview?
[09:56] <anpok> greyback: when qtmir posts QEvent::Hide to a window
[09:56] <anpok> will that disable processing of the qml scene?
[09:57] <greyback> anpok: doesn't stop the qml processing, just halts the renderer
[09:58] <anpok> greyback: if I see a qDebug() << ... then this will be on already?
[09:58] <greyback> anpok: no, the event is processed inside qt a little later
[09:59] <anpok> hum?
[10:00] <greyback> anpok: I think I may have misinterpreted your question, can you rephrase pla
[10:01] <anpok> i am currently looking for reasons that might cause qml scene processing to stop, since we see that the dbus signal is there.. but the processing with sensorsToggle(false) and what happens in the scene does not happen when
[10:02] <anpok> when we play videos or games are running..
[10:02] <anpok> so I was assuming a change in mir that causes us to tell qtmir to stop..
[10:02] <anpok> and that because of change timing makes it happen to soon for qtmir to react..
[10:02] <Mirv> greyback: yes, that
[10:03] <greyback> anpok: nothing *should* stop qt/qml from processing, - or to rephrase, nothing should stop the qt main loop spinning
[10:03] <Mirv> greyback: ...and it finished building on amd64 1 minute ago so it'll take 15 more before it's installable :) not tested, but finally builds.
[10:03] <anpok> greyback: ah
[10:03] <anpok> thanks
[10:04] <greyback> anpok: but if something blocks it, then we've a problem
[10:04] <anpok> that would explain it
[10:04] <anpok> i assumed we do some sort of shut down
[10:04] <greyback> nope. We tell the renderer to stop while the display is off, but unity8 is still humming away
[10:05] <greyback> Mirv: cool, I might have a play ;)
[10:08] <mzanetti> mhall119, hey ho. I've written an article. Did not publish it yet. Want to give it a read beforehand?
[12:45] <dandrader> greyback_, added the flush() call
[12:52] <dandrader> greyback_, ping
[12:52] <mhall119> mzanetti: sure :)
[12:58] <mzanetti> mhall119, let me know when I should publish it
[13:00] <greyback_> dandrader: pong
[13:01] <dandrader> greyback_, any ETA for merging the app focus hadling stuff?
[13:01] <greyback_> dandrader: it's waiting for QA approval
[13:01] <greyback_> shouldm'e be long hopefully
[13:01] <greyback_> shouldn't
[13:02] <dandrader> greyback_, when I go through the steps here: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1473720
[13:02] <mhall119> mzanetti: it looks good to me
[13:02] <mhall119> mzanetti: on a side note, will the API you developed to detect a mouse eventually be moved to the SDK where app developers can use it too?
[13:02] <dandrader> greyback_, and I have the debug version of qtmir:detach-state-from-focus, I get an assertion failure. so all would go fine in a release built
[13:02] <dandrader> build
[13:03] <mzanetti> mhall119, I certainly hope so
[13:03] <dandrader> greyback_, but still, I would like to fix this case
[13:03] <mzanetti> mhall119, so pressing the publish button now?
[13:03] <dandrader> greyback_, so, should I prepare a separate MP?
[13:04] <dandrader> greyback_, the assertion in question complains because camera-app stops while it was getting suspended
[13:04] <dandrader> so no big deal
[13:06] <mhall119> mzanetti: go for it
[13:06] <mzanetti> done
[13:07] <greyback_> dandrader: separate MP. Just in case the other thing needs to be reverted
[13:08] <dandrader> greyback_, ok. what other thing?
[13:08] <greyback_> dandrader: the detach-state-focus MR
[13:09] <greyback_> perhaps I misunderstood you but it sounded like you wanted to push the assert fix into it?
[13:09] <MacSlow> Anyone ever seena qml-warning like "QIODevice::read: device not open" in the qmltests?
[13:09] <dandrader> greyback_, yes. but it's a bit more than just fixing the assertion. it's more like making the state machine better respond to this situation
[13:09] <dandrader> greyback_, anyway, will make a separate mp
[13:10] <greyback_> dandrader: understood, and thanks!
[13:11] <greyback_> dandrader: I had a look at your mirsurface rework, one idea I have is to move any pure C++ classes into a separate lib, and ship the headers of that lib in a new dev package. WDYT?
[13:12] <dandrader> greyback_, you mean taking the Mir* headers out of unity-api?
[13:13] <dandrader> greyback_, didn't get what you mean by "pure C++"
[13:13] <mzanetti> mhall119, where can I find it now?
[13:13] <dandrader> greyback_, you mean C++ classes that do not use Qt or what?
[13:13] <greyback_> dandrader: by "pure C++" I meant anything that isn't needed for QML
[13:13] <mhall119> mzanetti: http://unity.ubuntu.com/blog/
[13:13] <greyback_> dandrader: yeah bad term, but wasn't sure how to express it otherwise
[13:13] <mhall119> I still haven't worked out how to add it to the top-level navigation, that doesn't appear to be generated from the actual pages in the database
[13:14] <greyback_> dandrader: I guess my idea is to have a lib for Qt eple who want to write a shell but without using QML
[13:14] <dandrader> greyback_, but still QObject based
[13:14] <greyback_> dandrader: yeah
[13:14] <dandrader> greyback_, I can't imagine someone using Qt but not QML
[13:15] <conyoo> hm.. strange.. why i get back from tty1 to the terminal app (ctrl alt f8) the keyboard events are messed up
[13:15] <conyoo> a is #1 instead of #97
[13:15] <conyoo> b is #2 c is #3 etc
[13:16] <greyback_> dandrader: I can. I'd like to try using Qt3d to make a shell, which isn't qquiuckitem based
[13:16] <conyoo> i have to press Super to fix it
[13:17] <dandrader> greyback_, spreading our code through more libs means more development overhead. I would way until we have a clear use for it...
[13:17] <tsdgeos> dandrader: i have a game i've been awiting for you guys to fix qtmir to not crash
[13:17] <tsdgeos> dandrader: it's Qt based and not QML based
[13:18] <tsdgeos> sure it's not the smartest thing to do, but it's old code :D
[13:18] <dandrader> tsdgeos, did you file a bug?
[13:18] <greyback_> dandrader: ok, can leave it
[13:18] <tsdgeos> dandrader: pretty sure i did, let me find it
[13:21] <conyoo> hmm.. it looks like whoever reads the keyboard buffer thinks the Ctrl key is pressed
[13:22] <tsdgeos> dandrader: well i didn't but it's basically https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1417655
[13:22] <tsdgeos> or at least i cna't find it
[13:22] <tsdgeos> well https://bugs.launchpad.net/qtmir/+bug/1223881
[13:22] <tsdgeos> is more like it
[13:23] <tsdgeos> dandrader: greyback_: i just realized you guys have https://bugs.launchpad.net/qtmir/ and https://bugs.launchpad.net/ubuntu/+source/qtmir maybe it'd make sense to do the same we did with unity and fill the first?
[13:25] <dandrader> tsdgeos, I don't know. but doing the same way we do with untiy8 sounds good to me
[13:26] <greyback_> tsdgeos: we could, but I am used to the distinction between bugs in released packages versus bugs in the current project code
[13:26] <tsdgeos> greyback_: :)
[13:26] <tsdgeos> okidkoi
[13:27] <greyback_> tsdgeos: perhaps I'm just resisting change :)
[13:27] <tsdgeos> greyback_: if you can manage for it to mean that disticntion, it's cool
[13:27] <tsdgeos> for unity8 it was just a pita since people randomly put bugs wherever they felt like
[13:28] <tsdgeos> mzanetti: the blog is virtually impossible to find unless you have a link? https://unity.ubuntu.com/
[13:29] <mzanetti> tsdgeos, I know... I had to ask mhall119 where to find it
[13:29] <tsdgeos> :D
[13:29] <mzanetti> tsdgeos, I think it'll go to planet.ubuntu at some point tho
[13:29] <tsdgeos> ok
[13:31] <mhall119> tsdgeos: I'm working on adding /blog/ to the main nav
[13:31] <tsdgeos> mzanetti: :)
[13:32] <tsdgeos> i mean
[13:32] <tsdgeos> mhall119: :)
[13:32] <mhall119> mzanetti: it's on planet.u.c now in fact :)
[13:32] <mzanetti> :D
[13:49] <MacSlow> mhall119, just wondering... should unity.ubuntu.com/blog not have a direct link to it from unity.ubuntu.com? I only see one to the Design-blog.
[13:52] <mhall119> MacSlow: it should, yes, but I don't know where that menu is getting it's data from
[13:53] <MacSlow> mhall119, ah... so the "Design Blog" one on  unity.ubuntu.com is actually meant to point to unity.ubuntu.com/blog ?!
[13:54] <mhall119> MacSlow: yes, somewhere (not in the DB or theme branch) those menu items are being defined, I just have to find them
[13:54] <MacSlow> mhall119, ok... good luck hunting then :)
[13:55] <mhall119> heh,thanks
[17:25] <dandrader> greyback_, remember that assertion issue I was talking earlier? without the assert you end up with a "ghost" of the camera app (ie, only its shadow), like in this bug: https://bugs.launchpad.net/bugs/1474319
[17:26] <dandrader> greyback_, so it seems to be a pre-existing isse that at least my refactoring brought to light, via that assertion