[12:06] <ulrichard> How difficult is it to bring a javafx app to ubuntu phone? I managed to get it running with docker, but I never created a snap. https://github.com/jpasqua/VisibleTesla/pull/125
[14:11] <mterry> tedg_: I'm seeing some potentially UAL-related oddities.  With u8 now, some apps open and some don't.  Like, calculator opens but clock does not (both with devmode).  No logs that I can see.  But then when I run clock confined with my in-progress unity8 interface (and no unity7 interface), it does run.  So the app itself isn't borked.  I'm guessing that UAL
[14:11] <mterry> is doing something there?  Deciding between u7 and u8 modes and getting something wrong?  (even though the app can do both...)
[14:22] <mterry> tedg_: although... I had to rebuild the apps to test with a smaller interface footprint.  maybe rebuilding them fixed them too.  Like the ubuntu-app-platform qt-mismatch issue...
[14:23] <mterry> So maybe it was simply a rebuild that did it
[14:28] <dobey> mterry: yeah i think it's the rebuild that did it
[14:30] <tedg_> mterry: Seems likely there is a fix for apps that crash in silo 2434 which might help a couple of those cases.
[14:37] <dobey> tedg_: for that fix though, the app at least will run once from a new boot though, right? just fails later after the app had crashed previously in the session?
[14:38] <tedg_> dobey: Correct, so not all of mterry's issue, but it might be part of what's confusing him.
[18:38] <andybleaden> Quit
[20:02] <mterry> ogra_: you were getting some high load on a Pi from unity8-session restarting services a bunch, right?  I've tighted up our respawn limits in the latest snap, let me know if that works better for ya
[20:44] <mterry> tedg_: how are apps finding the right mir socket today?  (It ends up in /run/user/xxx/snap.unity8-session/mir_socket)
[20:46] <tedg_> mterry: We're pushing it into their environment when running. But when they have interface hooks we shouldn't do that. They should get it when connected.
[20:47] <tedg_> mterry: But I have a feeling we're gonna end up pushing it into their environment forever :-/ One of those things that we won't be able to drop.
[20:47] <mterry> tedg_: they want us to use /run/user/xxx/mir_socket (a global location)
[20:47] <mterry> So I can change that easily on u8 side...
[20:47] <mterry> But was curious how the apps got it
[20:47] <tedg_> mterry: That would be fine, then desktop-launch could set it.
[20:48] <mterry> True...
[20:48] <tedg_> mterry: Curious if it should be set per compositor, because you could nest them.
[20:48] <mterry> tedg_: who does the pushing today? UAL?
[20:48] <tedg_> mterry: Yeah, UAL.
[20:48] <mterry> tedg_: well...  I asked about nesting, but haven't gotten an answer back yet -- I suspect they don't care
[20:50] <tedg_> mterry: So, in a nutshell, I'm not sure I care that much. But I'd really rather we didn't provide it as an environment var. I'm most +1 on that, everything else is details :-)
[20:51] <mterry> tedg_: yeah it's hard to get away from doing it forever.  I was just thinking about doing it in desktop-launch instead, then realized that old apps would suddenly break once UAL stopped doing it
[20:51] <tedg_> mterry: We don't have that many old apps, and we've broken them twice in the last two weeks already :-)
[20:52] <mterry> tedg_: yeah -- just I don't like how fragile snaps sometimes seem, when we don't have good boundaries
[20:52] <mterry> Just need to nail down those boundaries
[20:52] <tedg_> And that's where I want to get to. I want to provide nothing that isn't detailed in the snap.yaml.
[20:52] <mterry> tedg_: I'll propose some changes
[20:57] <brunch875> does the ubuntu phone vibrate at some rate?
[20:58] <brunch875> it would be fun to use a ringtone which syncs with it
[20:58] <brunch875> have the phone dance to it :-)
[20:59] <dobey> i'm not sure the speed of vibration is controllable via software
[21:17] <mterry> tedg_: so I'm looking at UAL now -- if we go with a hardcoded path, we don't need any of this socket demangler complexity?  That'd be nice
[21:19] <tedg_> mterry: That's actually for the trusted prompt sessions, and we'd need that. Because it's a custom file handle that's part of the trusted prompts stuff.
[21:19] <tedg_> mterry: But yes, it would solve some complexity problems for us.
[21:20] <mterry> ah k