| === jzheng is now known as jzheng_afk | ||
| === Malsasa_ is now known as Malsasa | ||
| tsdgeos | dandrader: there? | 10:12 |
|---|---|---|
| tsdgeos | greyback: you there? | 10:15 |
| dandrader | tsdgeos, yes | 10:15 |
| greyback | tsdgeos: yep | 10:15 |
| tsdgeos | greyback: dandrader: do you know what is creating the QTouchEvents? is it the qtmir qpa? | 10:16 |
| tsdgeos | in the phone | 10:16 |
| dandrader | tsdgeos, QtEventFeeder | 10:16 |
| tsdgeos | dandrader: where's the code of that? | 10:16 |
| dandrader | tsdgeos, src/platforms/mirserver/qteventfeeder.h | 10:17 |
| dandrader | tsdgeos, src/platforms/mirserver/qteventfeeder.cpp | 10:17 |
| tsdgeos | in qtmir? | 10:17 |
| dandrader | tsdgeos, yes | 10:17 |
| tsdgeos | oki tx | 10:17 |
| tsdgeos | dandrader: greyback: can i compile qtmir on the phone with this qmake or do i need some special flags? | 10:21 |
| dandrader | tsdgeos, I always build it on the phone | 10:22 |
| dandrader | tsdgeos, with qmake. nothing special | 10:22 |
| tsdgeos | ok, no special flag, just run qmake, good | 10:22 |
| dandrader | tsdgeos, but I pass it CONFIG+=no_tests to speed up the build | 10:22 |
| tsdgeos | oki | 10:22 |
| dandrader | tsdgeos, check the readme | 10:22 |
| tsdgeos | sorry ^_^ | 10:23 |
| dandrader | tsdgeos, I also pass it PREFIX=/usr, although I'm not sure it it's really needed | 10:24 |
| greyback | dandrader: for qmake, that's not needed | 10:26 |
| Saviq | or! | 10:29 |
| Saviq | x-build! | 10:29 |
| Saviq | the cmake-based qtmir is migrating now ;) | 10:30 |
| pstolowski | tsdgeos, hey, there is conflict in https://code.launchpad.net/~aacid/unity8/list_on_bottom_swipe, can you update? | 10:40 |
| tsdgeos | dandrader: if i put a qDebug in QtEventFeeder::dispatchMotion should i see it in the unity-dash.log if it's the dash i'm pressing over? | 10:40 |
| tsdgeos | pstolowski: hmmm | 10:41 |
| tsdgeos | $ bzr merge ../unity8/ | 10:41 |
| tsdgeos | Nothing to do. | 10:41 |
| tsdgeos | maybe i have not pushed? | 10:41 |
| dandrader | tsdgeos, no | 10:41 |
| dandrader | tsdgeos, it will be in unity8.log | 10:41 |
| tsdgeos | ok | 10:41 |
| tsdgeos | pstolowski: it's pushed | 10:41 |
| tsdgeos | pstolowski: conflict with what? | 10:41 |
| dandrader | tsdgeos, QtEventFeeder lives in the unity8 process. it takes an event out of mir and puts it into unity8's QQuickWindow | 10:41 |
| tsdgeos | dandrader: but unity8-dash has a different window, how events get there? | 10:42 |
| dandrader | tsdgeos, if you wanna track the input events that unity8 sends to client apps check MirSurfaceItem in qtmir | 10:42 |
| tsdgeos | dandrader: well i have an input event that "seems" wrong | 10:42 |
| tsdgeos | i'm trying to track where goes wrong | 10:42 |
| tsdgeos | or if it's just sent wrong by autopilot | 10:42 |
| tsdgeos | ok, tx for the pointers | 10:43 |
| pstolowski | tsdgeos, debian/control | 10:44 |
| tsdgeos | pstolowski: merging which branches? | 10:44 |
| dandrader | tsdgeos, src/modules/Unity/Application/mirsurfaceitem.cpp:615 | 10:45 |
| pstolowski | tsdgeos, trunk. unity8 just landed | 10:45 |
| dandrader | tsdgeos, that's where unity8 sends a mir input event down to the client app | 10:45 |
| pstolowski | tsdgeos, i mean, another chanes in unity8 landed | 10:45 |
| tsdgeos | pstolowski: ah unity8 just landed | 10:46 |
| tsdgeos | k | 10:46 |
| dandrader | oh... qtmir trunk now uses CMake | 10:46 |
| greyback | yep, proper cros building now possible | 10:47 |
| tsdgeos | noooooooooooooo | 10:47 |
| dandrader | greyback, Saviq, qtmir README still talks about qmake :) | 10:47 |
| tsdgeos | nooooooooooooooooo | 10:47 |
| * tsdgeos shakes fist | 10:48 | |
| greyback | d'oh | 10:48 |
| tsdgeos | 107 tags updated. | 10:48 |
| tsdgeos | Saviq: ↑ | 10:48 |
| Saviq | mterry!!!! | 10:48 |
| dandrader | greyback, do we have a CONFIG+=no_tests equivalent? | 10:48 |
| greyback | dandrader: probably not | 10:48 |
| dandrader | grrrrr | 10:48 |
| greyback | sorry | 10:49 |
| Saviq | easy to add | 10:49 |
| Saviq | copy/paste from usc | 10:49 |
| tsdgeos | pstolowski: ok, merged | 10:49 |
| pstolowski | tsdgeos, thanks | 10:51 |
| tsdgeos | mzanetti: merge your branches plz | 10:53 |
| tsdgeos | Text conflict in debian/unity8-common.install | 10:53 |
| tsdgeos | 1 conflicts encountered. | 10:53 |
| mzanetti | again :D | 10:53 |
| mzanetti | tsdgeos: ack, will do. thanks | 10:53 |
| * tsdgeos keeps digging up | 11:08 | |
| tsdgeos | dandrader: who calls QtEventFeeder::dispatch ? | 11:08 |
| tsdgeos | i guess mir | 11:11 |
| dandrader | tsdgeos, yes | 11:11 |
| * tsdgeos ends where he didn't want to end | 11:11 | |
| Saviq | greyback_, dandrader, I had to overwrite lp:qtmir and lp:qtmir/gles | 11:15 |
| Saviq | it has dome dumb empty commits from the train on top | 11:15 |
| Saviq | s/has/had/ | 11:16 |
| Saviq | s/dome/some/ | 11:16 |
| greyback_ | ok | 11:16 |
| mzanetti | greyback_: hey, I had to push some change to the uninvert-launcher branch | 11:30 |
| mzanetti | greyback_: mind reapproving? | 11:30 |
| tsdgeos | meh i want to build mir but don't have enough space in the phone :/ | 11:30 |
| greyback_ | mzanetti: ok looking | 11:30 |
| mzanetti | greyback_: so the issue is that the launcher changed in trunk, which I merged | 11:30 |
| mzanetti | greyback_: unfortunately had to clip | 11:30 |
| greyback_ | naughty | 11:31 |
| dandrader | tsdgeos, to the ubuntun image resize trick! | 11:35 |
| dandrader | tsdgeos, and use mako, not krillin | 11:35 |
| tsdgeos | dandrader: i'm on mako, my krillin has enough space :D | 11:35 |
| dandrader | if you say so | 11:36 |
| greyback_ | tsdgeos: I've not rebuilt mir for phone in a while, but I know the team use their own chroot-based Xcompile scripts | 11:36 |
| Saviq | tsdgeos, for when x-building doesn't work, I started using a chroot in $HOME on the device | 11:36 |
| tsdgeos | right | 11:36 |
| tsdgeos | that makes sense-ish | 11:36 |
| Saviq | can get you a rootfs | 11:36 |
| dandrader | tsdgeos, just in case http://paste.ubuntu.com/9381191/ | 11:36 |
| === dandrader is now known as dandrader|afk | ||
| Saviq | yeah that's not gonna work on krillin | 11:37 |
| Saviq | we have real partitions there | 11:37 |
| * Saviq recommends chroots | 11:37 | |
| Saviq | they survive flashing etc. | 11:37 |
| Saviq | and it's real easy to debootstrap into a folder | 11:37 |
| mzanetti | tsdgeos: merged 'em all | 11:38 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === dandrader|afk is now known as dandrader | ||
| === alan_g is now known as alan_g|lunch | ||
| dandrader | Saviq, so have 107 stale tags leaked into unity8? | 13:47 |
| Saviq | dandrader, yes, mterry managed to land them yesterday | 13:47 |
| dandrader | Saviq, your script doesn't seem to detect them | 13:47 |
| Saviq | dandrader, you might not have the latest instalment http://people.canonical.com/~msawicz/unity8/strip-tags.py | 13:48 |
| Saviq | this should remove all the invalid tags | 13:48 |
| dandrader | Saviq, yeah, now it works | 13:48 |
| === alan_g|lunch is now known as alan_g | ||
| seb128 | where is the app details page come from in unity8/touch (the one you get when you long press on an app icon) | 14:36 |
| Saviq | seb128, the click store in general | 14:41 |
| Saviq | seb128, falling back to the .desktop file | 14:41 |
| seb128 | thanks | 14:41 |
| Saviq | mzanetti, think you could prep a vivid silo? I'd want to focus on the first ota landing | 14:48 |
| Saviq | mzanetti, don't build yet, list_on_bottom_swipe is migrating already, but it's blocked in proposed for a while still | 14:49 |
| mzanetti | Saviq: sure. is there a spreadsheet entry already? | 14:50 |
| Saviq | mzanetti, no | 14:50 |
| === dandrader is now known as dandrader|lunch | ||
| mzanetti | ack | 14:52 |
| tsdgeos | mzanetti: what do you mean in https://code.launchpad.net/~aacid/unity8/deparment_jumping/+merge/243639 ? | 14:55 |
| mzanetti | tsdgeos: I open the store and even though the department selection says "all" I only see the music section | 14:56 |
| tsdgeos | mzanetti: in the navigation list? or as part of the results? | 14:56 |
| mzanetti | tsdgeos: results | 14:56 |
| tsdgeos | mzanetti: the list is still full of stuff? | 14:56 |
| mzanetti | no, only has the media section too, and "all" | 14:56 |
| tsdgeos | weird | 14:58 |
| tsdgeos | i'll check | 14:58 |
| tsdgeos | maybe it really needs the scopes shell part | 14:58 |
| Saviq | greyback_, can you have a look at bug #1394645 please | 15:00 |
| ubot5` | bug 1394645 in The Webapps-core project "OSK doesn't appear after OA login" [Critical,Confirmed] https://launchpad.net/bugs/1394645 | 15:01 |
| greyback_ | Saviq: sure | 15:04 |
| Saviq | greyback_, it seems from the last comments like we might be on the hook there | 15:13 |
| greyback_ | Saviq: yeah I think you're right | 15:18 |
| tsdgeos | Cimi: you're reviewing my debug output to try to find what's wrong :D | 15:27 |
| tsdgeos | sorry should have marked as DO NOT REVIEW YET | 15:27 |
| Cimi | tsdgeos, I saw you filled the description so I thought it was good to go :) | 15:28 |
| === dandrader|lunch is now known as dandrader | ||
| kgunn | Saviq: i don't think these are unity8....do you agree ? | 15:43 |
| kgunn | bug 1398427 | 15:43 |
| ubot5` | bug 1398427 in qtmir (Ubuntu RTM) "Can't use earphone to answer or disconnect a call" [Critical,In progress] https://launchpad.net/bugs/1398427 | 15:43 |
| kgunn | bug 1394645 | 15:43 |
| ubot5` | bug 1394645 in The Webapps-core project "OSK doesn't appear after OA login" [Critical,Confirmed] https://launchpad.net/bugs/1394645 | 15:43 |
| Saviq | kgunn, the latter one is between u8 and qtmir it seems | 15:43 |
| Saviq | kgunn, the former we're debating, have asked for design feedback to start with | 15:43 |
| Saviq | kgunn, they're "ours" in the sense there might be little or more work in it | 15:44 |
| Saviq | for us | 15:44 |
| tsdgeos | Cimi: ok, you can review https://code.launchpad.net/~aacid/unity8/autopilot_drag_more/+merge/243367 now, but better let it run in CI and see if it passes | 15:46 |
| tsdgeos | i had it running on the phone for 45 minutes and succeded all the time so is looking good | 15:46 |
| tsdgeos | but you never know | 15:46 |
| Cimi | tsdgeos, if it is a workaround, add a comment linking the bug | 15:48 |
| tsdgeos | i can't | 15:48 |
| tsdgeos | i have not filed the bug yet | 15:48 |
| Cimi | ok so file it :P | 15:48 |
| Cimi | you said filed in the commit :P | 15:48 |
| tsdgeos | i am a lier | 15:49 |
| tsdgeos | you got me | 15:49 |
| Cimi | :D | 15:49 |
| Cimi | * Did you make sure that your branch does not contain spurious tags? | 15:50 |
| Cimi | hah | 15:50 |
| Cimi | I think I lied sometimes on that | 15:50 |
| * Cimi slaps himself | 15:50 | |
| === Malsasa_ is now known as Malsasa | ||
| tsdgeos | Cimi: happier now? https://code.launchpad.net/~aacid/unity8/autopilot_drag_more/+merge/243367 | 15:55 |
| Cimi | tsdgeos, the comment was to be added in the code :P | 15:55 |
| tsdgeos | that's nonsense | 15:56 |
| tsdgeos | what do we have commit logs for then? | 15:56 |
| Saviq | mterry, looks like bug #1363400 is coming your way | 15:56 |
| ubot5` | bug 1363400 in unity8 (Ubuntu) "[wizard] allows to "Continue" without connecting to network" [High,Triaged] https://launchpad.net/bugs/1363400 | 15:56 |
| Cimi | tsdgeos, why? we usually add FIXME in code for this reason | 15:56 |
| Cimi | when we workaround things | 15:56 |
| tsdgeos | which i complain every single time we do that | 15:56 |
| tsdgeos | if we're going to make our commit logs useless we may as well keep them empty | 15:56 |
| mterry | hmm, Cimi knows that code better than me -- do you know what's going on with the above bug? ^ | 15:57 |
| tsdgeos | Cimi: but sure, i'll add it there | 15:57 |
| tsdgeos | not that i care :D | 15:57 |
| Cimi | tsdgeos, I am happy both ways, just we need to keep going with the same rule | 15:57 |
| Cimi | let's discuss with saviq and others | 15:58 |
| Cimi | mterry, there is a stupid counter for wifi | 15:58 |
| Cimi | mterry, we need more capability from network indicator, like a value saying "wifi is connected" | 15:58 |
| mterry | Cimi, it doesn't tell us that? | 15:58 |
| Cimi | mterry, it didn't when I wrote that code iirc | 15:59 |
| tsdgeos | Cimi: added | 15:59 |
| mterry | Cimi, can I assign the bug to you? | 15:59 |
| Cimi | mterry, is not on me... | 16:00 |
| mterry | Cimi, right, but someone needs to do the u8 side and make sure the network side gets done | 16:00 |
| Cimi | mterry, ok then | 16:00 |
| Cimi | mterry, just looked at the code | 16:01 |
| Saviq | Cimi, if we need more from some backends, add a task for it | 16:01 |
| Cimi | Saviq, yeah, months ago answer was "not a priority" | 16:01 |
| Cimi | Saviq, will chase again | 16:02 |
| mterry | Cimi, thanks! | 16:02 |
| Saviq | Cimi, it just became a priority as the bug is targeted for the milestone in 2 weeks | 16:03 |
| Saviq | Cimi, so you got some push behind you this time | 16:03 |
| mterry | Saviq, if it's targetting rtm, the code change will be in u-s-s | 16:05 |
| Saviq | mterry, ah right | 16:05 |
| Saviq | mterry, this is going to be a tricky one | 16:05 |
| Saviq | mterry, so it affects unity8 (Ubuntu) but u-s-s (RTM | 16:05 |
| mterry | Saviq, heh, right | 16:05 |
| Saviq | greyback_, fix for bug #1365673 still on hold? | 16:07 |
| ubot5` | bug 1365673 in unity8 (Ubuntu) "/usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene:6:qt_message_fatal:QMessageLogger::fatal:UbuntuClientIntegration::UbuntuClientIntegration:UbuntuMirClientIntegrationPlugin::create:loadIntegration" [High,Confirmed] https://launchpad.net/bugs/1365673 | 16:07 |
| greyback_ | Saviq: yeah, I suspect it breaks something else | 16:07 |
| Saviq | greyback_, any chance for a fix for 18.12? | 16:08 |
| greyback_ | Saviq: well if it's some other issue (which this far I've been unable to determine/reproduce) then unlikely. If it's just that, then looks good | 16:09 |
| Saviq | greyback_, ok, I'll leave it in for that milestone for now then | 16:09 |
| tsdgeos | mzanetti: you tried lp:~aacid/unity8/deparment_jumping on rtm or vivid? | 16:11 |
| mzanetti | tsdgeos: vivid | 16:13 |
| tsdgeos | ok | 16:15 |
| dandrader | mterry, got an MP for you to review https://code.launchpad.net/~dandrader/unity8/greeterRefactoring/+merge/243823 | 16:20 |
| dandrader | mterry, I cherry picked it out of the shellRotation work | 16:21 |
| mterry | dandrader, oof ok | 16:21 |
| dandrader | mterry, so it can be reviewed separately. | 16:21 |
| mterry | nice, thanks | 16:21 |
| Saviq | tsdgeos, I'll wait for moreAsyncDash before landing the other bits in rtm, ok? | 16:25 |
| tsdgeos | Saviq: sure | 16:25 |
| tsdgeos | Cimi: actually you want to give it more time on https://code.launchpad.net/~aacid/unity8/moreAsyncDash/+merge/241524 or ? | 16:26 |
| Cimi | tsdgeos, ccan we retrigger ci? | 16:26 |
| tsdgeos | sure | 16:26 |
| Cimi | so for monday we are ok to go? | 16:27 |
| tsdgeos | hmmm | 16:27 |
| tsdgeos | actually did i lose the hability to retrigger builds? | 16:28 |
| tsdgeos | Saviq: any idea? ↑ | 16:28 |
| Saviq | tsdgeos, seems I have, too | 16:29 |
| tsdgeos | Cimi: so no, can't retrigger a build :D | 16:29 |
| tsdgeos | i'll merge | 16:29 |
| Saviq | tsdgeos, ah, it's all the network etc. issues in CI | 16:29 |
| tsdgeos | that should trigger one | 16:29 |
| Saviq | tsdgeos, it won't | 16:29 |
| Cimi | tsdgeos, great | 16:29 |
| tsdgeos | oh :/ | 16:29 |
| Cimi | ah | 16:29 |
| Saviq | tsdgeos, there's still issues in the lab they're working on | 16:29 |
| * greyback_ hates that QtCreator just fails to open cmake project if a dependency is missing | 16:33 | |
| Saviq | greyback_, +1, but I'm not sure it's QtC's fault.., cmake just doesn't generate the list of files that QtC uses then | 16:49 |
| Saviq | (I think) | 16:49 |
| greyback_ | Saviq: sure I get that, but that's a technical reason which I don't hugely care about. Prompt me, force cmake to generate as much as it can, and disable building | 16:50 |
| greyback_ | then I can still read & edit code | 16:50 |
| Saviq | maybies | 16:50 |
| Saviq | greyback_, btw, seems kgunn threw bug #1394645 josharenson's way | 16:59 |
| ubot5` | bug 1394645 in The Webapps-core project "OSK doesn't appear after OA login" [Critical,Confirmed] https://launchpad.net/bugs/1394645 | 16:59 |
| greyback_ | Saviq: ok | 16:59 |
| kgunn | unless greyback_ you wanna give josharenson an early christmas present :) | 16:59 |
| kgunn | and just fix it | 16:59 |
| josharenson | :-D | 16:59 |
| greyback_ | will see | 17:00 |
| josharenson | I have another question for you greyback_ before you go eow, gimmie a min | 17:00 |
| greyback_ | not sure where focus has gone to | 17:00 |
| greyback_ | ok | 17:00 |
| josharenson | greyback_ so current screenshot logic (the actual screengrab) is handled in qml now... | 17:07 |
| josharenson | so does USC/mir have the ability to take screenshots already? | 17:07 |
| greyback_ | josharenson: it does, just via a different mechanism. | 17:08 |
| josharenson | greyback_ I figured.. ok ill go look for it | 17:08 |
| greyback_ | josharenson: have a look at mir::scene::Session::take_snapshot | 17:09 |
| josharenson | cool | 17:09 |
| greyback_ | an example of it being used is in qtmir: src/modules/Unity/Application/applicationscreenshotprovider.cpp | 17:10 |
| josharenson | ack, thanks | 17:13 |
| josharenson | hummm so if screenshots are handled in USC, how will the user receive feedback | 17:18 |
| greyback_ | josharenson: what feedback should the user get? Noise being played? Screen flash? | 17:20 |
| josharenson | greyback_ yes | 17:20 |
| josharenson | :-p | 17:20 |
| josharenson | greyback_ also, I assume it should be encoded via something like libping rather than being converted to a QImage | 17:20 |
| josharenson | libpng | 17:21 |
| mzanetti | josharenson: QImage::saveToFile() | 17:21 |
| josharenson | mzanetti, trying to avoid the use of qml in usc, unless that isn't an issue | 17:22 |
| josharenson | well qy | 17:22 |
| josharenson | qt* | 17:22 |
| * josharenson can't type today | 17:22 | |
| greyback_ | josharenson: I didn't know you could use Qt. You can use the qmultimedia stuff to play back sound - not sure if it'll work as root user, but one way to find out | 17:23 |
| greyback_ | the white flash, well, 1 form of feedback is probably enough? Sound should do it, no (sorry hearing-impaired people)? | 17:23 |
| josharenson | greyback_ trying not to use Qt.... | 17:23 |
| greyback_ | josharenson: then you've hard work ahead of you :( | 17:24 |
| greyback_ | can probably use pulseaudio C library to play sound | 17:24 |
| josharenson | greyback_ is there any reason not to use qt? kgunn had asked me about it and I told him I would avoid it | 17:24 |
| mzanetti | josharenson: there's already Qt in there | 17:24 |
| mzanetti | at least it links qtcore and qtdbus | 17:24 |
| josharenson | mzanetti, so... any disadvantage to adding more? Just trying to keep screenshots shell agnostic | 17:25 |
| * greyback_ might've heard that people wanted to remove Qt dependency from USC | 17:26 | |
| greyback_ | kgunn: ^^ any truth to that? | 17:26 |
| josharenson | greyback_ is there any way shell can listen to USC for events? | 17:26 |
| greyback_ | josharenson: via dbus would be only way | 17:27 |
| josharenson | greyback_ thats not bad... then any shell could listen for the screenshot dbus signal and notify the user however it wants | 17:27 |
| greyback_ | true | 17:28 |
| josharenson | and libpng could, I assume, save the raw pixel data to $USER | 17:28 |
| josharenson | well after encoding | 17:28 |
| greyback_ | well if you have qt, I don't see why you shouldn't just use it | 17:29 |
| * mzanetti is a bit lost here | 17:29 | |
| josharenson | mzanetti, I guess the tl;dr is I want to move screenshot logic entirely to USC and minimize (or not at all) use of Qt | 17:30 |
| mzanetti | yeah... I understand that... did anyone tell you to avoid Qt? | 17:31 |
| josharenson | mzanetti, kgunn had asked me something like "will moving screenshots to usc mean there will be more qt in usc?" | 17:32 |
| josharenson | so I assumed it was discouraged | 17:32 |
| mzanetti | ah... you I guess you'll have to clarify if that's true. would be news to me. | 17:34 |
| kgunn | mzanetti: i don't know if it's a completely bad thing...but there was some reason we were thinking we wanted to pull qml out of u-s-c | 17:36 |
| kgunn | i guess more of a "is this really a necessary dependancy?" kind of thot | 17:36 |
| kgunn | alan_g: AlbertA ^ | 17:36 |
| alan_g | AIUI there were security concerns about Qt in a privileged task. (But I wasn't directly involved in those discussions) | 17:38 |
| AlbertA | kgunn: josharenson: why move screenshots to USC? | 17:41 |
| greyback_ | kgunn: alan_g: whatever these "security concerns" are, the other side of the argument should be development time and convenience. the phrase "security concerns" always sounds like FUD to me | 17:41 |
| AlbertA | I thought we convinced ourselves it was not a good idea for it to be in USC | 17:41 |
| kgunn | AlbertA: but why ? | 17:42 |
| AlbertA | kgunn: well one reason was encrypted user folders | 17:42 |
| kgunn | i recall the conclusion, but not the reason | 17:42 |
| mzanetti | hmm... I guess that's a good point | 17:43 |
| AlbertA | kgunn: and you would be screenshotting the root server | 17:43 |
| josharenson | AlbertA, was because we wanted to switch screenshots to power + volume, and power key was in USC | 17:43 |
| mzanetti | AlbertA: so the reason this happens is because we thought using the power key would be a better idea than up/down | 17:43 |
| kgunn | e.g. workingn around volume notification is hard+hacky | 17:44 |
| kgunn | in shell | 17:44 |
| mzanetti | but I can see the point about moving the shotting logic to usc might be a bad idea | 17:44 |
| kgunn | so expose shell to power key instead ? | 17:44 |
| AlbertA | mzanetti: kgunn: ok...but how would volume + power key help? doesn't it still popup the volume notification? | 17:44 |
| kgunn | usc would filter i suppose | 17:45 |
| mzanetti | AlbertA: power + volume would help though | 17:45 |
| mzanetti | yeah, exposing the power key to unity might be way to go | 17:45 |
| josharenson | What if we just added the delay to volume key presses (and cancel on release) as we talked about earlier | 17:45 |
| kgunn | hacky | 17:46 |
| kgunn | mainly...but i thot it would work | 17:46 |
| AlbertA | mzanetti: sorry I still don't get it...how does power + volume help? I mean the volume notification comes in during a volume press | 17:46 |
| josharenson | kgunn, we should do that anyway as to make the button press order independent | 17:46 |
| mzanetti | AlbertA: well, we trigger the notification in the shell if the volume key is pressed down | 17:46 |
| kgunn | josharenson: don't have to convince me :) | 17:46 |
| alan_g | greyback_: if someone has to vet all the Qt code that could slow things a lot | 17:46 |
| mzanetti | AlbertA: but we can if() that with isPowerButtonPressed | 17:47 |
| greyback_ | alan_g: we rest a huge percentage of the platform on qt | 17:47 |
| AlbertA | mzanetti: aaahh ok... | 17:47 |
| greyback_ | if the policy is to avoid using qt for root-user processes, then there'll be a development time cost | 17:48 |
| AlbertA | greyback_: there's only a tiny bit of QT in USC, which can easily be replaced with dbus-cpp and process-cpp | 17:48 |
| alan_g | greyback_: I'm speculating - as I said I wasn't involved in the discussions | 17:48 |
| greyback_ | AlbertA: sure, but I'm asking if doing that is worth the trouble | 17:49 |
| AlbertA | mzanetti: josharenson: well anpok has a branch that kinda exposes the power key stuff through dbus, but it needs some work | 17:50 |
| alan_g | Anyway "don't use Qt in USC" dates from the "previous administration". We might want to check current thinking. | 17:50 |
| AlbertA | mzanetti: josharenson: including disabling taking action on power key presses | 17:50 |
| mzanetti | alan_g: ah... I thought that would be a new thing... would have surprised me | 17:50 |
| AlbertA | greyback_: well there's already a desire to refactor USC | 17:50 |
| * josharenson notes that could be helpful with orientation sensors as well | 17:51 | |
| AlbertA | greyback_: that would just be part of that refactoring | 17:51 |
| mzanetti | AlbertA: josharenson: yes, that sounds like the way to go | 17:51 |
| camako | Last time I asked why we have the nested configuration, the response was because we don't trust Qt, whereas, say, Google uses trusted code in their "shell". | 17:51 |
| greyback_ | AlbertA: ok great, then this is a good time to decide to use Qt in USC, or not. Mixing Qt and other libs is wasteful | 17:51 |
| AlbertA | greayback_: right! | 17:52 |
| mzanetti | but seriously... doing everything ourselves can't be more secure | 17:52 |
| josharenson | ok so, keep screenshots in shell, but use power key? | 17:52 |
| mzanetti | josharenson: yeah | 17:53 |
| josharenson | mzanetti, ok follow up question...\ | 17:53 |
| AlbertA | mzanetti: josharenson: I mean as a bandaid pending anpok's work... | 17:53 |
| alan_g | mzanetti: we do as little as possible in USC | 17:53 |
| greyback_ | kgunn: if security/trust is the main reason against Qt in USC, can we have a meeting to discuss this topic with some security team people? | 17:53 |
| josharenson | mzanetti, you are ok with adding a delay to the notification onVolumeKeyPressed, but canceling the delay onVolumeKeyReleased? | 17:53 |
| AlbertA | mzanetti: josharenson: just have USC not take action on power key presses if a volume key is also currently pressed down | 17:54 |
| josharenson | so you can do Vol + Power || Power + Vol for a screenshot | 17:54 |
| greyback_ | kgunn: just so we make the decision clear for all | 17:54 |
| mzanetti | josharenson: getting away with any delay/timers is the main thing we're doing this... | 17:55 |
| josharenson | AlbertA, do we support holding VolumeDown + Power for a hard reset? | 17:55 |
| mzanetti | josharenson: I guess Power+Vol, in that order, is enough | 17:55 |
| josharenson | mzanetti, ok so you think we should keep the screenshot button sequence order dependent... | 17:55 |
| josharenson | ok | 17:55 |
| AlbertA | josharenson: it should be button sequence independent | 17:55 |
| mzanetti | AlbertA: :D | 17:55 |
| josharenson | impossible to do without some kind of delay | 17:56 |
| AlbertA | josharenson: yo can know if a volume key is currently pressed and not released | 17:56 |
| josharenson | I know | 17:56 |
| mzanetti | AlbertA: but... then we need a delay, and we don't want to delay the volume notification that everyone uses, for the screenshot feature that noone uses | 17:56 |
| josharenson | but if you want to display the notification without a delay, then it will always be in screenshots | 17:56 |
| AlbertA | josharenson: oh yeah heh | 17:56 |
| josharenson | so you get delay, or order dependence... I'll implement order dependence, but make it easy to switch | 17:57 |
| AlbertA | josharenson: well actually maybe we can change USC so that it takes action on power key release rather than press | 17:57 |
| josharenson | AlbertA, but don't you hold power key for shutdown? | 17:58 |
| AlbertA | josharenson: yeah...I guess the 2s delay is too short.... | 17:59 |
| AlbertA | I remember now why I avoided the power key in the first place : | 18:00 |
| josharenson | ok, doing it the mzanetti way, and I'll add you all as reviewers so you can have a final argument ;-) | 18:00 |
| AlbertA | :) | 18:00 |
| josharenson | ha | 18:00 |
| mzanetti | :D | 18:00 |
| AlbertA | mzanetti: josharenson: so it's too convoluted to tell the volume notification to dissappear? | 18:02 |
| kgunn | ah good...didn't miss anything | 18:02 |
| === alan_g is now known as alan_g|EOW | ||
| josharenson | AlbertA, thought of that... but what if you WANT the volume notification in the screenshot | 18:03 |
| AlbertA | josharenson: :) well then there's nothing to change | 18:04 |
| josharenson | lol | 18:04 |
| mzanetti | AlbertA: you might only want it in the pic *sometimes* | 18:04 |
| mzanetti | :D | 18:04 |
| mzanetti | no? | 18:05 |
| josharenson | yeah | 18:05 |
| AlbertA | mzanetti: make it a system settings option ;)= | 18:05 |
| josharenson | 99% of the time you don't want it... but you might want to show someone how loud you are listening to a song at | 18:05 |
| mzanetti | AlbertA: requires it's setting in the welcome wizard, even | 18:05 |
| AlbertA | mzanetti: josharenson: so the main obstacles are, if power key press should come first, then how can USC know to ignore taking action? but it's the opposite in the shell.... | 18:07 |
| AlbertA | that means USC has to take actions on power key release, except for holding power key down for a period of time... | 18:07 |
| josharenson | AlbertA, you have to assume that the delay for a screenshot is shorter than that for shutdown | 18:07 |
| josharenson | so.. bad | 18:08 |
| AlbertA | then in that case the user has to race agains the 2S limit before the shutdown dialog comes in | 18:08 |
| mzanetti | AlbertA: yeah, that's already happening afaik | 18:08 |
| mzanetti | AlbertA: you only turn the screen off on release | 18:08 |
| mzanetti | AlbertA: so if then a vol button comes in, we'd need to cancel the shutdown menu | 18:08 |
| AlbertA | mzanetti: oh true.... | 18:09 |
| mzanetti | actually... the shutdown menu is already in the shell, so no problem with that | 18:09 |
| mzanetti | it's be nice to cancel the screen blanking on release though | 18:10 |
| AlbertA | mzanetti: right... | 18:10 |
| mzanetti | how do we cancel the screen blanking onRelease when the shutdown menu opens? | 18:10 |
| mzanetti | isn't it just setting event.accepted=true in the shell? | 18:10 |
| josharenson | I'm assuming this is why screenshot currently doesn't involve the power key | 18:11 |
| AlbertA | mzanetti: you would still race agains the 5sec shutdown timeout too though...but 5s should be enough time for the user to get a vol key in there and cancel that in USC as well | 18:11 |
| * josharenson checks android behavior | 18:11 | |
| AlbertA | mzanetti: there's already some logic in USC | 18:11 |
| AlbertA | to ignore power key presses within the 2sec window :) | 18:12 |
| greyback_ | how about something different? if you hold power & tap on the screen, it takes a screenshot? | 18:13 |
| josharenson | greyback_ so do you disable all other touch events when power is down? | 18:15 |
| mzanetti | greyback_: doesn't really solve that issue though | 18:15 |
| AlbertA | greyback_: I think you could probably get spurious screenshots while trying to shut off the phone | 18:15 |
| mzanetti | and you still need to cancel the screen blanking | 18:15 |
| josharenson | or if you had a fullscreen app, and touching the screen changed its state in any way, the screenshot would not be what the user expected | 18:15 |
| greyback_ | thinking out of the box here | 18:15 |
| mzanetti | AlbertA: so that new upcoming api will allow us to do that? | 18:15 |
| mzanetti | in that case, lets do it properly when we can... | 18:16 |
| AlbertA | mzanetti: well here's the branch: https://code.launchpad.net/~andreas-pokorny/unity-system-compositor/expose-powerkey-state-and-screen-toggle-controller-interface/+merge/240834 | 18:17 |
| AlbertA | anpok: ^ | 18:17 |
| AlbertA | mzanetti: you could potentially receive power key press, receive volume key press, disable screen toggling, take screenshot, and renable screen toggling after getting power key release | 18:19 |
| AlbertA | seems a bit dangerous though...as in....if abused or not done right, the user may not be able to shut off the screen | 18:20 |
| AlbertA | so maybe the API should be just disable screen toggling until the next power key release | 18:20 |
| mzanetti | AlbertA: yeah... sounds about right | 18:23 |
| mzanetti | although I think it wouldn't be that risky to disable and re-enable it in unity... | 18:24 |
| anpok | AlbertA: aye - still need to rework it | 18:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!