[16:53] <seb128> Saviq, unity8 stack depends on boost 1.60 in yakkety but 1.61 is the version is main, do you know if anyone looking at using that one/would should work on it?
[16:54] <josharenson> Saviq: I see the "enter immediately launches a session" issue... should be a quick fix. How about I make the highlight always orange for now, and then fix it in a separate branch so we can land everything?
[16:54] <Saviq> josharenson, wfm
[16:54] <Saviq> josharenson, also, note I mentioned going < with Enter (I assume, there's no highlight around <) also launched the session here
[16:55] <Saviq> seb128, lemme try and go down the dep graph
[16:55] <josharenson> Saviq: ah the header isn't highlightable. How many different DEs do you have installed
[16:56] <Saviq> josharenson, 4 show up
[16:56] <josharenson> Saviq: either nothing is highlighted (which is a bug) or something not visible is highlighted (which is a bug) but they header is never highlighted
[16:56] <josharenson> (header [16:56] <Saviq> josharenson, might be
[16:56] <josharenson> Saviq: looking into it and making everything orange
[16:57] <josharenson> mterry: some questions about your session-lightdm branch
[16:59] <josharenson> mterry: I'm still seeing the normal unity7 lockscreen when switching users?
[17:01] <Saviq> josharenson, that's internal to unity7
[17:02] <Saviq> it's inside your session (as in unity8 when the greeter's built-in)
[17:02] <josharenson> Saviq: I know, just wondering how mterry was switching users when seeing a lightdm crash (although now that you mention it, he told me it happened regardless of the greeter)
[17:02] <Saviq> ah ack
[17:03] <Saviq> seb128, boost is used across the board, from mir through platform to API guys
[17:03] <Saviq> I suppose a coordinated migration is in order
[17:09] <seb128> Saviq, k, can you get that on some board or talk to whoever can¿
[17:09] <seb128> ?
[17:09] <Saviq> seb128, only question is, can we? thinking vivid and xenial?
[17:09] <seb128> well, if not talk to doko/steve about how we deal with 1.60/61
[17:18] <Saviq> seb128, you say 1.60 in yakkety, we only have 1.58 in vivid, so I suppose we don't have versioned B-Ds, just we need rebuilds so that 1.61 gets picked up?
[17:18] <Saviq> also only 1.58 in xenial
[17:21] <Saviq> ok looks like we just need rebuilds of a few things
[17:23] <Saviq> seb128, can we just push no-change rebuilds to yakkety directly then?
[17:24] <seb128> Saviq, I guess we can
[17:25] <Saviq> seb128, seems like we're not the first ones
[17:25] <Saviq> https://launchpad.net/ubuntu/+source/unity-scopes-api/1.0.6+16.10.20160617-0ubuntu2
[17:25] <Saviq> https://launchpad.net/ubuntu/+source/thumbnailer/2.4+16.10.20160719-0ubuntu2
[17:25] <seb128> k, good
[17:25] <seb128> so should naturally migrate as things land
[17:25] <seb128> thanks Saviq!
[17:25] <Saviq> except they fail to builds
[17:25] <Saviq> -s
[17:25] <Saviq> need bugs for that
[17:26] <Saviq> and libphonenumber on top of those two, that's the only three I found still dep'ing on 1.60
[17:26] <Saviq> filing a bug that they fail to build then
[17:29] <Saviq> seb128, and even being handled in the MIR bug #1613561 #1612461
[17:29] <Saviq> and I believe Ken is releasing a libphonenumber
[17:29] <Saviq> seb128, so all in all, I think it's being worked on, assuming people look at their MIR requests
[18:07] <seb128> Saviq, great, thanks for checking
[18:35] <mterry> Is there an easy way to restrict the normal qml focus chain to one widget hierarchy?  Like, normally Tab will go to the natural next widget, no matter where it lives.  But I want a TabFocusScope style widget to keep it inside its own bubble and wrap around inside that scope...
[18:36] <mterry> (my use case is keeping Tabs inside Shell in tst_Shell.qml and not have it escape to the controls on the right, to more properly emulate real tab conditions)
[18:42] <Saviq> wtf... adds on doc.qt.io search page... https://doc.qt.io/qt-5/search-results.html?q=focusscope
[18:42] <Saviq> mterry, anyway, doesn't FocusScope do it?
[18:43] <mterry> Saviq: I don't see ads there
[18:43] <mterry> Saviq: no it doesn't seem to
[18:43] <mterry> Saviq: and I don't think it should?  Like if you tab on the last element of a FocusScope, I think the expectation is that you go wherever the next focusable item is, even outside it
[18:44] <mterry> But I've never grokked qml focus
[18:44] <Saviq> mterry, TBH I didn't know there was any magic about Tabbing
[18:44] <Saviq> mterry, but I suppose https://doc.qt.io/qt-5/qml-qtquick-keynavigation.html is a place to start
[18:44] <mterry> Saviq: there is an activeFocusOnTab property, that's false by default for everything
[18:44] <mterry> Saviq: and you can set it to be true if you want to be in the focus chain
[18:45] <mterry> which seems to be the "easy" way to do tabbing -- you can do keynavigation if you know all the elements that should be in the chain
[18:45] <mterry> But if you are putting together elements that don't know each other, activeFocusOnTab seems like a more natural fit
[18:45] <mterry> But man, there are so many qml focus properties and schemes
[18:46] <mterry> I get lost on what the best way to do focus is
[18:58] <josharenson> mterry: So SessionsList is forwarding return presses to GreeterPrompt (WideView->LoginList->GreeterPrompt->PromptButton) which causes a passwordless user to instantly login when return is pressed on the SessionsList
[18:58] <josharenson> follow all that?
[18:59] <mterry> I think...
[18:59] <josharenson> mterry: There are several ways this could be handled, none of which I'm happy about as they don't address the issue of why the event is being forwarded, even though SessionsList is accepting it
[18:59] <mterry> via..
[18:59] <mterry>         Keys.onReturnPressed: {
[18:59] <mterry>             sessionChooserButtonClicked();
[18:59] <mterry>             event.accepted = true;
[18:59] <mterry>         }
[18:59] <mterry> right?
[18:59] <josharenson> mterry: yeah, has no effect
[18:59] <josharenson> mterry: well not for this at least
[19:00] <josharenson> mterry: GreeterPrompt sets focus on the button and sends it the returnPressed event
[19:01] <mterry> That would normally make sense, but we don't know why GreeterPrompt gets the return event?
[19:01] <josharenson> mterry: correct... could be considering it as a mouse press I guess
[19:01] <josharenson> maybe just need to eat mouse events
[19:02] <mterry> josharenson: could the handling of sessionChooserButtonClicked be doing something we don't like?
[19:02] <mterry> josharenson: if you move accepting the event up before that, might it help prevent that? (if that's going on at all)
[19:03] <mterry> Me and qml events have never understood each other
[19:03] <josharenson> mterry: I tried that
[19:03] <josharenson> lol
[19:03] <mterry> josharenson: if you simply comment out that clicked signal, does it still happen?
[19:03] <mterry> i.e. are we doing it, or is qml?
[19:03] <josharenson> mterry: no. If I prevent the prompt button from automatically gaining focus, it doesn't happen either
[19:03] <josharenson> mterry: I think its qml
[19:05] <josharenson> mterry: I can probably solve this by adding a variable, but seems hacky
[19:05] <mterry> yeah...
[19:05] <josharenson> mterry: LoginList and SessionsList are siblings, so accepting the event only prevents the parent from getting it...
[19:06]  * josharenson thinking out loud
[19:06] <mterry> josharenson: a not unreasonable thing to do is to make LoginList enabled=false when handling onSessionChooserButtonClicked...  That might fix this as a side effect (and any other weird focus/quick-typing issues while we swap widgets)
[19:07] <mterry> I guess that could be a propertychange on the State
[19:08] <josharenson> mterry: no effect... I keep getting that feeling that I'm running the exe from the wrong branch directory or something (cause nothing is having an effect), but its not the case :-p
[19:11] <josharenson> mterry: going the hack route for now...
[19:11] <mterry> josharenson: yeah sorry I don't know what might be going on  :(
[19:11] <mterry> I have my own tab-focus mysteries going on right now that I don't understnad
[19:12] <josharenson> mterry: yeah, its weird... haha
[19:13] <mterry> josharenson: actually -- here's a tip I just now found out.  Items have a activeFocusOnTab property that if you set to true, it automatically puts it into the default tab focus chain.  So you don't need to manually hook things up with KeyNavigation.tab
[19:14] <josharenson> mterry: that could help clean up 1 line of code by adding 1 additional line :-p ... certainly cleaner tho
[19:14] <mterry> josharenson: heh.  Yeah, just not needing to know the id of the next one is a bit nicer
[19:15] <josharenson> mterry: and the logic is in the right place too, I'll update this branch
[19:58] <ltinkl-u8> ChrisTownsend, ping pls :)
[19:59] <ChrisTownsend> ltinkl-u8: Hey!
[19:59] <ltinkl-u8> ChrisTownsend, cool \o/