[10:12] <tsdgeos> dandrader: there?
[10:15] <tsdgeos> greyback: you there?
[10:15] <dandrader> tsdgeos, yes
[10:15] <greyback> tsdgeos: yep
[10:16] <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:17] <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:21] <tsdgeos> dandrader: greyback: can i compile qtmir on the phone with this qmake or do i need some special flags?
[10:22] <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:23] <tsdgeos> sorry ^_^
[10:24] <dandrader> tsdgeos, I also pass it PREFIX=/usr, although I'm not sure it it's really needed
[10:26] <greyback> dandrader: for qmake, that's not needed
[10:29] <Saviq> or!
[10:29] <Saviq> x-build!
[10:30] <Saviq> the cmake-based qtmir is migrating now ;)
[10:40] <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:41] <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:42] <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:43] <tsdgeos> ok, tx for the pointers
[10:44] <pstolowski> tsdgeos,  debian/control
[10:44] <tsdgeos> pstolowski: merging which branches?
[10:45] <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:46] <tsdgeos> pstolowski: ah unity8 just landed
[10:46] <tsdgeos> k
[10:46] <dandrader> oh... qtmir trunk now uses CMake
[10:47] <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:48]  * 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:49] <greyback> sorry
[10:49] <Saviq> easy to add
[10:49] <Saviq> copy/paste from usc
[10:49] <tsdgeos> pstolowski: ok, merged
[10:51] <pstolowski> tsdgeos, thanks
[10:53] <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
[11:08]  * tsdgeos keeps digging up
[11:08] <tsdgeos> dandrader: who calls QtEventFeeder::dispatch ?
[11:11] <tsdgeos> i guess mir
[11:11] <dandrader> tsdgeos, yes
[11:11]  * tsdgeos ends where he didn't want to end
[11:15] <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:16] <Saviq> s/has/had/
[11:16] <Saviq> s/dome/some/
[11:16] <greyback_> ok
[11:30] <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:31] <greyback_> naughty
[11:35] <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:36] <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:37] <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:38] <mzanetti> tsdgeos: merged 'em all
[13:47] <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:48] <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
[14:36] <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:41] <Saviq> seb128, the click store in general
[14:41] <Saviq> seb128, falling back to the .desktop file
[14:41] <seb128> thanks
[14:48] <Saviq> mzanetti, think you could prep a vivid silo? I'd want to focus on the first ota landing
[14:49] <Saviq> mzanetti, don't build yet, list_on_bottom_swipe is migrating already, but it's blocked in proposed for a while still
[14:50] <mzanetti> Saviq: sure. is there a spreadsheet entry already?
[14:50] <Saviq> mzanetti, no
[14:52] <mzanetti> ack
[14:55] <tsdgeos> mzanetti: what do you mean in https://code.launchpad.net/~aacid/unity8/deparment_jumping/+merge/243639 ?
[14:56] <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:58] <tsdgeos> weird
[14:58] <tsdgeos> i'll check
[14:58] <tsdgeos> maybe it really needs the scopes shell part
[15:00] <Saviq> greyback_, can you have a look at bug #1394645 please
[15:01] <ubot5`> bug 1394645 in The Webapps-core project "OSK doesn't appear after OA login" [Critical,Confirmed] https://launchpad.net/bugs/1394645
[15:04] <greyback_> Saviq: sure
[15:13] <Saviq> greyback_, it seems from the last comments like we might be on the hook there
[15:18] <greyback_> Saviq: yeah I think you're right
[15:27] <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:28] <Cimi> tsdgeos, I saw you filled the description so I thought it was good to go :)
[15:43] <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:44] <Saviq> kgunn, they're "ours" in the sense there might be little or more work in it
[15:44] <Saviq> for us
[15:46] <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:48] <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:49] <tsdgeos> i am a lier
[15:49] <tsdgeos> you got me
[15:49] <Cimi> :D
[15:50] <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:55] <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:56] <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:57] <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:58] <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:59] <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?
[16:00] <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:01] <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:02] <Cimi> Saviq, will chase again
[16:02] <mterry> Cimi, thanks!
[16:03] <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:05] <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:07] <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:08] <Saviq> greyback_, any chance for a fix for 18.12?
[16:09] <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:11] <tsdgeos> mzanetti: you tried  lp:~aacid/unity8/deparment_jumping  on rtm or vivid?
[16:13] <mzanetti> tsdgeos: vivid
[16:15] <tsdgeos> ok
[16:20] <dandrader> mterry, got an MP for you to review https://code.launchpad.net/~dandrader/unity8/greeterRefactoring/+merge/243823
[16:21] <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:25] <Saviq> tsdgeos, I'll wait for moreAsyncDash before landing the other bits in rtm, ok?
[16:25] <tsdgeos> Saviq: sure
[16:26] <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:27] <Cimi> so for monday we are ok to go?
[16:27] <tsdgeos> hmmm
[16:28] <tsdgeos> actually did i lose the hability to retrigger builds?
[16:28] <tsdgeos> Saviq: any idea? ↑
[16:29] <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:33]  * greyback_ hates that QtCreator just fails to open cmake project if a dependency is missing
[16:49] <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:50] <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:59] <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
[17:00] <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:07] <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:08] <greyback_> josharenson: it does, just via a different mechanism.
[17:08] <josharenson> greyback_ I figured.. ok ill go look for it
[17:09] <greyback_> josharenson: have a look at mir::scene::Session::take_snapshot
[17:09] <josharenson> cool
[17:10] <greyback_> an example of it being used is in qtmir: src/modules/Unity/Application/applicationscreenshotprovider.cpp
[17:13] <josharenson> ack, thanks
[17:18] <josharenson> hummm so if screenshots are handled in USC, how will the user receive feedback
[17:20] <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:21] <josharenson> libpng
[17:21] <mzanetti> josharenson: QImage::saveToFile()
[17:22] <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:23] <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:24] <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:25] <josharenson> mzanetti, so... any disadvantage to adding more? Just trying to keep screenshots shell agnostic
[17:26]  * 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:27] <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:28] <greyback_> true
[17:28] <josharenson> and libpng could, I assume, save the raw pixel data to $USER
[17:28] <josharenson> well after encoding
[17:29] <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:30] <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:31] <mzanetti> yeah... I understand that... did anyone tell you to avoid Qt?
[17:32] <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:34] <mzanetti> ah... you I guess you'll have to clarify if that's true. would be news to me.
[17:36] <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:38] <alan_g> AIUI there were security concerns about Qt in a privileged task. (But I wasn't directly involved in those discussions)
[17:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <greyback_> AlbertA: sure, but I'm asking if doing that is worth the trouble
[17:50] <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:51]  * 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:52] <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:53] <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:54] <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:55] <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:56] <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:57] <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:58] <josharenson> AlbertA, but don't you hold power key for shutdown?
[17:59] <AlbertA> josharenson: yeah...I guess the 2s delay is too short....
[18:00] <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:02] <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:03] <josharenson> AlbertA, thought of that... but what if you WANT the volume notification in the screenshot
[18:04] <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:05] <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:07] <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:08] <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:09] <AlbertA> mzanetti: oh true....
[18:09] <mzanetti> actually... the shutdown menu is already in the shell, so no problem with that
[18:10] <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:11] <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:12] <AlbertA> to ignore power key presses within the 2sec window :)
[18:13] <greyback_> how about something different? if you hold power & tap on the screen, it takes a screenshot?
[18:15] <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:16] <mzanetti> in that case, lets do it properly when we can...
[18:17] <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:19] <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:20] <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:23] <mzanetti> AlbertA: yeah... sounds about right
[18:24] <mzanetti> although I think it wouldn't be that risky to disable and re-enable it in unity...
[18:39] <anpok> AlbertA: aye - still need to rework it