| === marcusto_ is now known as marcustomlinson | ||
| === marcusto_ is now known as marcustomlinson | ||
| Saviq | dednick, can you please resubmit unity8 laggy backends on top of lp:~dandrader/unity8/mouseClickSwitchesSurfaceFocus, there's a conflict in the Utils plugin | 09:13 |
|---|---|---|
| dednick | Saviq: ok | 09:26 |
| === greyback__ is now known as greyback | ||
| dednick | Saviq: done | 10:33 |
| dednick | Cimi: resubmitted laggy backend branch. | 10:36 |
| Cimi | dednick, o | 10:44 |
| Cimi | k | 10:44 |
| Saviq | dednick, tx | 11:03 |
| pete-woods | Saviq: hi. do you know if the unity application stack will tell me if the dash app is foremost even when the screen is locked? | 11:55 |
| pete-woods | my problem is basically this | 11:55 |
| pete-woods | I want the scopes to be active when both the screen is on, and the dash is the foremost app | 11:56 |
| pete-woods | unfortunately Qt.application.active (correctly) only tells me when the app is actually visible | 11:56 |
| pete-woods | so this works for when the user is operating the phone | 11:56 |
| pete-woods | be we really want the scopes to start being active as soon as the screen comes on, and we know that the scopes will be visible as soon as they have finished swiping | 11:57 |
| pete-woods | *but | 11:57 |
| Saviq | pete-woods, so you'd want to be told you're active before the phone is unlocked? that feels weird, what if the user actually launches an app from the launcher... | 12:01 |
| pete-woods | Saviq: then as soon as they do that, the scopes become inactive, and GPS goes off | 12:01 |
| pete-woods | the current behaviour we have is that the scopes are always active when the screen is on | 12:02 |
| pete-woods | which works well for user experience | 12:02 |
| pete-woods | but it leaves the GPS running when you have another app in the foreground | 12:02 |
| pete-woods | (and the scope you have selected uses location) | 12:02 |
| pete-woods | it's important to get the scope queries running early for us | 12:03 |
| pete-woods | as it means the user doesn't have to see the scope results popping in | 12:03 |
| Saviq | I've a weird feeling about this, we should be treating all apps the same way in this case | 12:04 |
| Saviq | nothing special about the dash there | 12:04 |
| === alan_g is now known as alan_g|lunch | ||
| pete-woods | the dash is already sorta special in that it never gets suspended | 12:05 |
| pete-woods | as it has to do this sort of trickery to get good performance | 12:05 |
| pete-woods | given it basically hosts about 30 "apps" inside of itself | 12:05 |
| Saviq | not true, it's not getting suspended because the middleware couldn't handle it | 12:06 |
| pete-woods | that's a fair point. but it still feels like it's special because it basically hosts all these other apps | 12:07 |
| pete-woods | we can just use the qt.active property, but then the user will see results popup after they unlock | 12:07 |
| Saviq | if we think that we need to pre-wake apps that "might soon be" on screen, then we should apply that to all the apps, not make dash special | 12:07 |
| pete-woods | sure, but this is a specific battery-use bug we have right now | 12:08 |
| Saviq | yeah but what if they just wake the screen to see the clock, or interact with notifications | 12:08 |
| pete-woods | I'd be very happy to move to a proper system later | 12:08 |
| Saviq | you'll waste battery this way to fetch results that the user might never see | 12:08 |
| pete-woods | that's a very good point | 12:09 |
| dandrader | tsdgeos, are you looking for tasks? | 12:09 |
| pete-woods | hmm | 12:09 |
| pete-woods | maybe I should just do the simple solution, and see if anyone complains :p | 12:09 |
| Saviq | pete-woods, we need to improve the refresh UX, that would help with "results popping up" | 12:09 |
| pete-woods | very true | 12:10 |
| Saviq | but for now I believe we just need to do with what we have | 12:10 |
| Saviq | and scopes should only wake up when the dash is focused | 12:11 |
| Saviq | pete-woods, screen gets on on incoming text, too, even worse to wake scopes up then | 12:12 |
| pete-woods | Saviq: thinking about it more, the scopes only actually *do* something if they have "dirty" results | 12:13 |
| pete-woods | but the GPS would come on for 20 seconds or so | 12:13 |
| pete-woods | I think you've convinced me to do the "wait til after unlock" solution | 12:13 |
| Saviq | sure, but they might get dirty every hour or whatnot | 12:13 |
| Saviq | all other apps have to deal with only getting woken up when the user focused it, I'm sure we can deal with that ourselves :) | 12:13 |
| Saviq | s/it/them/ | 12:14 |
| Saviq | dednick, should there not be a bumped dependency between unity8 and system components for laggy backends? | 12:17 |
| Saviq | s/system/settings/ | 12:17 |
| Saviq | looks like it | 12:19 |
| === MacSlow is now known as MacSlow|lunch | ||
| tsdgeos | dandrader: i am reviewing one branch from mterry but after that i'm quite idle yeah | 12:30 |
| dandrader | tsdgeos, this one next, please! -> https://code.launchpad.net/~dandrader/unity8/ddaImprovements/+merge/254964 | 12:31 |
| tsdgeos | dandrader: sure | 12:32 |
| dandrader | tsdgeos, great, thanks!! | 12:32 |
| === dandrader is now known as dandrader|afk | ||
| === alan_g|lunch is now known as alan_g | ||
| Saviq | tsdgeos, to clarify: it will only trigger the refresh on focus if the scope is dirty | 12:44 |
| tsdgeos | Saviq: and previously didn't | 12:44 |
| tsdgeos | i'm asking if we're fine with that | 12:44 |
| Saviq | tsdgeos, previously it did on screen wake up | 12:44 |
| tsdgeos | because scope rebuilding is a bit unsettling tbh | 12:44 |
| Saviq | or on you switching to the dirty scope, for that matter | 12:45 |
| tsdgeos | Saviq: yeah but you have the greeter and maybe the locker | 12:45 |
| Saviq | tsdgeos, yeah, and that wasted power | 12:45 |
| Saviq | tsdgeos, sure, we need to fix the UX of scope refresh | 12:45 |
| tsdgeos | Saviq: i'm not against it, i'm just saying we need to take into account that it's not only fixing a bug | 12:45 |
| tsdgeos | but changing the behaviour | 12:45 |
| tsdgeos | too | 12:45 |
| tsdgeos | sightly sure | 12:45 |
| Saviq | depends on the definition of fixing a bug, when the behaviour was wrong before ;) | 12:46 |
| tsdgeos | i will take that as a "yes we're aware it's changing behaviour and we're fine with it" | 12:47 |
| Saviq | yes :) | 12:48 |
| dednick | Saviq: ya, i've just left it so we get the debs for testing. will update. | 12:48 |
| Saviq | dandrader|afk, people have confirmed the tap-indicator issue on RTM where we don't have the MouseArea, so unlikely that's the cause | 12:52 |
| Mirv | tsdgeos: I marked 018 finally as tested... phew. | 13:03 |
| tsdgeos | Mirv: :) | 13:03 |
| === dandrader|afk is now known as dandrader | ||
| josharenson | tedg: do you know where dbus-display-manager.h is located (regarding indicator-session). It seems that it is included and called, but I cannot find it. | 13:07 |
| tsdgeos | josharenson: is it autogenerated? | 13:09 |
| * josharenson does a build | 13:10 | |
| josharenson | tsdgeos: yup, thanks... | 13:10 |
| tsdgeos | josharenson: no worries | 13:10 |
| === MacSlow|lunch is now known as MacSlow | ||
| tedg | josharenson, It is generated, but in the src/backend-dbus/ directory | 13:26 |
| josharenson | tedg: got it, thanks | 13:27 |
| tedg | np | 13:29 |
| Mirv | tsdgeos: thought: can you check plasma5 with silo 018? | 13:35 |
| tsdgeos | Mirv: i guess i can yes, the only thing in there is qtbus right? | 13:36 |
| Mirv | tsdgeos: yes | 13:36 |
| tsdgeos | i mean not sure what to test | 13:36 |
| tsdgeos | but i guess i can install it and see if something immediately blows up or not | 13:36 |
| Mirv | well basic operation, I'd guess you're using KDE more than me | 13:36 |
| tsdgeos | and use it a bit | 13:36 |
| Mirv | thanks | 13:37 |
| tsdgeos | Mirv: wops, good call | 13:52 |
| tsdgeos | everything exploded | 13:52 |
| tsdgeos | i'll comment on both our and upstream | 13:54 |
| Mirv | tsdgeos: aargh.. even though good call. I should probably cancel the QA signoff process? | 13:55 |
| tsdgeos | Mirv: guess so, trace looks genuine bug in Qt and not a misused API on the kde side | 13:56 |
| dandrader | Saviq, should be something else there then. because I just verified that the bug is indeed caused by that MouseArea for desktop interaction | 14:00 |
| Saviq | dandrader, could be, or popey used a different steps to repro | 14:01 |
| popey | hmm? | 14:01 |
| Saviq | popey, bug #1439318 | 14:02 |
| ubot5 | bug 1439318 in unity8 (Ubuntu) "Tapping the top edge shows the indicators panel when in fullscreen mode" [High,In progress] https://launchpad.net/bugs/1439318 | 14:02 |
| Saviq | popey, we've got an obvious explanation for vivid, but you confirmed for rtm too | 14:02 |
| popey | ah okay. | 14:03 |
| popey | i just opened the game and stabbed near the bottom left (which is top left of the phone) and the indicator messages flew down to the top | 14:03 |
| Saviq | yeah it could actually be we have two bugs there | 14:04 |
| popey | want a video of it? | 14:07 |
| Saviq | popey, no need, if the steps to repro are the same | 14:15 |
| MacSlow | Saviq, ever seen this when trying to compile unity8 -> http://pastebin.ubuntu.com/10724501 ? | 14:59 |
| MacSlow | Saviq, never mind... solved | 15:12 |
| === dandrader is now known as dandrader|afk | ||
| josharenson | I have some debug code in lightdm.c inside handle_seat_call that prints the GDbusMethodInvocation method name... when I run dm-tool, I get expected results. However, when locking or logging out, etc from indicator session, I don't see any calls made (obviously the device still locks). Anyone know whats going on here? | 16:42 |
| josharenson | mterry: so I still can't see any dbus calls from indicator-session to lightdm. I have debug code in lightdm that gets hit when I run things manually, but never gets hit when I do the same things via indicator-session... Is it possible that something other than lightdm is being used? (I don't have gdm installed, and lightdm is running, I just can't figure out whats happening) | 17:18 |
| mterry | josharenson, this is unity7 or unity8? | 17:19 |
| josharenson | unity7 | 17:19 |
| josharenson | mterry: should have clarified that | 17:19 |
| mterry | josharenson, so I think with the first time you use that indicator-session button "lock screen" it uses an internal lockscreen just inside unity7 | 17:20 |
| mterry | josharenson, from that lockscreen, if you press that button again, you go down the lightdm route | 17:20 |
| === alan_g is now known as alan_g|EOW | ||
| josharenson | mterry: I'll just assume there is a good reason for that and take a look at unity7 code. thanks | 17:21 |
| mterry | josharenson, there were technical reasons why it was hard to use the greeter as a simple session lockscreen at the time | 17:22 |
| mterry | josharenson, I think robert ancell solved most of them? But not sure the state of play there | 17:22 |
| mterry | josharenson, but anyway, that's why there's a separate session lockscreen inside unity7 | 17:22 |
| === dandrader|afk is now known as dandrader | ||
| seb128 | hum | 18:06 |
| seb128 | my bq rtm stops asking for the pincode to unlock | 18:06 |
| seb128 | but I had it configured on pin (I think) and that's what settings is listing as current config | 18:07 |
| mterry | I flashed my krillin and didn't see the location screen in the wizard... Do I have to do something special to get the HERE stuff? | 18:31 |
| mterry | seb128, knock it off :( | 18:31 |
| mterry | seb128, it's just slide to unlock for you now? | 18:31 |
| mterry | seb128, is your user somehow in the nopasswdlogin group? | 18:32 |
| === om26er_ is now known as om26er | ||
| seb128 | mterry, yeah, slide to unlock, and yes it's in nopasswdlogin (not sure why/how) | 19:20 |
| mterry | seb128, that's crazy town | 19:20 |
| mterry | seb128, did you mount stuff as rw like /etc/group? | 19:21 |
| mterry | seb128, accountsservice does normally try to add the user to the group but normally fails | 19:21 |
| seb128 | I've the image as r/w yes | 19:21 |
| mterry | seb128, because that isn't writable | 19:21 |
| seb128 | like the usual /userdata/.writable_image | 19:21 |
| mterry | seb128, but if it's writable, I'd expect it to also be able to remove you from that group | 19:22 |
| mterry | seb128, well I think that situation isn't normal for a customer at least... But still not great that we got out of sync | 19:22 |
| seb128 | yeah, unsure how I changed it/added it to the group | 19:22 |
| === ssweeny` is now known as ssweeny | ||
| === alexabreu is now known as alex-abreu|off | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!