[12:04] <zsombi> ltinkl: mzanetti: regarding the https://code.launchpad.net/~lukas-kde/unity8/reparent-cursor/+merge/319135
[12:04] <zsombi> where do you see UITK is doing the weirdo reparenting?
[12:04] <mzanetti> zsombi, copy/paste popups mainly
[12:05] <ltinkl> zsombi, a sec
[12:05] <zsombi> mzanetti: you mean the popups in general?
[12:05] <mzanetti> yes
[12:05] <mzanetti> I think we already hacked our own dialogs to not do that
[12:05] <mzanetti> but yeah, the copy/paste ones are broken still (e.g. wrong orientation in the shell on a tablet)
[12:06] <mzanetti> and covering the mouse cursor
[12:06] <ltinkl> zsombi, QQuickItem *QuickUtils::rootItem(QObject *object)
[12:06] <zsombi> well, that is a f* up, indeed, and it is a result of one MWC quickie that never got the opportunity to be cleaned properly :/
[12:07] <ltinkl> zsombi, I added uitk to #1667928
[12:08] <zsombi> that was the way it has been specified, and without proper window mangement at that time there was no way to have an overlay which would have been residing on top of everything :(
[12:08] <zsombi> ltinkl: is that a bug related to this change?
[12:08] <ltinkl> zsombi, yup
[12:08] <ltinkl> zsombi, above everything == above cursor as well :)
[12:08] <ltinkl> for the case of shell
[12:09] <zsombi> ltinkl: I am sorry, that cannot be fixed without breaking the APIs
[12:09] <zsombi> that's why we had not been doing much about those
[12:09] <zsombi> and it si not worth teh effort as QQC2 would bring the proper popups and dialogs we'd need
[12:10] <ltinkl> zsombi, ye well... we also hope for a proper HW cursor on Mir side
[12:10] <zsombi> :)
[14:39] <mterry> Saviq, ltinkl: https://code.launchpad.net/~mterry/unity8/fix-two-qmluitests/+merge/319214  -- how do I turn the OSK off?
[14:39] <mterry> whoops!
[14:39] <mterry> wrong link
[14:40] <Saviq> mterry, `gsettings set com.canonical.Unity8 always-show-osk false`
[14:40] <Saviq> or use the keyboard indicator
[14:40] <mterry> Saviq: not in the greeter -- indicator doesn't show toggle there
[14:40] <Saviq> mterry, right, then gsettings
[14:41] <ltinkl> yup, that should do
[14:41] <mterry> Saviq: I was more curious from a user perspective?
[14:41] <mterry> If I'm a user, Imma click that keyboard button at least once to see what it does
[14:41] <Saviq> mterry, it would show the switch there
[14:41] <mterry> And then never get rid of osk
[14:41] <Saviq> that's part of the problem - the switch isn't there ;0
[14:41] <mterry> Saviq: design didn't want that since the user can disable pulling down indicators
[14:41] <Saviq> mterry, or, if indicators unavailable, the next time you go into greeter, the switch would get overriden again
[14:42] <mterry> mm
[14:42] <mterry> Well anyway: https://code.launchpad.net/~mterry/unity8/greeter-osk/+merge/319215
[14:42] <mterry> ltinkl: ^
[14:42] <Saviq> I voted for "pull down keyboard to disable it again"
[14:42] <Saviq> but design didnae like
[14:42] <mterry> That branch can easily be pulled into a silo if we're not off to QA yet -- just a simple shell script change
[14:43] <Saviq> mterry, nice :)
[14:43] <Saviq> yeah, let's do that
[14:44] <ltinkl> mterry, nice, will that also help the lockscreen?
[14:45] <mterry> ltinkl: OSK is also broken in lockscreen?  I didn't know that.  This will not help there
[14:45] <ltinkl> mterry, not broken but the switch isn't accessible either
[14:46] <ltinkl> mterry, nvm :)
[14:46] <mterry> ltinkl: oh sure -- this branch doesn't address the bad UI design, it just fixes the OSK not coming up at all  :)
[14:46] <ltinkl> mterry, for the greeter only, got it
[14:46] <mterry> yeah
[14:58] <ltinkl> mterry, Saviq: ah reminds me, we should somehow drag in the ubuntu-keyboard-english package as a minimal dep; ppl will complain about the broken OSK
[14:58] <ltinkl> to unity8-desktop-session?
[14:58] <Saviq> ltinkl, ubuntu-keyboard does pull that in
[14:59] <Saviq> so as long as we depend on that
[14:59] <ltinkl> Saviq, hmm... wonder how come mterry didn't have it yday when testing
[14:59] <mterry> I didn't have ubuntu-keyboard either I don't think
[14:59] <ltinkl> ye
[14:59] <mterry> I could have uninstalled it at some point?
[14:59] <Saviq> maybe we're pulling maliit-framework and that's wrong
[14:59] <mterry> I dunno, my machine is insane -- not likely to be what user has
[14:59] <Saviq> or rather
[14:59] <Saviq> nothing at all
[14:59] <Saviq> and you installed maliit-framework manually
[15:00] <Saviq> so yeah, unity8-desktop-session would have to pull in ubuntu-keyboard
[15:00] <Saviq> just one problem there... MIR
[15:00] <mterry> And FFe at this point
[15:00] <Saviq> or maybe not
[15:00] <Saviq> right, maliit's in universe
[15:00] <Saviq> u-k in main
[15:00] <Saviq> ¿?
[15:01] <mterry> Saviq: u-k in universe
[15:02] <Saviq> ah /me was looking at our silo
[15:02] <Saviq> yeah, so all of it in universe still
[15:02] <Saviq> which is, maybe, OK
[15:02] <Saviq> but we should then not show the keyboard icon unless maliit-server is there, and running
[15:02] <Saviq> that'd be the solution for 17.04 IMO
[15:03] <Saviq> and later we might decide if ubuntu-keyboard belongs in main
[15:05] <mterry> ltinkl: is the keyboard icon smart about that?
[15:11] <Saviq> mterry, it's not, yet
[15:11] <Saviq> neither is the switch
[15:11] <Saviq> but should be relatively easy to add a check for maliit in there
[15:12] <Saviq> like, we know when we have an Input Method surface - if we don't, don't show the switches?
[15:12] <Saviq> and ltinkl gone
[15:19] <mterry> Saviq, ltinkl: So I had the stay-hidden maliit gsettings key set to true from some past adventures I guess.  What percent of users are going to hit same problem and not be able to see OSK?  Is there a reason we toggle our own key instead of that one?
 mterry, it's not, yet
[15:19] <Saviq>  neither is the switch
[15:19] <Saviq>  but should be relatively easy to add a check for maliit in there
[15:19] <Saviq>  like, we know when we have an Input Method surface - if we don't, don't show the switches?
[15:19] <Saviq>  and ltinkl gone
[15:19] <mterry> (Can we toggle that key in addition to ours?)
[15:19] <ltinkl> Saviq, mterry: back
[15:20] <Saviq> mterry, I *think* we manage stay-hidden as well
[15:20] <ltinkl> Saviq, we don't afaik
[15:20] <Saviq> oh ok, wonder if maliit should reset that, then
[15:21] <Saviq> we've too many keys doing ~the same
[15:21] <ltinkl> yeah it's confusing what is what
[15:21] <mterry> Why did we add our own?
[15:21] <ltinkl> ask Elleo :)
[15:21] <mterry> ltinkl: it's in your branch  :)
[15:22] <ltinkl> mterry, ah you mean always-show-osk?
[15:22] <ltinkl> mterry, right, I could have used stay-hidden, but hadn't known about it (we never used it)
[15:22] <mterry> ltinkl: yeah
[15:23] <mterry> ltinkl: is it too late?  :)
[15:23] <ltinkl> mterry, yes! ;) but can be changed in a followup branch later?
[15:23] <mterry> :(
[15:23] <mterry> That means synchronizing state later
[15:23] <mterry> And in meantime plenty of people (like me) may not see OSK like they intended
[15:24] <ltinkl> hmm but also means now we'd have to change indicator-keyboard, unity8 and u-s-s
[15:24] <mterry> And whatever tools exist to toggle that state in maliit, won't work in unity8
[15:25] <mterry> Well I leave it to Saviq to decide how bad it is, but that would have been a NAK during review from me
[15:25] <Saviq> ltinkl, mterry, not really too late, is it, but is stay-hidden the right thing? mzanetti, why didn't we use stay-hidden to inhibit OSK?
[15:26]  * mterry doesn't know if the keys are perfect overlap, but seems like we use them similarly. Maybe they do have nuance that's different
[15:27] <mterry> mzanetti: (stay-hidden is a key in the com.canonical.keyboard.maliit schema to disable keyboard)
[15:28] <ltinkl> Elleo, we were discussing the usefulness of having "always-show-osk" in our u8 schema when com.canonical.keyboard.maliit already has "stay-hidden"
[15:28] <ltinkl> Elleo, are they the same?
[15:29] <Elleo> ltinkl: they're effectively the opposite of each other, I was actually just preparing a branch to remove stay-hidden from the keyboard
[15:29] <Elleo> ltinkl: stay-hidden is how unity8 used to tell the keyboard to stay hidden before it took over hiding the surface itself
[15:30] <ltinkl> ah ok that solves it I guess ;)
[15:30] <ltinkl> Saviq, mterry ^^
[15:30] <Elleo> ltinkl: so it's redundant now
[15:31] <mterry> nice
[15:31] <mterry> ltinkl: back to ACK then  :P
[15:31] <Saviq> WFM
[15:37] <mzanetti> Saviq, mterry, what's the question?
[15:38] <Saviq> mzanetti, keep calm, carry on
[15:38] <mzanetti> :)
[19:07] <mterry> tedg: so I'm looking at launching gnome-terminal on deb-based-unity8 on zesty.  It fails to start because its backend user daemon can't connect to Mir (says "not accepted by server") -- is there some UAL magic around configuring a process such that unity8 will deign to talk to it, that might not be happening here for a dbus-activated user daemon?
[19:10] <tedg> mterry: Uhm.... we don't really cater to that example...
[19:10] <tedg> mterry: If it could start the first one not dbus activated, we'd pick it up easily.
[19:10] <tedg> mterry: As it'd have an instance that first time.
[19:11] <tedg> mterry: Not sure if it has a command line for that.
[19:11] <mterry> tedg: that's a pretty common GtkApplication pattern though, to spin a single-instance user daemon right?
[19:11] <tedg> mterry: I thought that they did that for first run, and then talked to it over dbus for secondary runs.
[19:12] <tedg> Not to dbus-activate it first time.
[19:12] <mterry> tedg: oh maybe that's how it's normally done then.  But gnome-terminal seems special
[19:12] <mterry> No command line arg that I can see
[19:15] <mterry> tedg: what is technically happening behind the scenes here?  I'm not familiar with not being accepted by the server -- are processes denied access to Mir unless UAL blesses them?
[19:15] <mterry> And in this case, I'm assuming UAL isn't blessing it because it doesn't recognize it as connected to the launching process
[19:16] <tedg> mterry: Yes, basically we put them into a systemd service. If things aren't a PID of that service, we reject them.
[19:45] <mterry> tedg: hmm, how do I debug what UAL is actually doing/launching?  i.e. get a look at the temp service?
[19:46] <mterry> The org.gnome.Terminal systemd unit is being started by UAL instead of just launching the command gnome-terminal it looks like
[19:46] <tedg> mterry: Probably easiest is to use the command line tools: ubuntu-app-*
[19:46] <tedg> mterry: That has most of the API pulled out for debugging purposes
[19:46] <mterry> tedg: which don't have --help or man pages  :P
[19:47] <tedg> mterry: If not that, you can also query systemd directly with d-feet/gdbus
[19:47] <mterry> The temp units are ephemereal though right?
[19:47] <tedg> mterry: Haha, they do print if they need args
[19:47] <tedg> mterry: Correct, so they'll disappear after running.
[19:47] <tedg> But while running, you can use dbus to get information.