[08:37] <Mirv> tsdgeos: the AP is in the PPA. the test case seemed fixed for me too, but it'd look like running full UITK test suite just hangs at some point - in the sense the test app is loaded but it stays there.
[08:50] <Mirv> I killed now one process and will see if the current run finishes eventually
[08:55] <tsdgeos> ok
[08:56] <tsdgeos> i'm also a bit concerned about richard's report of the addressboox app hanging
[08:57] <tsdgeos> trying to reproduce
[09:20] <tsdgeos> i can't reproduce richard's issue
[09:22] <tsdgeos> Cimi: can you do https://code.launchpad.net/~aacid/unity8/urldispatcher_hideeverything/+merge/253527 ?
[09:22] <tsdgeos> and someone https://code.launchpad.net/~aacid/unity8/passphrase_kewboard/+merge/253657 ?
[09:51] <tsdgeos> pstolowski: commented on https://code.launchpad.net/~stolowski/unity-api/filters-iface/+merge/252890
[09:52] <pstolowski> tsdgeos, thanks, looking
[10:01] <pstolowski> tsdgeos, is this also a problem with roles, do I need to avoid "id" in role names?
[10:02] <tsdgeos> pstolowski: roles are fine since they're not objects per se
[10:02] <tsdgeos> afaik we have have some other id roles
[10:02] <tsdgeos> in there
[10:02] <tsdgeos> yeah
[10:03] <tsdgeos> ./include/unity/shell/scopes/ScopesInterface.h:109:        roles[RoleId] = "id";
[10:03] <pstolowski> yeah, you're right
[10:03] <pstolowski> thanks
[10:14] <pstolowski> tsdgeos, about your second comment, i can added optionsChanged signal, but it will never be triggered since any changes are changes to options rows (model changes)
[10:14] <pstolowski> tsdgeos, makes sense?
[10:14] <tsdgeos> pstolowski: is the options varaible set correctly on creation alrady?
[10:15] <pstolowski> tsdgeos, yes, it's going to be set on creation of the filter only
[10:15] <tsdgeos> then it's fine
[10:15] <pstolowski> tsdgeos, fine to add but never trigger?
[10:15] <tsdgeos> yes
[10:16] <pstolowski> ok
[10:54] <Mirv> hmm. so slow.
[11:03] <tsdgeos> dednick: i think we should do the same thing i did for all the drags and see fi that helps
[11:03] <tsdgeos> since it seems it may very well be that
[11:03] <tsdgeos> looking at the logs the last movement is very few pixels
[11:47] <alan_g> greyback: does MirSurfaceManager have any reason to hold m_mirServer? I don't see it being used.
[11:52] <greyback> alan_g: quite right, it is unused
[11:52]  * greyback expcted compiler to notice that
[11:52] <greyback> no actually, that would be presumptuous of it
[11:53] <alan_g> The compiler knows there's a non-trivial dtor
[11:54] <alan_g> I just wanted to double check there isn't a weird lifetime issue.
[11:56] <greyback> none I'm aware of, this it an oversight
[12:15] <buggatti> Hello. I am trying to boot a 15.04 next live cd. Whenever i enter the username ubuntu-desktop-next and password, its stuck at login. i can move the cursor around but it wont let me in the gui
[12:54] <alan_g> greyback: not urgent, but would something like this make sense to you? https://code.launchpad.net/~alan-griffiths/qtmir/spike-using-WindowManager/+merge/254235
[12:58] <greyback> alan_g: looks reasonable at first glance. You've got work to do to replace our custom input dispatcher with the handle_*_event bits, but nothing huge. Direction looks good
[12:59] <alan_g> greyback: I don't *have* to change that. (At least not for a stable form.)
[13:00] <greyback> alan_g: true
[13:01] <greyback> alan_g: question, would "handle_*_event" supposed to communicate things like close event or focus/unfocus? A nested compositor would probable need to know such things
[13:02] <alan_g> BTW how do you go about building the stack and deploying on a phone? Every time I try I can't help feeling there's a better way...
[13:03] <greyback> alan_g: either building on device, or an sbuild chroot
[13:03] <greyback> if you disable tests building, dev on device isn't so bad
[13:04] <alan_g> How do you get space on the device to install the build tools?
[13:04] <greyback> I don't hit that issue usually
[13:05] <greyback> if you're changing mir too, then yeah, that's a problem
[13:05] <alan_g> Well, it is up to the WM to set focus etc, so yes
[13:06] <alan_g> I can probably work around that.
[13:06] <alan_g> Gotta go
[13:06] <greyback> enjoy
[13:30] <larsu> *giggle* "
[13:30] <larsu> Please note that Antti's "Disapprove" review is a joke.
[13:50] <tsdgeos> @unity: guys my unity8 is not accepting any touch at all
[13:50] <tsdgeos> http://paste.ubuntu.com/10683845/
[13:52] <tsdgeos> any clue?
[13:53] <tsdgeos> greyback: thread 22 suspicious?
[13:53] <dandrader> tsdgeos, no
[13:53]  * tsdgeos gets more debug symbols
[13:53] <greyback> tsdgeos: thread 22 in that state means the main loop is blocked
[13:54] <tsdgeos> greyback: that sounds bad
[13:54] <tsdgeos> :D
[13:54] <greyback> yeah
[13:54] <greyback> it is mir asking qt to authorize an application connection
[13:54] <greyback> and is waiting for a blockingqueuedconnection to return
[13:54] <tsdgeos> yet
[13:54] <tsdgeos> on screen
[13:55] <tsdgeos> i have soemthing that used to be a sdk test application
[13:55] <tsdgeos> that is not even running anymore
[13:55] <greyback> renderer is blocked too then
[13:57] <tsdgeos> greyback: anything else more i can do than filing a bug?
[13:58] <greyback> tsdgeos: is anything using lots of cpu? is dbus busy?
[13:58] <greyback> I don't see a good clue in that BT sadly
[13:58] <tsdgeos> cpu is idle
[13:58] <tsdgeos> dbus-monitor says nothing
[13:58] <greyback> ok
[13:59] <greyback> can you get the thread names
[13:59] <tsdgeos> sure
[14:00] <tsdgeos> greyback: http://paste.ubuntu.com/10683891/
[14:00] <greyback> tsdgeos: any ide what those pool threads are?
[14:00] <greyback> idea
[14:00] <tsdgeos> greyback: gio
[14:01] <tsdgeos> which we don't use but somehow we're stuck with afaik
[14:01] <greyback> hmm ok
[14:02] <greyback> tsdgeos: oh hang on, thread 9 is weird
[14:02] <greyback> that's the render thread
[14:03] <greyback> it's blocked waiting for a new buffer from mir
[14:03] <tsdgeos> mir is still unity8 here, no?
[14:03] <tsdgeos> or is it usc?
[14:03] <greyback> yeah, mir is a lib unity8 uses
[14:03] <tsdgeos> any clue which thread shuould supply that buffer?
[14:05] <greyback> not sure, I suspect thread 23 but am not sure
[14:05] <greyback> asking mir folk...
[14:05] <greyback> tsdgeos: please log a bug anyway, including unity8.log
[14:06] <tsdgeos> k
[14:06] <tsdgeos> i'll get some more debug symbols intsalled
[14:06] <tsdgeos> greyback: this is not "hard" to get it seems
[14:06] <tsdgeos> happens if you run the sdk suite
[14:07] <greyback> hmm
[14:07] <greyback> not what I like to hear :(
[14:07] <tsdgeos> seems more easily if you have the silo we have that makes qt dbus locking less
[14:08] <tsdgeos> but there's nothing that would seem to blame qtbus in that bt
[14:08] <tsdgeos> i'll note it in the bug anyway
[14:08] <tsdgeos> just in case
[14:11] <greyback> tsdgeos: what mir version?
[14:29] <tsdgeos> QQuickAsyncImageProvider merged \o/
[14:38] <greyback> tsdgeos: nice one
[14:38] <greyback> tsdgeos: link? We backported to 5.4?
[14:40] <tsdgeos> greyback: not yet
[14:40] <tsdgeos> greyback: https://codereview.qt-project.org/#/c/108540/
[14:40] <tsdgeos> only needed 17 patchsets :D
[14:41] <tsdgeos> and https://code.launchpad.net/~aacid/thumbnailer/asyncprovider is our counterpart
[14:41] <tsdgeos> which i think doesn't compile now
[14:41] <tsdgeos> since i had to change stuff upstream to make them happy
[14:42] <greyback> tsdgeos: no worries. just wanna be familiar with the api
[14:42] <tsdgeos> there's not much
[14:42] <tsdgeos> basically you get a job
[14:42] <tsdgeos> and then you signal done()
[14:42] <tsdgeos> it's up to you to spawn threads and stuff
[14:42] <tsdgeos> i think it's not done() but finished()
[14:42] <tsdgeos> :D
[14:42] <tsdgeos> but you know what i mean
[14:48] <greyback> gotcha
[15:19] <tsdgeos> lol
[15:19] <tsdgeos> make testDialogs was doing nothing
[15:19] <tsdgeos> :D
[15:20] <tsdgeos> Mirv: \o/
[15:20] <tsdgeos> Loading tests from: /usr/lib/python3/dist-packages
[15:20] <tsdgeos> Tests running...
[15:20] <tsdgeos> Ran 365 tests in 2579.659s
[15:20] <tsdgeos> OK
[15:20] <tsdgeos> greyback: that silo seems ot really help
[15:20]  * tsdgeos launches again
[15:21] <greyback> tsdgeos: sweet
[15:21] <Mirv> tsdgeos: good that you caught me still, I can still launch a 018+013 full suite then now
[15:23] <Mirv> and, \o/ if a working combo of Mir + Qt + Autopilot is found
[15:23] <tsdgeos> he he
[15:24] <tsdgeos> mzanetti: test updated https://code.launchpad.net/~aacid/unity8/passphrase_kewboard/+merge/253657
[15:26] <tsdgeos> Mirv: you probably need my autopilot change too, do you have that one?
[15:27] <mzanetti> tsdgeos, ack
[15:27] <Mirv> tsdgeos: hmm? you mean the one I submitted to ap1.5 and added to the PPA, or something new?
[15:28] <tsdgeos> Mirv: that one
[15:28] <tsdgeos> ah didn't know you had it in the ppa already
[15:28] <tsdgeos> good then
[15:28] <Mirv> tsdgeos: right, the MP is there in the PPA.
[15:28] <dandrader> tsdgeos, yeah, it's there only for its "try" version
[15:29] <tsdgeos> dandrader: lol right i broke the try now
[15:57] <tsdgeos> mzanetti: there was no test for this functionality https://code.launchpad.net/~aacid/unity8/urldispatcher_hideeverything/+merge/253527 originally
[15:58] <tsdgeos> but i guess i can write one for my fix
[15:58] <tsdgeos> and for the feature itself
[15:58] <tsdgeos> will take a bit but it's good to have another test
[16:22] <faenil> tsdgeos: can any of the properties of a Result be used as a unique id?
[16:22] <faenil> to look for an item and similar tasks
[16:22] <tsdgeos> pstolowski: ↑↑
[16:22] <faenil> uri is probably not unique enough
[16:24] <tsdgeos> faenil: result is
[16:24] <tsdgeos> since it's basically the pointer
[16:24] <tsdgeos>         case RoleResult:
[16:24] <tsdgeos>             return QVariant::fromValue(std::static_pointer_cast<unity::scopes::Result>(m_results.at(index.row())));
[16:24] <tsdgeos> not sure the mock implements it that way
[16:24] <tsdgeos> if it doesn't it should :D
[16:25] <tsdgeos> or at least return something that is unique
[16:26] <faenil> tsdgeos: in the mocks it's a string
[16:26] <faenil> but ok, thanks!
[16:26] <tsdgeos> faenil: but is it unique?
[16:26] <faenil> yeah,
[16:27] <tsdgeos> then it's "ok2
[16:27] <tsdgeos> "
[16:31] <pstolowski> faenil, none of the results' attributes should be treated as a key, we do not impose any constraints on any values to be unique.. as tsdgeos says you may relay on the pointers, but this is of course a hack/workaround. note, when you do a new search or refresh, you get new result instances even though the data looks the same
[16:33] <faenil> pstolowski: mmm ok...
[16:33]  * tsdgeos missed something
[16:33] <tsdgeos> what's the ok for?
[16:34] <pstolowski> faenil, on new search we basically wipe the model and create new result instances
[16:34] <faenil> pstolowski: I see
[16:34] <faenil> tsdgeos: in reply to pstolowski
[16:34] <tsdgeos> oki
[16:36] <pstolowski> tsdgeos, fyi "faenil, none of the results' attributes should be treated as a key, we do not impose any constraints on any values to be unique.. as tsdgeos says you may relay on the pointers, but this is of course a hack/workaround. note, when you do a new search or refresh, you get new result instances even though the data looks the same"
[16:37] <tsdgeos> sure
[16:37] <tsdgeos> i meant that for a given set of results
[16:37] <tsdgeos> you can use the pointer as key
[16:37] <tsdgeos> but won't be stable or regresh or something
[16:37] <pstolowski> tsdgeos, ok.. i didn't know what is it for
[16:38] <tsdgeos> pstolowski: me neither :D
[17:58] <om26er> mzanetti, Hi! who is the best person for bug 1436982 ?
[17:59] <om26er> actually it should be dednick ^
[17:59] <mzanetti> probably
[17:59] <mzanetti> let me try to reproduce
[18:02] <om26er> 'Clear all' button.
[18:02] <mzanetti> yeah... so far not happened. but only had telegram notifications in it. let me try with a missed call
[18:05] <om26er> mzanetti, same happens when you change volume from sound Menu
[18:06] <om26er> when notification appears, try to flick close the menu up
[18:06] <mzanetti> hmm... no problem here...
[18:06] <mzanetti> om26er, maybe try checking if unity8.log prints something suspicious
[18:09] <om26er> mzanetti, on rtm right now, will flash and update you/bug_report.
[18:16] <dednick> mzanetti, om26er: yeah, that's probably me.
[18:16] <mzanetti> ack
[18:22] <om26er> dednick, mzanetti try to clear while the notification is still on screen.