[06:56] <Mirv> mzanetti: hi! can you update on https://requests.ci-train.ubuntu.com/#/ticket/1411 (which is updating just to have it in sync with overlay)? I see in the bug report Pat had a problem with hang with the test app, but no comment from you?
[09:09] <tsdgeos> Mirv: welcome back?¿
[09:12] <Mirv> tsdgeos: that too :)
[12:15] <tsdgeos> Mirv: when you have some time have a look at silo 001
[12:15] <tsdgeos> it has a small patch that'd be nice to land
[12:20] <Mirv> tsdgeos: I have noticed it
[12:21] <Mirv> seems pretty safe and long in 5.5 and 5.6
[12:25] <tsdgeos> yep
[12:25] <tsdgeos> i was trying to get sil2100 to land it but i guess he's been busy
[12:25] <tsdgeos> if you can take over that'd be nice
[12:41] <sil2100> tsdgeos, Mirv: it's in QA's hands since Friday
[12:41] <sil2100> Nothing more can be done with it
[12:41] <tsdgeos> sil2100: ah, awesome
[12:42] <davmor2> sil2100: if this is the blocked silo with your name on then it is blocked :P
[12:42] <sil2100> tsdgeos: sorry it took so long, I was actually almost sure I switched it to Approved looong way ago
[12:42] <tsdgeos> sil2100: no worreis
[12:43] <sil2100> tsdgeos: could you just comment on the trello card in my stead? ;) You know better which UITK test failures it fixes
[12:43] <tsdgeos> sil2100: url?
[12:44] <sil2100> tsdgeos: https://trello.com/c/M75g1XTv/3428-1630-ubuntu-landing-001-qtdeclarative-opensource-src-qtdeclarative-opensource-src-gles-sil2100-tsdgeos
[12:49] <tsdgeos> i have stupid trello trying to format things
[12:49] <tsdgeos> and not having any kind of "what kind of stuppid formatting we use" link
[13:20] <Mirv> sil2100: tsdgeos: right! there's then another qtdeclarative upload to be prepared after that one has landed first, for dandrader
[14:06] <mterry> dednick, is this snap decision dialog doable today without changes on unity8 side?  https://wiki.ubuntu.com/Networking#Inserting_a_new_SIM
[14:06] <mterry> dednick, i.e. can a user specify button color to be red and such?
[14:12] <dednick> mterry: give me a sec
[14:12] <mterry> I see we can set x-canonical-private-rejection-tint...
[14:13] <dednick> dednick: ermmmm.
[14:13] <dednick> i'll have to look at the dialog code.
[14:13] <mterry> dednick, But can't seem to control which button gets the tint?
[14:13] <mterry> It seems strictly based on order
[14:13] <dednick> but should be fairly easy to ascertain
[14:13] <ltinkl> mterry, dednick: I should know
[14:14] <mterry> ltinkl, oh hey ^
[14:14] <mterry> :)
[14:14] <dednick> mterry: i think the order is fixed.
[14:14] <dednick> as in which one is accept action, which one is reject action
[14:14] <ltinkl> mterry, dednick: the order is defined, 0 accept, 1 reject, then everything else
[14:14] <dednick> "as designed"
[14:15] <dednick> sounds entirely straight forward ;)
[14:15] <ltinkl> mterry, dednick: look in Notification.qml, around line 480
[14:15] <mterry> ltinkl, got it...
[14:16] <mterry> ltinkl, dednick: so...  what should we do for this dialog?  :)
[14:16] <ltinkl> "tint" here means the button gets green/red, nothing else
[14:16] <ltinkl> otherwise it's a regular button
[14:16] <mterry> ltinkl, dednick: x-canonical-private-reverse-tints?  :-/
[14:16] <dednick> mterry: well, the red one is the reject one.
[14:16] <mterry> I wish we could associate a tint with a particular action index
[14:16] <dednick> which is button 1
[14:17] <mterry> dednick, that looks like button 0?
[14:17] <dednick> which is "restart" in the picture no?
[14:17] <ltinkl> mterry, not quite sure what you _want_ to achieve :)
[14:17] <ltinkl> dednick, yeah, red == reject, number 1
[14:17] <ltinkl> 0 would be accept
[14:17] <mterry> ltinkl, in that picture, is the Restart Now button index 0 or index 1?
[14:17] <dednick> i would seriously hope the one on the right is 1.
[14:18] <dednick> otherwise we ave a very strange indexing system.
[14:18] <ltinkl> mterry, dednick: the red (restart) is 0
[14:18] <mterry> yeah
[14:18] <ltinkl> as in "accept"
[14:18] <ltinkl> do it now :)
[14:18] <mterry> dednick, buttons go reverse in dialogs
[14:18] <ltinkl> yup, they get filled from the right side
[14:18] <dednick> of course they do!
[14:19] <ltinkl> dednick, as designed :p
[14:19] <mterry> dednick, well there's some thought behind it -- your eye ends up in the bottom right by default -- so we want the "preferred" action there
[14:19] <mterry> GNOME does it too
[14:19] <dednick> mterry: i guess the restart needs to be green then.
[14:19] <mterry> ltinkl, so yeah, thoughts on best way to get that dialog in the spec?
[14:20] <ltinkl> yeah, Gnome and MacOS, the default/accept/OK button is always the rightmost one
[14:20] <mterry> dednick, except it's a destructive action
[14:20] <ltinkl> mterry, just emit a notification
[14:20] <ltinkl> mterry, I suppose from indicator-network?
[14:20] <mterry> ltinkl, right...  but to get the index==0 button to be red...
[14:21] <mterry> dednick, red is for "negative and irreversible actions"
[14:21] <mterry> It just also happens to be the "preferred" action here
[14:22] <ltinkl> mterry, ah... hmm, no better suggestion than patching Notification.qml
[14:22] <dednick> should probably have an x-canonical-private-affirmative-index / x-canonical-private-rejection-index.
[14:23] <mterry> ltinkl, dednick: rejection-tint seems bizarrely specific (in assuming index==1 -- like it was coded only for one dialog).  What about if we supported x-canonical-private-rejection-tint-XXX where XXX is an action index.  And if there isn't an XXX, we assume 1?
[14:23] <ltinkl> dednick, mterry: hmm no... let me come up with a simple patch
[14:23] <ltinkl> shouldn't be too hard
[14:23] <mterry> dednick, ltinkl: oh right, a hint can have a value
[14:23] <mterry> ltinkl, dednick: I like -index
[14:24] <dednick> then we can deprecate the "-tint"
[14:25] <ltinkl> mterry, dednick: https://pastebin.kde.org/p1x46wiug
[14:25] <ltinkl> this should work for both buttons
[14:26] <ltinkl> ah, small correction
[14:27] <dednick> while we're in there somebody should clean that button loader up... why are there 2 repeaters?
[14:27] <dednick> oh, a row and cloumn.
[14:28] <mterry> ltinkl, ah but we don't want both buttons red
[14:28] <ltinkl> yeah, a sec
[14:28] <mterry> ltinkl, dednick: so if we were to implement rection-index, is there anything we need to modify besides unity8's Notification.qml?  LIke any spec or approval we need from someone?
[14:29] <dednick> i have no idea if there is a spec around somewhere
[14:29] <dednick> should be. there are loads of hints.
[14:30] <mterry> dednick, ltinkl: looks like we should expose it in the capabilities in unity-notification
[14:31] <ltinkl> mterry, dednick: yeah, if you add new hints, you should add them also to the unity-notifications backend
[14:31] <ltinkl> shouldn't be a big prob
[14:31] <mterry> dednick, ltinkl: OR....  we could keep going with the bad current hint and assume that if ONLY rejection or affirmative are specified, it should be for index==0...
[14:31] <mterry> That makes some sort of sense to me, without the bother of adding new hints
[14:32] <ltinkl> mterry, then it's break as soon as the other button should be colorized too :)
[14:32] <mterry> ltinkl, yes...  but maybe by then we have proper dialogs  :-/
[14:32] <ltinkl> mterry, I wouldn't bet my socks on that ;)
[14:33] <mterry> ltinkl, well fair enough.  We can do the right thing.  So dednick, ltinkl: any objections to me adding rejection-index and affirmative-index?
[14:33] <ltinkl> mterry, if we can't come up with anything better, sure
[14:38] <mterry> ltinkl, do you mean to say you don't like the -index idea?
[14:38] <ltinkl> mterry, I mean I'm fine with it
[14:39] <ltinkl> mterry, can't see any other (better) way atn
[14:39] <ltinkl> atm
[14:39] <mterry> ltinkl, dednick: from a client point of view, do they name actions or index them?
[14:39] <mterry> like if I'm writing code for an app, and I add actions to a notification
[14:39] <ltinkl> mterry, it's an ordered list
[14:39] <mterry> Do I give it a name or just know the order?
[14:40] <mterry> ltinkl, yeah, but do I also name it?  Like does any part of the api refer to indexes already or is it all names?
[14:40] <ltinkl> mterry, just the order; the format is sth like "actionId:Visible text"
[14:40] <dednick> mterry: it's in a model
[14:40] <ltinkl> mterry, let me verify
[14:41] <mterry> I think they name them... so having them specify name might be nicer
[14:41] <ltinkl> mterry, dednick: the model is a plain string list (with pairs), so every odd number is a label, every even number is the action id
[14:41] <mterry> like it's an ordered list of action names
[14:42] <ltinkl> sorry, the opposite
[14:42] <ltinkl> id+label
[14:42] <dednick> i guess maybe use action name rather than index then
[14:42] <mterry> ltinkl, dednick: yeah.  So I'm thinking "x-canonical-private-affirmative-action=actionId"
[14:42] <ltinkl> mterry, dednick: see MockActionModel.cpp
[14:42] <dednick> x-canonical-private-affirmative-action=plop
[14:43] <dednick> mterry: yup
[14:43] <mterry> So this means you couldn't specify more than one positive / negative button...
[14:43] <ltinkl> mterry, dednick: yup, better identify them by the actionId
[14:43] <mterry> x-canonical-private-affirmative-actionId=true ?
[14:43] <ltinkl> that's also exported to the QML side
[14:43] <mterry> Or maybe that restriction is good...?
[14:43] <dednick> ltinkl: no, i think better not muddle with dynamic hint names
[14:44] <dednick> unless it comes from desigh
[14:44] <ltinkl> dednick, so you suggest x-canonical-private-affirmative-action=plop, where plop is the actionId or index?
[14:44] <dednick> ltinkl: ya
[14:44] <dednick> actionId
[14:44] <mterry> OK, I can go with that.  Designs aren't likely to use multiple affirmatives...
[14:44] <ltinkl> dednick, right, that's what I meant :)
[14:45] <mterry> OK.  x-canonical-private-affirmative-action=actionId
[14:45] <dednick> ltinkl: oh, it was directed at mterry; not you :)
[14:45] <dednick> sorry, you're both showing up as highlight color :)
[14:46] <ltinkl> dednick, mterry: ok then the Notification.qml code should be easy, lines 555-589
[14:46] <mterry> dednick, ltinkl: we could do x-canonical-private-affirmative-actions=actionId1,actionId2,etc
[14:46] <ltinkl> could be a list yeah, more flexible
[14:47] <dednick> mterry: fyi; there's a could of spots using the tint i think
[14:47] <dednick> and you need to make sure the old way works still
[14:47] <mterry> yeah that's fine
[14:47] <mterry> we can support old way
[14:48] <mterry> OK, will prepare some branches.  This is all in service of bug 1332306, btw
[14:48] <mterry> Which I inherited from Mirco!  :)
[14:49] <dednick> :)
[14:51] <mterry> dednick, ltinkl: should we worry about affirmative-actions=... sounding a lot like https://en.wikipedia.org/wiki/Affirmative_action ?
[14:51] <dednick> lol.
[14:51] <mterry> I'm not worried, but still.  Feels weird looking at it in source code
[14:52] <dednick> well i dont think it's trademarked or copywrite; so i think it'll be fine.
[15:27] <ltinkl> dednick, mterry: regarding the most recent comment... why do we need this dialog in the first place? the SIM should be usable without a reboot
[15:28] <dednick> ltinkl: https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1332306
[15:28] <mterry> ltinkl, I don't know the full technical details.  But bug 1332306 gets into it a bit.  I think only some platforms support it or something?
[15:28] <ltinkl> dednick, mterry: yeah, check the last comment
[15:29] <ltinkl> I wouldn't spend much time on the dialog now :)
[15:29] <mterry> ltinkl, ah cool.  OK
[15:29] <mterry> thx  :)
[15:30] <ltinkl> mterry, dednick: I mean, it must be possible without a reboot, some android phones do it (unlike the stock android)
[15:34] <dednick> some network operators require a reboot after picking up new data settings i think.
[15:34] <dednick> but meh.
[17:47] <mterry> ltinkl, on my dogfood phone, I'm seeing "Mute" in indicator-sound instead of "Silent Mode" -- is that expected?
[18:33] <mterry> bregma, is there an easy way to port config over to a libertine container?  Like, my xchat-gnome config and such
[18:33] <mterry> bregma, oh I found the rootfs
[18:34] <bregma> yeah, thye're bind-mounted in
[18:34] <mterry> bregma, oh, what's bind-mounted in?
[18:35]  * mterry wants a way to have libertine just point at my rootfs
[18:35] <mterry> a 'fake' container
[18:36] <bregma> mterry, the root of each container is available in the host OS at ~/.local/share/libertine-container/user-data and bind-mounted into the container
[18:36] <mterry> bregma, got it
[18:37] <bregma> if you;re trying to break out of the container and have your host filesystem used as a 'fake' container you're going to have to work pretty hard
[18:37] <bregma> breaking containment isn't a supported option
[18:37] <mterry> bregma, just would make for easier dogfooding of u8 -- if all my apps didn't lose config.  I know it's not in-scope for libertine.  I actually just want a "native apps" scope
[18:38] <mterry> to hell with confinement for this use case
[18:38] <bregma> that would miss the whole point of containment, then, wouldn't it?
[18:38] <mterry> bregma, yes
[18:38] <mterry> bregma, but I'm actually only interested in dogfooding u8, not confinement right this second
[18:38] <bregma> what you want is to use the snap scope and just use snapcraft to repackage all your apps
[18:39] <bregma> it's just that simple
[18:39] <mterry> bregma, sure, the future is bright.  :)  But dogfooding on the way to that future is not
[18:39] <bregma> dogfooding Unity 8 means following the containment story
[18:39] <bregma> if you;re not using containment and Unity 8, you;re not dogfooding Unity 8
[18:40] <bregma> (you can always hand-craft .desktop files if you really want to bypass containment, but there's no X11 server for you then)
[18:56] <mterry> josharenson, I tried to test chooser-gui on Friday, but the branch hadn't been updated?  Did you not push to LP?
[18:57] <josharenson> mterry: let me check
[18:58] <josharenson> mterry: try pulling now?
[18:59] <mterry> josharenson, got updates!  OK, will retest
[18:59] <josharenson> mterry: cool, sorry about that
[19:07] <mterry> josharenson, also, consider updating from trunk?  get nice focus fixes that way too
[19:11] <josharenson> mterry: will do, gimmie a few min to finish lunch
[19:11] <mterry> josharenson, no rush  :)
[21:56] <mterry> dandrader, still around?  https://code.launchpad.net/~dandrader/unity8/mirSurfaceInputBounds/+merge/298780 has a conflict?
[21:58] <dandrader> mterry, let me check...
[22:01] <dandrader> mterry, no. didn't find any conflict with trunk
[22:02] <mterry> dandrader, LP shows the conflict in debian/changelog
[22:03] <dandrader> mterry, LP web diff can get confused. I tried it locally and it merges fine
[22:03] <mterry> dandrader, why the version bump anyway?
[22:03] <dandrader> mterry, can you reproduce the conflict?
[22:03] <dandrader> mterry, because of ubuntu-keyboard dependencies
[22:03] <dandrader> iinm
[22:04] <mterry> dandrader, I can't reproduce the conflict.  so good I guess