[09:21] <tsdgeos> anyone has an idea of why indicator-keyboard would not work at all under unity7?
[09:29] <tsdgeos> cimi: you there?
[09:40] <cimi> tsyes
[09:52] <Saviq> tsdgeos, gsettings list-recursively com.canonical.indicator.keyboard ?
[09:52] <tsdgeos> Saviq: fixed it
[09:52] <Saviq> kk
[09:52] <tsdgeos> the keyboard plugin for the settings daemon was disabled for some unknown reason
[09:55] <cimi> tsdgeos, yeah
[09:55] <tsdgeos> cimi: thanks, i figured it out myself already
[09:55] <cimi> oki
[10:32] <tsdgeos> ltinkl: ping
[10:43] <mzanetti> Mirv, when you have some moments, please kick a rebuild of the inputinfo silo
[10:58] <ltinkl> tsdgeos, pong
[10:58] <tsdgeos> ltinkl: see the MR comment
[10:59] <ltinkl> tsdgeos, ah right, the test needs moving probably, will fix
[11:06] <pstolowski> cimi, hey, how is the situation with single-preview looking?
[11:06] <cimi> pstolowski, running tests
[11:07] <pstolowski> ack
[11:07] <tsdgeos> ltinkl: make xvfbtestShell FUNCTION="Shell::test_inputEventsOnEdgesEndUpInAppSurface" also fails in your branch but since it passes in silo64 branch i guess we can "ignore" it
[11:07] <Mirv> mzanetti: hmm, it's already in QA queue since you said it's ok to go?
[11:07] <Mirv> mzanetti: should I ask QA to remove it?
[11:07] <ltinkl> tsdgeos, I guess mzanetti fixed it in another branch in that silo
[11:08] <cimi> pstolowski, I think tests are passing
[11:09] <cimi> tsdgeos, can you have a look at my single preview branch?
[11:09] <pstolowski> cool
[11:09] <pstolowski> lunch time..
[11:10] <tsdgeos> cimi: sure
[11:11] <tsdgeos> cimi: you still need to fix the "needs fixing" i did yesterday
[11:12] <cimi> tsdgeos, I did merge in activation progress
[11:13] <cimi> it says nothing to be merged
[11:13]  * cimi checks again
[11:13] <tsdgeos> cimi: the other needs fixing
[11:13] <cimi> ok
[12:01] <cimi> tsdgeos, is the MP fine now? Updated the commit and description message
[12:02] <tsdgeos> cimi: need to review it now :D
[12:10] <tsdgeos> cimi: in which silo do you guys have this stuff?
[12:10] <cimi> tsdgeos, 76
[12:10] <cimi> tsdgeos, let me rebuild
[12:10] <tsdgeos> ktx
[12:29] <tsdgeos> cimi: there?
[12:34] <cimi> tsdgeos, yes
[12:34] <tsdgeos> cimi: any reason we need the previewLoader in PreviewView.qml ?
[12:35] <tsdgeos> would just having the Previews.Preview in there be as good/better?
[12:35] <tsdgeos> food!
[12:36] <cimi> tsdgeos, maybe, or we can play with the "active" property and do some checks on the model
[12:37] <cimi> tsdgeos, I initially thought the model might be missing something so as a transition from the PreviewListView I used a loader, but i then removed the active property I was using so
[13:45] <tsdgeos> cimi: i'd prefer if you remove the loader
[13:45] <tsdgeos> should remove some complexity from the code
[14:12] <mterry> Saviq, remember how we asked for feedback from Alex (from design) about the warn-on-launching-xapp dialog?  Did we ever get that?
[14:12] <Saviq> mterry, not in my inbox
[14:12] <mterry> Saviq, I'll poke paty
[14:12] <ltinkl> tsdgeos, kbdIndicator test fixed
[14:12] <tsdgeos> tx
[14:17] <mterry> Saviq, sent another email, this time with Paty on cc too...  :-/
[14:18] <Saviq> kk
[14:18] <tsdgeos> ltinkl: but then we're not testing the shortcuts with this new test, no?
[14:19] <ltinkl> tsdgeos, hmm, right, I'll have to add a new test for that, the logic changed a bit
[14:19] <tsdgeos> ltinkl: could you add it?
[14:19] <ltinkl> tsdgeos, sure
[14:19] <tsdgeos> awesome
[14:20] <dandrader> does anybody know how can I stop that spam in unity8.log? "loadExtendedAttributes: menu item does not contain 'x-canonical-scroll-action'"
[14:27] <Saviq> dednick, ↑
[14:28] <dednick> dandrader: Saviq: https://code.launchpad.net/~nick-dedekind/qmenumodel/logging-categories
[14:28] <dandrader> dednick, thanks
[14:30] <mterry> ltinkl, so libtimezonemap pulls in gtk?  That's another reason to use geonames
[14:30] <dednick> although i dont really like the fact that i'm logging it as debug...
[14:30] <dednick> maybe should make it warning; and only log out critical...
[14:31] <ltinkl> mterry, hmm it probably does with the widget... that we're not using
[14:31] <mterry> ltinkl, I know system settings uses it too, but we should try to minimize use I guess
[14:32]  * ltinkl nods
[14:32] <ltinkl> mterry, do they plan to get rid of it?
[14:32] <mterry> ltinkl, I believe system settings intends to port, yet
[14:32] <mterry> *yes
[14:33] <ltinkl> mterry, ok, then we might want to coordinate with them, when it happens
[14:34] <mterry> ltinkl, working on coordinating
[14:37] <ltinkl> mterry, great, thanks!
[14:58] <tsdgeos> mzanetti: maybe you can do https://code.launchpad.net/~aacid/unity8/deprecatedNetworkingStatus/+merge/286350 ?
[14:59] <mzanetti> tsdgeos, ack
[15:05] <mzanetti> pstolowski, tsdgeos, cimi: your opinion about this? https://code.launchpad.net/~ken-vandine/unity8/share_data_uri_string/+merge/286676
[15:06] <cimi> mzanetti, pstolowski tsdgeos it's an api choice, up to you
[15:06] <cimi> we want to support multiple uri
[15:06] <mzanetti> yes, I would agree we want to support it...
[15:06] <tsdgeos> i thought it was settled you guys wanted to support both single string and array ?
[15:07] <tsdgeos> and that typeof was needed?
[15:07] <mzanetti> ah ok... I missed that
[15:07] <mzanetti> but yes, that sounds good
[15:07] <mterry> ltinkl, you're not in #ubuntu-touch?
[15:07] <ltinkl> mterry, now I am :)
[15:13] <pstolowski> cimi, mzanetti i'm not sure what the proposed change does tbh. or are you asking whether we should rename from 'uri' to 'uris'?
[15:13] <mzanetti> pstolowski, yeah... that, or support both I guess
[15:14] <mzanetti> so either we rename it "uris" and use the typeOf() thing to see if its an array or a single one
[15:14] <mzanetti> or we add uri and uris
[15:14] <mzanetti> IMO
[15:17] <tsdgeos> mzanetti: or just use uri and it can be a string or an array, smaller change, just needs a change in our side
[15:17] <tsdgeos> even if the name is a bit confusing, noone will die :D
[15:17] <pstolowski> mzanetti, yeah, i second that
[15:17] <pstolowski> what tsdgeos says
[15:18] <mzanetti> kk then... wfm
[15:19] <mzanetti> do we have some documenting text that this can be a list?
[15:19] <mzanetti> I really just checked the clock if it's 6pm ^ :D
[15:30] <pstolowski> mzanetti, yes we do
[15:31] <mzanetti> kk then. problem solved. cimi, will you fix that uri thing then?
[15:31] <cimi> mzanetti, sure this afternoon
[15:31] <mzanetti> ack
[15:31] <pstolowski> mzanetti, http://bazaar.launchpad.net/~unity-team/unity-scopes-api/trunk/view/head:/src/scopes/PreviewWidget.cpp
[15:32] <pstolowski> mzanetti, that's how it was documented when content-sharing landed in unity8
[15:32] <pstolowski> mzanetti, (see Content sharing section)
[15:32] <mzanetti> pstolowski, ack. found it. lgtm
[15:36] <mterry> ltinkl, oobe almost ready?  I thought we needed this whole "alternate city names" feature for searching timezones
[15:37] <ltinkl> mterry, not critical... more like would be "nice to have"
[15:37] <mterry> ltinkl, I guess since we match system settings there...
[15:40] <cimi> tsdgeos, we have some code in PreviewListView (check old branch) around a previewData thing when preview close... is this code working?
[15:40] <tsdgeos> cimi: i can't tell for sure, why?
[15:40] <cimi> tsdgeos, looks like I can remove that
[15:40] <cimi> tsdgeos, if you can confirm
[15:41] <tsdgeos> well, why do you want to remove it?
[15:41] <cimi> tsdgeos, I guess is dead code
[15:42] <tsdgeos> cimi: why do you guess that?
[15:42] <tsdgeos> i mean what makes you think it's not needed?
[15:42] <cimi> tsdgeos, what is previewData?
[15:43] <cimi> tsdgeos, Preview.qml has no previewData property
[15:44]  * cimi looks annotation
[15:46] <cimi> tsdgeos, looks like it's there for test previewWidgetFactory and you wrote that?
[15:46] <cimi> nope
[15:46] <mterry> Saviq, I'd like to throw relock-during-tutorial in there, will do so now if you don't object
[15:47] <mterry> (silo 64 that is)
[15:47] <Saviq> mterry, please do
[15:47] <tsdgeos> cimi: hmmm, previewWidgetFactory?
[15:47] <cimi> tsdgeos, nope that was a grep previewData
[15:47] <cimi> :)
[15:47] <tsdgeos> ah, ok
[15:47] <mterry> Saviq, done
[15:48] <Saviq> huh, I wonder, why doesn't mako rotate in windowed mode ¿?
[15:48] <Saviq> mzanetti, any idea ↑?
[15:48] <cimi> tsdgeos, looks like ooooold code http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/494.1.1
[15:48] <cimi> tsdgeos, old API?
[15:49] <Saviq> aah maybe pre-silo 10
[15:52] <tsdgeos> cimi: ok, yeah remove the previewData code, can't find what it'd do
[15:54] <cimi> tsdgeos, and that previewData.cancelAction() ?
[15:54] <cimi> tsdgeos, previewModel has similar actions?
[15:55] <tsdgeos> cimi: i'd say cancelActivation is basically it
[15:55] <tsdgeos> maybe not
[15:55] <tsdgeos> pstolowski: there?
[15:55] <cimi> maybe pawel remembers
[15:55] <cimi> indeed
[15:55] <pstolowski> tsdgeos, y
[15:55] <cimi> pstolowski, we had previewData.cancelAction()
[15:55] <tsdgeos> pstolowski: we have some code that says
[15:55] <tsdgeos> / Cancel any pending preview requests or actions
[15:55] <tsdgeos> and then call cancelAction on something callled previewData
[15:56] <tsdgeos> i can't find any cancelAction on unity-api not unity-scopes-shell
[15:56] <tsdgeos> this is when hiding the preview on the dash
[15:57] <pstolowski> tsdgeos, hmm, interesting. and previewData is what? a PreviewModelInterface object?
[15:57] <tsdgeos> it's a good question
[15:58] <tsdgeos> no, it was somthing that came from a model long time ago
[15:58] <tsdgeos> was called previewData in the model too
[16:00] <tsdgeos> pstolowski: i guess the better question is, do we have to call something else other than scope.cancelActivation(); when closing the preview ?
[16:01] <pstolowski> tsdgeos, still looking
[16:01] <Saviq> tsdgeos, re: orientation bug, easiest to repro on mako is with silo 10, force desktop mode in display indicator, launch camera app, rotate phone
[16:01] <Saviq> bbl
[16:09] <pstolowski> tsdgeos, i think cancelActivation will only have effect on activate requests and action activation and will do nothing for previews. however, when it comes to previews, when you drop preview model instance on the floor it cleans up its stuff, so i don't see any need for explicit calls
[16:09] <tsdgeos> ok
[16:09] <cimi> ok
[16:09] <pstolowski> tsdgeos, so the question is if preview object is properly destroyed on qml side when not needed?
[16:10] <tsdgeos> we will leave cancelActivation since it's there nowadays
[16:10] <cimi> and we had this code that does nothing :D
[16:10] <pstolowski> tsdgeos, preview objects have no cpp owener, so should be taken over by qml
[16:11] <tsdgeos> pstolowski: it should be dropped, yes
[16:12] <tsdgeos> will double check as soon as cimi does the last change
[16:12] <cimi> tsdgeos, I can push now
[16:13] <tsdgeos> go!
[16:16] <cimi> tsdgeos, needless to say that I run tests and now fail without the Loader :D give me 5 mins
[16:16] <cimi> tsdgeos, then I push, really.
[16:17] <tsdgeos> ok :)
[16:30] <cimi> tsdgeos, ok
[16:32] <cimi> tsdgeos, also, silo is rebuilding unity8
[16:32] <tsdgeos> oki
[16:44] <tsdgeos> cimi: code looks good, will do a phone test tomorrow
[16:44] <cimi> tsdgeos, sure thanks
[16:56] <cimi> mzanetti, tsdgeos I'm wondering if this will do the content sharing thing http://paste.ubuntu.com/15181460/
[16:57] <cimi> testing the code is more complicated because it would be basically testing contenthub, and we dont want to
[16:58] <tsdgeos> cimi: well you can test that a single street goes to one place and that an array goes thorugh the other, no?
[16:59] <cimi> tsdgeos, the logic is inside the content picker code, so we will have to test the picker in the qmltest somehow
[16:59] <cimi> iirc
[17:00] <tsdgeos> cimi: you mean that code is executed by the content picker and not us?
[17:02] <cimi> tsdgeos, yeah
[17:03] <tsdgeos> weird
[17:03] <tsdgeos> have to go now, cinema waiting, ping me tomorrow and we can think about it
[19:24] <lpotter> mzanetti: we are targetting qt 5.4 with that qinputinfo?
[19:24] <mzanetti> looks like, yes
[19:27] <lpotter> that's what I thought, just making sure :)