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