[08:30] <pstolowski> cimi, morning!
[10:02] <pstolowski> cimi, there?
[10:05] <cimi> pstolowski, yes
[10:15] <pstolowski> cimi, hey! do you plan any more changes to https://code.launchpad.net/~cimi/unity8/single-preview/+merge/286646 ? can you get a review? i'd like to start full testing
[10:15] <cimi> pstolowski, fixing tests basically
[10:16] <cimi> pstolowski, so yeah, starting testing wouldnt be bad,,,
[10:16] <cimi> ...
[10:16] <pstolowski> cimi, i think we should get your branch approved first
[10:17] <pstolowski> cimi, since it's a non trivial change, that kind of stuff usually gets some comments
[11:14] <tsdgeos> ltinkl: you taking care of https://code.launchpad.net/~unity-team/unity8/launcher-updates/+merge/286393 and https://code.launchpad.net/~unity-team/unity8/launcher-sizing/+merge/286396 ?
[11:15] <tsdgeos> cimi: you reviewing https://code.launchpad.net/~ken-vandine/unity8/share_data_uri_string/+merge/286676 ?
[11:15] <cimi> tsdgeos, it's more tricky, afaics we want array not string
[11:16] <tsdgeos> why do we want array?
[11:16] <cimi> tsdgeos, I am looking into tests on my single preview branch, it seems I have some fails on code I didn't touch :O
[11:16] <tsdgeos> like?
[11:16] <cimi> tsdgeos, if we want to share more than one thing. For example more than one image in some preview
[11:16] <tsdgeos> have you read the emails?
[11:17] <cimi> I did mmm
[11:17]  * cimi reads again
[11:17] <tsdgeos> somehow i remember reading contenthub only worked on a single item
[11:17] <tsdgeos> but now i can't find it
[11:17] <cimi> tsdgeos, yeah that shows a bug for sure
[11:18] <cimi> tsdgeos, as well as ken fix removes the array
[11:18] <cimi> tsdgeos, we need to have both working I suppose
[11:18] <tsdgeos> ok, please comment on the MR if it's wrong
[11:19] <cimi> tsdgeos, http://paste.ubuntu.com/15169625/
[11:20] <ltinkl> tsdgeos, yup
[11:20] <tsdgeos> cimi: ok
[11:20] <tsdgeos> ltinkl: cool
[11:20] <cimi> tsdgeos, so I need to make qml/js check if is an array or a string
[11:20] <pstolowski> cimi, tsdgeos if possilble we should detect if 'uri' is a single string or array of strings, and deal with it
[11:21] <cimi> tsdgeos, and add a test
[11:21] <cimi> support both basicallt
[11:21] <cimi> pstolowski, I originally thought the scope author would had to embed a string inside an array
[11:22] <cimi> like I think it is happening if my app preview in the ubuntu store has only one screenshot?
[11:23] <tsdgeos> cimi: yeah you can do that with typeof probably
[11:24] <cimi> tsdgeos, will have a look later
[11:24] <tsdgeos> k
[11:24] <tsdgeos> cimi: what tests you say are failing?
[11:25] <cimi> tsdgeos, testDash
[11:25] <tsdgeos> cimi: which test specifically?
[11:25] <tsdgeos> i mean you're kind of touching things inside the dash
[11:25] <cimi> qmltestrunner::Dash::test_manage_dash_move_current(), qmltestrunner::Dash::test_manage_dash_move_current_click_other(), qmltestrunner::Dash::test_close_temp_scope_preview_opening_scope()
[11:26] <cimi> tsdgeos, I am seeing if they fail in activation-progress branch
[11:26] <cimi> just noticed they were failing, so I am digging down first
[11:27] <tsdgeos> k
[11:28] <pstolowski> cimi, no worries, it probably escaped us.. this is what i think we discussed & i documented in the api - http://bazaar.launchpad.net/~unity-team/unity-scopes-api/trunk/view/head:/src/scopes/PreviewWidget.cpp (scroll to 'Content sharing')
[11:28] <pstolowski> "uri A single URI to share or an array of URIs"
[11:38] <cimi> tsdgeos, can you try testing dash in activation progress?
[11:38] <tsdgeos> sure, do you get failures there too?
[11:38] <cimi> tsdgeos, activation-progress plus my changes to the mocks have the exact same fails
[11:38] <cimi> tsdgeos, but I have the silo installed, so to test without my mock I have to uninstall the silo..
[11:38] <tsdgeos> k
[11:39] <tsdgeos> give me a min
[11:39] <tsdgeos> well some mins :D
[11:51] <tsdgeos> mphf
[11:52] <tsdgeos> pstolowski: lp:~stolowski/unity-api/activation-progress/ is outdated, no? can you remerge it so that i can test that one alone?
[11:54] <pstolowski> tsdgeos, merged trunk, note the version bump of changelog is done in single-preview branch in the same silo
[11:54] <oSoMoN> greyback_, I commented on https://code.launchpad.net/~gerboland/webbrowser-app/formFactor-support/+merge/286790
[12:08] <tsdgeos> cimi: looks good http://paste.ubuntu.com/15169819/
[12:09] <cimi> tsdgeos, thanks
[12:09] <cimi> tsdgeos, it must be something in my mocks thewn
[12:09] <tsdgeos> probably
[12:23] <Saviq> tsdgeos, qmenumodel failed QA https://trello.com/c/fXKsauE3/2784-1013-ubuntu-landing-015-qmenumodel-saviq
[12:24] <tsdgeos> booo
[13:00] <cimi> tsdgeos, mock fixed
[13:03] <cimi> tsdgeos, still more tests to fix (on GenericScopeView now) - I'll let you know when you can review then
[13:14] <tsdgeos> cimi: oka
[13:28] <mterry> tsdgeos, when you have cycles this week, https://code.launchpad.net/~mterry/unity8/relock-during-tutorial/+merge/285631 can use another look
[13:28] <tsdgeos> mterry: i was just going to do it :)
[13:28] <mterry> :)
[13:29] <mterry> PSA: trunk got infected with bad tags again.  I stripped them from trunk, but it may have spread around already
[13:30] <tsdgeos> damnit
[13:30] <mterry> @unity ^
[13:33] <tsdgeos> mzanetti: lp:~mzanetti/unity8/spread-visual-updates needs tag cleaning
[13:33] <tsdgeos> ltinkl: lp:~lukas-kde/unity8/cascadeWindows needs tag cleaning
[13:33] <ltinkl> tsdgeos, kk
[13:35] <mterry> cimi, if you have cycles this week, can you look at https://code.launchpad.net/~mterry/unity8/narrow-mouse-hack/+merge/284804 (you offered before, not sure if you still have time)
[13:45] <mzanetti> tsdgeos, done
[13:45] <tsdgeos> k
[13:47] <mterry> greyback__, looking at your indicator-menu-height-bindings branch, is there an easy way to test dynamic grid units today?  (like a qmltest that lets you toggle it, or even just a silo?)
[13:51] <greyback__> mterry: nothing too convenient at the moment unfortunately. It is in silo10 right now, but dunno how good that is for you.
[13:52] <greyback__> mterry: there's 1 thing I've hacked up that might help you see the bug, let me email it to you
[13:52] <mterry> greyback__, and there's no easy toggle?  I have to actually hook up to a TV?
[13:53] <greyback__> mterry: yeah. dynamic grid units aren't in a landable state right now, enough was done for the demo
[13:53] <mterry> greyback__, OK.  I have a slimport around here somewhere, I can test it out.  (Code changes look fine, just feel like I ought to actually test it  :))
[13:54] <mterry> greyback__, you mentioned something that made it easier to see the bug?
[13:55] <tsdgeos> mterry: do we care the launcher is not accessible during the tutorial if you lock the screen? i guess not much
[13:55] <mterry> tsdgeos, no... I think that's intentional, at least for the first couple tutorial screens -- we haven't taught them about launcher yet
[13:56] <tsdgeos> ok
[13:56] <tsdgeos> let's leave it like that then
[13:56] <tsdgeos> looks good
[13:56] <mterry> tsdgeos, although maybe I introduced a new bug in that?  :)
[13:56] <mterry> we'll leave it
[13:56] <mterry> :)
[13:56] <tsdgeos> it's not accessible either after we introduced the launcher
[13:56] <mterry> tsdgeos, can you use it in greeter after first screens?
[13:56] <greyback__> mterry: getting there, want to check it does show you the bug. stand by
[13:56] <mterry> tsdgeos, hmm
[13:56] <tsdgeos> mterry: no, but i think it'd be weird too probably
[13:57] <mterry> tsdgeos, ah.. probably because in the past when you couldn't lock the screen, we just disabled the launcher in the greeter if the tutorial is running at all (since that state only happened right before you entered tutorial)
[13:59] <mterry> tsdgeos, if you could pull it out, you could launch apps...  which would be weird in the middle of tutorial to do
[13:59] <mterry> tsdgeos, (though we should handle that fine -- we're built to just dismiss tutorial if an app launches)
[13:59] <tsdgeos> mterry: yep, i'd say leave it as is, i can see the usefulness of locking it if you don't want to finish the tutorial because you're in a hurry
[13:59] <tsdgeos> but launching an app...
[13:59] <mterry> tsdgeos, ok
[14:00] <greyback__> mterry: you got mail
[14:00] <mterry> tsdgeos, (the tutorial is getting a whole redesign in the medium term anyway)
[14:00] <mterry> greyback__, awesome
[14:00]  * greyback__ popping to shops, back in 5
[14:13] <cimi> mterry, I can do this week yeah
[14:13] <mterry> cimi, cool thanks!
[15:45] <mterry> Saviq, silo 10 gives me non-animated indicator motion (I let go with my finger and the indicator warps to bottom of screen or top).  Is that known?
[15:49] <Saviq> mterry, what device?
[15:50] <mterry> Saviq, mako (just in phone mode, not testing convergence)
[15:50] <ltinkl> mterry, Saviq: here too, N4
[15:50] <Saviq> mterry, ltinkl, yeah we've noticed that, not sure what's causing it yet
[15:50] <ltinkl> it stops in the middle of screen and then jumps to bottom/top
[15:50] <mterry> Saviq, k
[15:50] <Saviq> mzanetti, not just frieza after all ↑
[15:51] <tsdgeos> ltinkl: which sile was https://code.launchpad.net/~lukas-kde/unity8/kbdLayoutIndicator2/+merge/285736 in, sorry?
[15:51] <mzanetti> Saviq, not happening on flo with latest rc-proposed
[15:52] <ltinkl> tsdgeos, 64
[15:52] <ltinkl> tsdgeos, https://requests.ci-train.ubuntu.com/#/ticket/993
[15:52] <Saviq> mzanetti, oh yeah, silo10-specific, that I know (will keep an eye out on silo 64)
[15:54] <Saviq> oh well
[15:54] <mzanetti> dafuq... I just suspended my notebook by placing flo on it
[15:54] <Saviq> :D
[16:00] <greyback__> mterry: that'll probably be my patch
[16:01] <mterry> greyback__, which?  It's not the indicator-menu-height-bindings one -- without that patch, the indicator just hangs where it is.
[16:02] <greyback__> mterry: huh ok. I suspected my lousy code
[16:02] <Mirv> jhodapp: tsdgeos: any update on the ticket https://requests.ci-train.ubuntu.com/#/ticket/939 / bug #1534776 ? is it pending on the larger discussion about how roles would be used that has been ongoing?
[16:02] <mterry> greyback__, you still have other branches in silo 10 we can blame  :)
[16:02] <greyback__> indeed
[16:02] <mterry> greyback__, I'm going to test indicator-menu-height-bindings in isolation with just the dynamic-grid-units branch
[16:03] <jhodapp> Mirv, no update as I thought you were handling trying the backport
[16:03] <greyback__> mterry: lemme know if you need a hand
[16:04] <tsdgeos> jhodapp: but it needs you updating media-hub, no?
[16:05] <jhodapp> tsdgeos, possibly, haven't had a moment to look into it any further
[16:05] <tsdgeos> ok
[16:06] <jhodapp> tsdgeos, actually it really shouldn't need media-hub to be touched as we should be able to just handle the new audio role types in qtubuntu-media and do a translation there for what media-hub has
[16:06] <Mirv> jhodapp: the backport is there and done since ages, but I do not know what else needs to be landed thus the silo is assigned to you / tsdgeos to add any needed media-hub etc
[16:06] <tsdgeos> jhodapp: right, maybe it's qtubuntu-media
[16:07] <jhodapp> Mirv, I'll add to my list to give that silo a try and just sanity check it
[16:07] <Mirv> jhodapp: and then there was the long e-mail discussion about roles which seemed like would need resolving too before it's ok to land the xenial/upstream roles to vivid
[16:07] <jhodapp> Mirv, yeah indeed, that's still not resolved IMO
[17:09] <tsdgeos> ltinkl: reboot didn't help :/
[17:09] <tsdgeos> i'll try to debug it tomorrow
[17:09] <tsdgeos> since i guess this is supposed to work
[17:33] <mterry> greyback, I can't seem to test the scaling.  Ctrl+Up/Down doesn't do anything or print anything
[17:34] <greyback> mterry: you're on xenial, aren't you?
[17:34] <mterry> greyback, I'm testing on my mako
[17:34] <greyback> mterry: ah, no that won't work.
[17:35] <mterry> greyback, oh why?
[17:35] <greyback> the steps I gave were for testing unity8 on x11
[17:36] <greyback> I now see that my instructions lack that info
[17:36] <greyback> my bad
[17:37] <greyback> and the plugin I sent you is only suited for Qt5.4, so vivid
[17:37] <mterry> greyback, ah.  I'm on xenial anyway on my desktop as well
[17:37] <greyback> sorry, I just don't have good way for people to test dynamic grid units yet
[17:39] <mterry> greyback, ok
[17:40] <mterry> greyback, well I can test that that branch doesn't screw anything up anyway -- and the code changes look fine.  Assuming you are interested in landing it ahead of the rest of the dynamic grid unit stuff
[17:40] <greyback> if it doesn't hurt
[17:50] <mzanetti> lpotter, please ping me when you're on
[18:03] <lpotter> mzanetti: ping
[18:06] <mzanetti> lpotter, hey, that was quick :)
[18:06] <mzanetti> lpotter, about the topic wrt inputinfo josharenson pinged you about
[18:07] <mzanetti> In parallel I was switching unity8 to QtInputInfo. There is the InputInfoManager now, which would do whatever I need. Problem with that is that it is not a model, so we can't put a SortFilterProxy on top.
[18:07] <mzanetti> lpotter, if instead I use the model, I'm missing the count property now with the latest version
[18:08] <mzanetti> I guess I could use a combination of both... however... wanted to hear your opinion on it
[18:11]  * lpotter gulps more coffee
[18:14] <mterry> ltinkl, in your windowOpenCloseAnimations MP, maximized apps aren't animated.  Is that on purpose?  (I forget the intention there)
[18:15] <ltinkl> mterry, windows going into maximized state?
[18:15]  * ltinkl checks
[18:15] <ltinkl> mterry, but yeah, the intention of this MP is to provide animations when the windows (dis)appear
[18:16] <mterry> ltinkl, opening and closing windows that are maximized
[18:16] <mterry> ltinkl, I'm trying from silo 6
[18:16] <mterry> 64
[18:19] <lpotter> mzanetti: are you wanting the count( InputType ) ?
[18:19] <ltinkl> mterry, hmm I do get those here
[18:20] <mzanetti> lpotter, yes... in the end, for my particular use case it's about the count. but we need to filter some mock devices
[18:20] <ltinkl> mterry, definitely for closing, the maxed window gets a bit smaller and fades in opacity a bit
[18:20] <ltinkl> mterry, restarting the maxed app otoh isn't very obviously visible
[18:20] <lpotter> mzanetti: I see no reason why that cannot be added to the model
[18:21] <mzanetti> lpotter, but I just realize there's another issue with that... We have a generic UnitySortFilterProxyModel which can filter models, but only if the roles enum is exposed to QML as Q_ENUM...
[18:22] <mzanetti> which it isn't and I'm really not sure if that makes sense for upstream
[18:22] <lpotter> already exposed by Q_ENUMS
[18:22]  * mzanetti checks again
[18:22] <mzanetti> oh..
[18:22] <mzanetti> well, in that case
[18:23] <mzanetti> yes, the count property in the model would help us
[18:23] <lpotter> there is rowCount
[18:23] <lpotter> but it is named count currently
[18:24] <mterry> ltinkl, ugh my irc is awful, if you commented to me I missed it.  Best to talk in MP. I'll leave a note there
[18:24] <mzanetti> lpotter, it'd just require this one line I think "Q_PROPERTY(int count READ rowCount NOTIFY countChanged)"
[18:24] <mzanetti> lpotter, and emitting the countChanged signal accordingly
[18:24] <ltinkl> mterry, ok :)
[18:26] <lpotter> mzanetti: ok. it does have rowCountChanged already, but seems to not be emitted ever :)
[18:26] <lpotter> no worries, I'll fix it up
[18:26] <mzanetti> lpotter, hah :D
[18:26] <mzanetti> lpotter, ok, awesomes
[18:27] <mzanetti> josharenson, FYI ^
[18:32] <lpotter> oh, hang on. I'm looking at my updated and not yet committed changes which have that property/signal... gah
[18:42] <lpotter> can you tell when the caffeine kicked in?
[18:52] <mzanetti> not exactly, no :D
[18:52] <mzanetti> but might be because I'm running out of it
[18:52] <lpotter> :)
[20:29] <dandrader> AlbertA, hey
[20:29] <AlbertA> dandrader: hey
[20:29] <dandrader> AlbertA, qtmir sends close request to a qtubuntu client
[20:30] <dandrader> AlbertA, client receives it and calls mir_surface_release_sync upon destruction of its UbuntuWindow
[20:30] <dandrader> AlbertA, but in qtmir I'm not getting anything telling me that this surface is gone
[20:30] <dandrader> AlbertA, what should I expect to receive?
[20:31] <dandrader> AlbertA, that's on a multi-surface application, by the way
[20:31] <dandrader> AlbertA, so the application is still running as it still has another top-level surface up
[20:31] <dandrader> AlbertA, I wonder if it ever worked, as in a single-surface-per-app model, the app would quit anyway
[20:32] <AlbertA> you should expect a remove_surface in the window manager
[20:32] <dandrader> AlbertA, hmmm.... I guess qtmir doesn't have that wired up yet
[20:32] <dandrader> AlbertA, will look into it. thanks!
[20:32] <AlbertA> dandrader: oh well there you go!
[20:56] <dandrader> AlbertA, ni response to MirWindowManager::remove_surface, should I call something to delete the surface or is it already going away?
[20:56] <dandrader> AlbertA, s/ni/in
[20:56] <dandrader> AlbertA, ie, is any action required from qtmir side or is it just an informative callback?
[20:57] <AlbertA> dandrader: you can think of it as informative, to delete any resources you may have created on your side, related to the surface in question
[20:58] <dandrader> AlbertA, so no need for qtmir to call mir::scene::Session::destroy_surface on it?
[20:59] <AlbertA> umm actually. let me se....
[21:00] <dandrader> AlbertA, because I'm not getting a mir::scene::SessionListener::destroying_surface for it...
[21:01] <AlbertA> so right now you inherit from mir::shell::WindowManager?
[21:02] <AlbertA> so yeah our default window manger in mir will call Session::destroy_surface
[21:03] <AlbertA> which is in CanonicalWindowManagerPolicy::handle_delete_surface
[21:04] <josharenson> mzanetti: So, as long as lpotter exposes the count, should my existing solution (w/ unitysortfilterproxymodel) work?
[21:05] <AlbertA> dandrader: so yeah since you have your own window manager, you'll have to call that Session::destroy_surface yeah...
[21:05] <dandrader> AlbertA, ok, thanks