[07:27] <Saviq> thomi, dude, you spent most of the day on two issues that are known / fixed already...
[07:29] <Saviq> thomi, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1235159
[07:29] <Saviq> thomi, and http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/397
[07:38] <tsdgeos> Saviq: so any special bug you want me to look at or shall i continue with the delegate creation range thing?
[07:39] <Saviq> tsdgeos, can you have a look at https://bugs.launchpad.net/unity8/+bug/1124567
[07:39] <Saviq> tsdgeos, we've had to revert that over the weekend, 'cause the activity indicator used CPU all the time
[07:40] <Saviq> tsdgeos, if you can reduce to a testcase and fila a bug against SDK
[07:40] <Saviq> tsdgeos, hi, btw!
[07:40] <tsdgeos> hallo
[07:40] <tsdgeos> so devdays is today or tomorrow?
[07:40] <tsdgeos> s/is/starts
[07:40] <Saviq> tsdgeos, today
[07:41] <tsdgeos> i see
[07:42] <Cimi> Saviq, morning
[07:42] <Saviq> hey Cimi
[07:42] <Cimi> Saviq, good weekend? london finally got some sun, it's a pity it's monday :)
[07:43] <Saviq> Cimi, nothing much, but thanks
[07:43] <Saviq> Cimi, pretty London-y here now (dark'n'grey)
[07:43] <Cimi> Saviq, here too, we have fog :(
[07:44] <tsdgeos> Saviq: not sure about that bug, is the bug "ActivittyIndicator takes lots of CPU" or "ActivittyIndicator takes lots of CPU even when not spinning"?
[07:44] <Saviq> tsdgeos, the latter
[07:44] <Cimi> Saviq, I wanted to see why style is causing the hangs, you have ideas?
[07:44] <tsdgeos> i see
[07:44] <Cimi> tsdgeos, it's the style SDK property causing the hanfs
[07:44] <Cimi> tsdgeos, hangs
[07:44] <tsdgeos> :/
[07:45] <Cimi> I might need help to debug
[07:45] <Cimi> I think we might need to use some qtcreator debug modes/profiler
[07:45] <Saviq> Cimi, that's easy
[07:45] <Cimi> which I never used
[07:45] <Saviq> Cimi, get it to hang
[07:45] <Cimi> Saviq, that's easy :)
[07:46] <Saviq> Cimi, ah, run it through run_on_device, get it to hang
[07:46] <Saviq> or well, pass -qmljdebuggingport or whatever the option is (see in run_on_device near the top)
[07:48] <Saviq> Cimi, then, in QtCreator Analyze → QML Profiler (External) → set "Host" to your device's IP → let it run for 10s
[07:48] <Saviq> Cimi, but I'm 90% certain you'll get zilch - no QML events will happen - it's probably hanging in the scenegraph
[07:49] <Saviq> Cimi, to confirm that - make it hang, and run `gdb program $(pidof unity8)`
[07:49] <Saviq> Cimi, that will connect gdb to the process and let you see what the threads are doing
[08:22] <tsdgeos> Saviq: no bug in the ActivityIndicator, just a bug in our side
[08:23]  * tsdgeos proposes branch
[08:23] <Saviq> tsdgeos, yay
[08:23] <Saviq> tsdgeos, couldn't pinpoint it late on Friday, and couldn't be bothered over the weekend ;)
[08:23] <tsdgeos> :-)
[08:23] <greyback> Greetings from Qt DevDays
[08:24] <tsdgeos> greyback: aloha
[08:24] <greyback> tsdgeos: yo yo
[08:25] <Saviq> greyback, o/
[08:26] <greyback> Saviq: hey
[08:26]  * Saviq f**ed up for not being there
[08:26] <mhr3> Saviq, reverted activity-indicator? :(
[08:26] <Saviq> mhr3, will be right back
[08:27] <Saviq> mhr3, caused constant CPU usage, but tsdgeos just found the issue
[08:27] <mhr3> wonder how much is it going to conflict isactive
[08:27] <tsdgeos> none
[08:27] <tsdgeos> just wait
[08:27] <tsdgeos> until i commit my stuff
[08:27] <tsdgeos> or base your stuff in mine
[08:28] <Saviq> mhr3, just going through previews now, will get to -isactive afterwards
[08:28] <tsdgeos> it's just one line
[08:28] <tsdgeos> well actually two
[08:29] <tsdgeos> mhr3: Saviq: https://code.launchpad.net/~aacid/unity8/unrevert376/+merge/189544
[08:29] <mhr3> why do we hide that empty search can take a while as well?
[08:30] <tsdgeos> do what?
[08:30] <Saviq> tsdgeos, ah, we didn't protect against scope [08:30] <mhr3> tsdgeos,
[08:30] <mhr3> +                            name: "searching"
[08:30] <mhr3> 68	+                            when: scope && scope.searchInProgress && searchField.text !== ""
[08:31] <tsdgeos> Saviq: yep
[08:31] <Saviq> stoopid
[08:31] <tsdgeos> mhr3: http://bazaar.launchpad.net/~aacid/unity8/unrevert376/revision/401 is my change
[08:31] <tsdgeos> mhr3: the rest was there already
[08:31] <tsdgeos> don't ask me why you do something you did :D
[08:32] <mhr3> yes, i should have reviewed the qml part too, but this gives me second chance :)
[08:32] <tsdgeos> or someone else, not sure if it was you who did the original code
[08:33] <tsdgeos> ah, it was nic-doffay's
[08:33] <mhr3> Saviq, your thoughts about removing the .text condition from the states?
[08:34] <Saviq> mhr3, right
[08:34] <Saviq> mhr3, didn't think that's when it'd come up
[08:34] <Saviq> tsdgeos, can you? drop the !== "" / [08:36] <tsdgeos> if you want me
[08:36] <Saviq> tsdgeos, yes please
[08:36] <tsdgeos> it's not like i've checked the code
[08:36] <Saviq> mhr3, any reason why a preview.subtitle would have newlines?
[08:39] <tsdgeos> Saviq: mhr3: pushed
[08:39] <Saviq> tsdgeos, thanks
[08:57] <mhr3> Saviq, not really... scopes misusing it for something?
[08:57] <Saviq> mhr3, right, that's what I thought - so removed "support" for it
[08:57] <mhr3> k
[09:09] <Saviq> seb128, I'm offended :P Why isn't PL in the set of languages installed on the device?
[09:10] <Saviq> seb128, more, why installing the langpacks and generating locale doesn't work anymore for setting the language? is there a new trick to change locale?
[09:11] <seb128> Saviq, the list is my number of speakers, you need to teach more being to speak pl it seems ;-)
[09:12] <Saviq> seb128, I don't mean the list in settings app
[09:12] <seb128> Saviq, it doesn't work because the system image is ro and you can't install langpacks...
[09:12] <Saviq> seb128, most recent image has some langpacks
[09:12] <Saviq> seb128, and that's where pl isn't included
[09:12] <seb128> Saviq, right, we seeded the same as on the desktop image
[09:12] <seb128> Saviq, zh > es > pt > de > fr
[09:12] <seb128> Saviq, that's ranked by "usefulness"
[09:12] <Saviq> seb128, but even making it rw and installing the langpack / changing /etc/environment doesn't seem to work correctly
[09:12] <Saviq> seb128, yeah, I know, j/k
[09:13] <seb128> Saviq, how "not correctly"?
[09:13] <Saviq> seb128, or well, it changes *some* of the UI
[09:13] <Saviq> seb128, but not e.g. scopes
[09:13] <seb128> Saviq, the settings app use accountsservice which writes ~/.pam_environment
[09:13] <seb128> Saviq, what langpack did you install?
[09:13] <Saviq> seb128, ah, let me try that
[09:13] <Saviq> seb128, -gnome-pl
[09:13] <seb128> Saviq, lot of the scopes strings are new
[09:14] <seb128> Saviq, https://translations.launchpad.net/ubuntu/saucy/+source/unity-scope-home/+pots/unity-scope-home
[09:14] <seb128> Saviq, yeah, there is no polish translation, stop slacking :p
[09:14] <Saviq> OH!
[09:15] <seb128> Saviq, not sure if you are part of the pl translators team, if you are, just go to https://translations.launchpad.net/ubuntu/saucy/+source/unity-scope-home/+translations and do some work ;-)
[09:16] <Saviq> seb128, yeah, will have to
[09:16]  * Saviq frowns at the pl translators team
[09:18] <Saviq> mhr3, we had somewhere a fix that stopped activating entries other than apps, remember where?
[09:19] <mhr3> Saviq, dont remember such thing, why would we want that?
[09:19] <Saviq> mhr3, because we want previews for everything other than apps?
[09:20] <mhr3> Saviq, oh, that kind of activating... it's part of the previews transitions
[09:20] <Saviq> mhr3, right, good
[09:20] <mhr3> lp:~mzanetti/unity8/switching-previews
[09:20] <mhr3> Saviq, ^ that one
[09:21] <Saviq> mhr3, yup, next in my q
[10:12] <mhr3> Cimi, will your branch adding the new styles for dash plugins and weather come back?
[10:12] <Cimi> mhr3, who knows
[10:12] <mhr3> Cimi, needs to be fixed in sdk first?
[10:12] <Cimi> mhr3, I think
[10:13] <mhr3> anyone working on that?
[10:13] <Cimi> mhr3, but it's early to confirm
[10:13] <Cimi> I'm compiling on the phone
[10:13] <Cimi> slow boot this morning
[10:22] <mhr3> Saviq, think we have an issue with caching - if results are showing "image://thumbnailer/foo" and preview uses the same string for their main image, it'll end up using the low-res image from the result instead of requesting new one with different requestedSize from thumbnailer
[10:23] <Saviq> mhr3, hmm, interesting... shouldn't happen IIUC
[10:23] <Saviq> mhr3, it should cache per-requestedSize
[10:23] <mhr3> Saviq, sure about that?
[10:23] <Saviq> mhr3, yeah - it'd break SVGs, for example, otherwise
[10:24] <mhr3> would explain why svgs look horrible
[10:24] <mhr3> :)
[10:24] <Saviq> mhr3, well, yeah
[10:24] <Saviq> mhr3, can you confirm with a small test? loading the same svgs twice with different sourceSize
[10:25] <Saviq> mhr3, and see if the order in which you load them makes a difference?
[10:25] <mhr3> was hoping you'd know this
[10:25] <mhr3> tsdgeos, maybe you do ^?
[10:26] <tsdgeos> mhr3: same url == same image
[10:26] <tsdgeos> if you want different images
[10:26] <tsdgeos> add the image to the url or something
[10:26] <mhr3> tsdgeos, so noone cares that svgs are broken with qt?
[10:26] <dednick> mhr3: you sure you havent got a copy of the image as a png somewhere? i was having an issue where I had icons as svg and png, but it was loading the png
[10:27] <tsdgeos> mhr3: nope :D
[10:27] <mhr3> dednick, i'm coming to this conclusion from the thumbnailer, it just explains svgs as well
[10:28] <tsdgeos> mhr3: it's not that noone cares obviously, it's that there's noone with the willingness to fix it
[10:28] <tsdgeos> which is kind of the same thing :D
[10:28] <dednick> mhr3: my old thumbnailer?
[10:28] <dednick> from unity?
[10:29] <mhr3> dednick, nah, we have a new one now
[10:29] <Saviq> tsdgeos, really? it caches regardless of requestedSize? that's broken ;(
[10:29] <dednick> thank god
[10:29] <mhr3> dednick, but actually i think the caching in unity7 has exactly the same issue
[10:29] <Saviq> tsdgeos, mhr3 granted, it's not *that* simple - it's probably the image provider that should be able to provide a hash under which the image is cached
[10:30] <tsdgeos> Saviq: hmmm what's requestedSize?
[10:30] <tsdgeos> there's no such property
[10:30] <Saviq> tsdgeos, sourceSize
[10:30] <Saviq> tsdgeos, → that's requestedSize when requesting an image from an image provider
[10:30] <tsdgeos> Saviq: well, you should not be touching sourceSize afaics
[10:30] <tsdgeos> "This property holds the actual width and height of the loaded image."
[10:30] <Saviq> tsdgeos, HUHE!Q
[10:30] <Saviq> tsdgeos, you get a slap
[10:31] <tsdgeos> hmmmm
[10:31] <tsdgeos> otoh
[10:31] <tsdgeos> "Note: Changing this property dynamically causes the image source to be reloaded, potentially even from the network, if it is not in the disk cache."
[10:31] <Saviq> tsdgeos, read the whole thing - print out
[10:31] <Saviq> tsdgeos, and stick over your bed
[10:31] <mhr3> Saviq, yep, that would fix it cleanly, but i don't think it's possible atm
[10:32] <tsdgeos> Saviq: my bed is behind me, won't help much sticking it there
[10:32] <Saviq> mhr3, yeah - let's just pass ?width=x&height=y?
[10:33] <tsdgeos> Saviq: ok, so the first line definition of the property is crap-ish
[10:33] <Saviq> tsdgeos, true
[10:33] <Saviq> mhr3, so that category renderer and preview request different, but static URLs?
[10:33] <tsdgeos> and yeah sounds like a bug that it doesn't take into account the size
[10:33] <mhr3> Saviq, i'm afraid we don't have that where the uri is created
[10:33] <tsdgeos> are we sure it's not us doing that?
[10:33] <Saviq> tsdgeos, you told us so! :D
[10:34] <Saviq> mhr3, can you verify?
[10:34] <tsdgeos> Saviq: well, i'm not infallible by far... :D
[10:34] <Saviq> mhr3, a simple two-Image with onClicked: source = "blah"
[10:34] <mhr3> yep, but not right away :)
[10:34] <Saviq> mhr3, ok, let me have a try
[10:35] <tsdgeos> hmmm
[10:36]  * tsdgeos retracts the hmmm
[10:36] <tsdgeos> who provides thumbnailer:// libunity?
[10:37] <mhr3> tsdgeos, sdk
[10:37] <mhr3> trunk sdk anyway
[10:39] <tsdgeos> hmmm
[10:39] <tsdgeos> doesn't look like that code is doing anything with the desiredSize?
[10:39] <tsdgeos> well, it is, but just to decide what other size it'll give you
[10:40] <mhr3> the difference between preview image size and results should be big enough
[10:40] <tsdgeos> hmmm
[10:40] <tsdgeos> actually not
[10:41] <tsdgeos> i should learn how to read :D
[10:41] <tsdgeos> man what a morning...
[10:41] <sil2100> Reading is overrated
[10:47] <Cimi> Saviq, ok, I've ref lashed, compiled, had a couple of teas to wake up
[10:47] <tsdgeos> mhr3: Saviq: ok, code shows that requestedSize is taken into account for the caching
[10:47] <Cimi> Saviq, I have gdb opened
[10:47] <tsdgeos> mhr3: Saviq: so it "should" work
[10:47] <Cimi> Saviq, I run bt and it gives me
[10:47] <Cimi> #0  0x40b3568a in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
[10:47] <Cimi> #1  0x40b37324 in malloc () from /lib/arm-linux-gnueabihf/libc.so.6
[10:47] <Cimi> #2  0xdea19b8e in ?? ()
[10:47] <Cimi> #3  0xdea19b8e in ?? ()
[10:47] <Cimi> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[10:47] <Cimi> which is not very useful
[10:47] <Cimi> (sorry for not using paste bin, my fault)
[10:48] <tsdgeos> mhr3: Saviq: http://pastebin.kde.org/pqmpq60ka
[10:48] <mhr3> Cimi, i was looking at it on friday too, it changes depending when you break
[10:49] <mhr3> Cimi, i was getting this malloc thing or something quite deep in qtqml.so
[10:49] <tsdgeos> mhr3: so if you can verify it doesn't work it's probably broken somwhere up in the stack?
[10:49] <Cimi> help guys
[10:50] <tsdgeos> Cimi: start by install debug symbols for libc
[10:50] <mhr3> tsdgeos, hm, you sure that code path is executed? :)
[10:50] <Saviq> mhr3, hmm, nope, can't confirm what you're saying
[10:50] <tsdgeos> mhr3: pretty much
[10:50] <tsdgeos> mhr3: it's just after the requestImage code
[10:50] <tsdgeos> and that one does get executed :D
[10:50] <mhr3> hm, in that case thumbnailer must be broken
[10:51] <tsdgeos> mhr3: where's the thumbnailer code?
[10:51] <Saviq> mhr3, http://paste.ubuntu.com/6204437/
[10:51] <Saviq> mhr3, regardless of the order of clicking
[10:51] <Saviq> mhr3, the large image is the same
[10:53] <Cimi> guys, I throw it
[10:53] <Cimi> would be nice to have a flag for phablet-flash that automatically enables developer mode (and some packages already preinstalled)
[10:54] <Cimi> so we flash a second zip with writeable root, all our development crap already installed
[10:55] <Cimi> like phablet-flash ubuntu-system --developer-mode
[10:56] <mhr3> tsdgeos, lp:thumbnailer
[10:57] <Saviq> Cimi, thing is... which packages would you install?
[10:57] <mhr3> Saviq, ok my bad for svgs, was looking at some results from foursquare, thought it's giving svgs but they're low-res pngs :/
[10:58] <Cimi> Saviq, the common stuff to both ubuntu sdk and shell
[10:58] <Cimi> Saviq, writeable image
[10:58] <mhr3> dednick_, 1:0 for you
[10:58] <Saviq> Cimi, I get what you mean, I'm not totally convinced, though ;)
[10:59] <Saviq> Cimi, feels like that would only be useful for us, really
[10:59] <Cimi> Saviq, well, we *all* do the same thing every time we install
[10:59] <Cimi> Saviq, we enable and reinstall the usual packages
[10:59] <Cimi> Saviq, "us" is many engineers
[10:59] <Saviq> Cimi, that is true, so a channel=unity8-development or something
[10:59] <Cimi> Saviq, whatever yeah
[10:59] <Saviq> Cimi, yeah, but it's very specific to what we do
[11:00] <Saviq> Cimi, and then we'd end up having hundreds of channels
[11:00] <Saviq> Cimi, thing is you don't need to flash all the time
[11:00] <Cimi> Saviq, well, we are the most important one
[11:00] <Saviq> of course we are lol
[11:00] <mhr3> anyway, i'll go bother satoris about something broken in thumbnailer
[11:00] <Saviq> Cimi, if you make it read-write, just dist-upgrade
[11:00] <Saviq> mhr3, give him that QML for testing
[11:00] <mhr3> Saviq, right, thx for that
[11:01] <Cimi> Saviq, would be nice to flash and start working immediately instead of wasting time apt-getting the same things and rebooting
[11:01] <Saviq> mhr3, if it results in two requests to the thumbnailer - tb is broken - otherwise it's Qt
[11:01] <Saviq> Cimi, just don't waste time flashing
[11:01] <Saviq> Cimi, and apt-get update / upgrade
[11:01] <Saviq> Cimi, it's the same result
[11:02] <Saviq> Cimi, unless you really need a particular image
[11:02] <Cimi> Saviq, I'm super lazy and I'm trying to simplify my life
[11:02] <Cimi> Saviq, laziness can be a great virtue ;)
[11:02] <Saviq> Cimi, what's simpler about flashing than update/dist-upgrade?
[11:03] <Cimi> Saviq, sometimes it screws
[11:03] <Cimi> anyway ok
[11:03] <Saviq> Cimi, `adb shell "apt-get update; apt-get -y dist-upgrade"`
[11:03] <mhr3> Saviq, i think it'd be the other way around ;)
[11:03] <tsdgeos> caches everywhere! :D
[11:03] <tsdgeos> so we cache at the Thumbnailer level and at the QML level
[11:04] <mhr3> Saviq, ...eh, yea, no... nvm :)
[11:05] <Saviq> tsdgeos, but tb is on-disk, QML is in mem
[11:05] <Saviq> tsdgeos, and well, we disable caching in-mem for previews IIRC
[11:05] <Saviq> tsdgeos, also, tb is reusable between apps -  QML cache isn't
[11:09] <tsdgeos> mhr3: ok, on a second look at the thumbnailer:// code
[11:09] <tsdgeos> i did read it correctly the first time
[11:10] <tsdgeos> and just uses the requestedSize to switch between TN_SIZE_SMALL, TN_SIZE_LARGE and TN_SIZE_ORIGINAL
[11:11] <mhr3> tsdgeos, what's wrong about that?
[11:11] <tsdgeos> that it won't give you the size you really want?
[11:11] <mhr3> right, but previews are surely bigger than 256
[11:12] <dednick_> mhr3: cookie please
[11:13] <mhr3> dednick_, lots of them at the office :)
[11:13] <tsdgeos> mhr3: what you mean with "are surely bigger than 256"? that you should be getting the "original size"?
[11:13] <mhr3> tsdgeos,
[11:13] <mhr3> right
[11:13] <Cimi> http://paste.ubuntu.com/6204498/
[11:13] <mhr3> i was seeing pixelation on video that had original res 1280x800
[11:14] <tsdgeos> ok
[11:14] <Cimi> tsdgeos, Saviq ^
[11:14] <tsdgeos> Cimi: is it stuck there?
[11:14] <Cimi> tsdgeos, yes
[11:15] <Saviq> not good
[11:15] <mhr3> it's not stuck though... it's spinning around it
[11:15] <mhr3> somehow
[11:16] <tsdgeos> Cimi: so if you say continue and break again it'll get the same backtrace?
[11:18] <Cimi> tsdgeos, continue?
[11:18] <Cimi> in gdb?
[11:18] <tsdgeos> Cimi: ye
[11:18] <Cimi> let me rehang the thing
[11:21] <Cimi> http://paste.ubuntu.com/6204523/
[11:21] <Cimi> same hang
[11:21] <Cimi> just a different call
[11:21] <Cimi> let me do continue
[11:22] <Cimi> tsdgeos, what is continue supposed to do?
[11:22] <tsdgeos> Cimi: continue executing the program?
[11:22] <Saviq> Cimi, c
[11:22] <Cimi> tsdgeos, well it says continuing
[11:22] <Saviq> Cimi, continue
[11:22] <Cimi> but doesn't move
[11:22] <Saviq> Cimi, then ctrl+c
[11:22] <Cimi> I'll debug gdb now :P
[11:22] <Saviq> Cimi, then bt again
[11:22] <Cimi> gdb program pidof gdb :D
[11:23] <Cimi> same stuff guys
[11:23] <Saviq> tsdgeos, Cimi, feels like SDK's theming gets stuck in creating the delegate?
[11:24] <tsdgeos> Cimi: is it exactly the same backtrace?
[11:24] <Cimi> this is after http://paste.ubuntu.com/6204545/
[11:24] <Cimi> tsdgeos, no
[11:24] <Cimi> lil difference
[11:24] <Cimi> Kaleo, ^
[11:24] <Saviq> Cimi, remember he's in Brazil? ;)
[11:25] <Saviq> Cimi, anyway, he won't be able to do *anything* from that
[11:25] <Cimi> Saviq, I do, but he was replying :P
[11:25] <Cimi> in #sdk :)
[11:25] <tsdgeos> from what i can see from the BT
[11:25] <tsdgeos> it's trying to create the item with index 1
[11:26] <tsdgeos> which now i see is done async
[11:26] <Saviq> tsdgeos, re: showNow
[11:26]  * tsdgeos hits himselfs and hides at the same time
[11:26] <Saviq> tsdgeos, it's now in Mir's plate
[11:27] <Saviq> tsdgeos, they need to flush the buffers after blanking / before unblanking for us to be able to push a new frame
[11:27] <Kaleo> Saviq: tsdgeos: Cimi before you go any further; bug report
[11:27] <tsdgeos> Saviq: ok
[11:28] <tsdgeos> Saviq: so approve?
[11:28] <Saviq> tsdgeos, yes
[11:30] <tsdgeos> ah, it's async because it's inside the viewport, "makes sense" (talking to myself)
[11:40] <Cimi> Kaleo, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1236316
[12:03] <mhr3> Saviq, this is weird - http://imgur.com/UsglIHA
[12:04] <mhr3> Saviq, that's what i see on the phone, yet the image itself it full-res
[12:04] <Saviq> mhr3, looks like sourceSize is bad there?
[12:05] <Saviq> mhr3, same with switching-previews branch?
[12:05] <mhr3> Saviq, don't have that one on the phone
[12:05] <Saviq> mhr3, you can run on desktop and should see the same
[12:06] <mhr3> time to install mediascanner
[12:09] <Cimi> Saviq, shall I redo all the renderers without using style?
[12:09] <Saviq> Cimi, not yet - we should instead try & solve the issue
[12:10] <Saviq> tsdgeos, you stopped talking to yourself? got somewhere?
[12:10] <Cimi> Saviq, I dunno where to start though with this one
[12:11] <Cimi> Saviq, downloading qt source and reading those files?
[12:11] <Saviq> Cimi, tsdgeos will (is) look(ing) at it
[12:11] <Saviq> Cimi, as it might be something int the LVWPH
[12:12] <Saviq> /food
[12:12] <mhr3> Saviq, seems to work fine with switching-preivews
[12:13] <Cimi> /food
[12:13] <mhr3> Saviq, otoh all previews look washed out with switching-previews
[12:13] <mhr3> like some semi-transparent layer was on top of them
[12:14] <Mirv> Saviq: any idea why some unity8 tests have started failing on desktop while they continue to work on device? http://10.97.0.1:8080/job/autopilot-saucy-daily_release/2409/label=autopilot-intel/artifact/results/autopilot/autopilot.log
[12:16] <Mirv> Saviq: because of various cu2d problems I'm not sure if it happened already with the release that's in, or if the mir startup fix is somehow causing it.
[12:16] <Mirv> I only know the errors happened this morning, twice, while they didn't happen on Friday morning
[12:17] <Saviq> Mirv, looking at those errors I'd say notify-osd is running
[12:17] <Saviq> Mirv, and taking the notifications over
[12:18] <Saviq> Mirv, yeah "Service name already taken."
[12:18] <Saviq> Mirv, until now it was fine 'cause nothing triggered notify-osd to start
[12:18] <Mirv> Saviq: ok. given that we focus on touch and manual testing there gives +1, I'd tend to ignore it but good to check.
[12:18] <Mirv> Saviq: so apparently now something triggers it then. do you want a bug about that?
[12:19] <Saviq> Mirv, not against unity8, no ;)
[12:19] <Mirv> Saviq: yeah I just started thinking that it's not unity8's problem as such :)
[12:19] <Saviq> Mirv, we probably shouldn't be running unity7 under unity8 tests
[12:19] <Saviq> Mirv, but while we are - we need to make sure notify-osd is killed
[12:19] <Saviq> Mirv, are other tests ran in that run?
[12:20] <Saviq> Mirv, like gallery or something?
[12:20] <Saviq> Mirv, if that's the case - move unity8 to the front
[12:20] <Saviq> Mirv, we've had the same on upstream merger
[12:20] <Saviq> Mirv, gallery tests triggered notify-osd and ours were failing
[12:21] <Mirv> Saviq: not directly in that, gallery-app is ran with different set of packages
[12:21] <Mirv> Saviq: it should be only running unity8-autopilot in case of unity8 stack
[12:26] <Mirv> Saviq: anyhow, marked down a note about the problem on desktop side and published unity8 with the mir-side AP fix
[12:31] <Saviq> Mirv, thanks!
[12:55] <tsdgeos> Saviq: my internal talking was just about why something was being created sync, that i understood why
[12:55] <tsdgeos> Saviq: having a look at why stuff is hanging now
[12:55] <tsdgeos> Cimi: it did not happen on the desktop right?
[12:55] <Cimi> tsdgeos, no
[12:55] <tsdgeos> that's weird indeed
[12:57] <Cimi> tsdgeos, try no?
[12:57] <Cimi> tsdgeos, just expand applications and scrol
[13:18] <tsdgeos> wops
[13:18] <tsdgeos> i changed run_on_device by mistake and nobody realized :D
[13:22] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/bring_back_id_rsa/+merge/189597
[13:23] <Saviq> tsdgeos, yeah I saw that
[13:23] <tsdgeos> sorry
[13:23] <Saviq> tsdgeos, while you're at it
[13:23] <Saviq> tsdgeos, can you fix ssh to not rm, but to truncate /etc/init/ssh.override?
[13:23] <Saviq> tsdgeos, or actually... start ssh on both -s and non-(-s)
[13:24] <Saviq> tsdgeos, we probably don't want to make ssh start by default for people
[13:24] <Saviq> tsdgeos, but enable it when needed instead
[13:25] <tsdgeos> Saviq: got lost, want me to do anything with /etc/init/ssh.override or just add the start ssh call?
[13:26] <Saviq> tsdgeos, let's not do anything with the .override
[13:26] <Saviq> tsdgeos, but start ssh when needed - not only on --setup
[13:26] <tsdgeos> yep
[13:33] <kgunn> MacSlow: so rcv call notif ended up being a unity-mir bug ?
[13:33] <MacSlow> kgunn, partly...
[13:35] <MacSlow> kgunn, the fix needed to make it work on mir (adding an InputFilterArea around the notifications ListView) showed a bug in mir
[13:37] <mterry> racarr, do you know why enabing Mir would prevent unity8 from receiving signals from a dbus daemon that isn't root?
[13:37] <kgunn> alan_g: ^
[13:39] <alan_g> kgunn, mterry: Mir itself doesn't touch dbus
[13:39] <mterry> alan_g, that's what I would think.  Yet here we are  :)  It's probably (I'm guessing) more some effect enabling unity-mir has?
[13:42] <kgunn> alan_g: we're actually talking on the unity standup..thinking is that unity-mir might have a role here
[13:43] <mterry> "thinking" == "wild guess"  :)
[13:43] <kgunn> mterry: true...but at least it actually touches dbus in some way :)
[13:43] <mterry> fai
[13:43] <mterry> fair
[13:43] <alan_g> mterry: I'd be guessing. I don't know most of what enabling unity-mir entails.
[13:46] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/start_ssh/+merge/189602
[13:54] <Saviq> tsdgeos, s/service/initctl/
[13:55] <Saviq> tsdgeos, and maybe we should get SSH_STARTED from initctl status ssh instead?
[13:55] <Saviq> tsdgeos, and maybe even stop it on exit
[13:55] <Saviq> tsdgeos, if it wasn't started before us
[13:55] <tsdgeos> ok, can do that
[13:55] <tsdgeos> was aiming for a low smartness solution :D
[13:56] <tsdgeos> so
[13:56] <tsdgeos> check status on start, start if needed, stop if was not started?
[13:56] <tsdgeos> Saviq: ↑↑
[13:57] <Saviq> tsdgeos, yeah
[13:57] <Saviq> tsdgeos, and merge with your bring_back_id_rsa - let's not torment jenkins
[13:58] <tsdgeos> :D
[13:58] <tsdgeos> ok
[14:01] <pstolowski_> nic-doffay: ping
[14:04] <tsdgeos> Saviq: that hang stuff is ugly
[14:05] <tsdgeos> no clue why it only happens on the phone though
[14:05] <tsdgeos> but it's basically stuff "loading" a component and that component thinks it's loaded
[14:05] <tsdgeos> or something like that
[14:05] <tsdgeos> not totally sure i get it
[14:05] <tsdgeos> but it's basically while looping "doing nothing"
[14:06] <Saviq> tsdgeos, ouch
[14:06] <tsdgeos> compiling qtdeclarative on the device with debug enabled so i can add a few more qdebugs here and there
[14:07] <Saviq> mterry, ah, I forgot - the stats welcome screen qml test is somewhat flaky
[14:07] <Saviq> mterry, hrm wait, ignore
[14:08] <Saviq> dandrader, I meant your minimizingAppTakesToRunningApps test ↑↑
[14:08] <Saviq> dandrader, when you have some free cycles, try and see if it can be improved
[14:09] <dandrader> Saviq, it could just be skipped for now if it's giving Jenkins some headaches
[14:09] <mterry> phew  :)
[14:12] <kgunn> dednick_: know anything about location services/indicator  not working like in the lastest image  ?
[14:27] <dednick_> kgunn: nope. by not working, you mean not showing up?
[14:28] <kgunn> dednick_: yeah...that's the report...like no effect in the ui (i suspect backend...but its going to get some attention soon)
[14:29] <nic-doffay> pstolowski_, what's up
[14:33] <dednick_> kgunn: i'll take a look
[14:34] <kgunn> dednick_: thank you
[14:39] <kgunn> dandrader: i confirmed, the primary bug to fix is the focus on top (not necessarily the hot-key vol for apps in background)
[14:40] <kgunn> Saviq: ^ fyi
[14:40] <dandrader> kgunn, ok. it's likely gonna take a while for me. focus in mir involves some 13241 classes and interfaces
[14:43] <kgunn> Saviq: should we ask tvoss_ to help dandrader here on the input bug 1233245 ? vs the slowdown ?...i know you asked him to help on slow down
[14:44] <dandrader> kgunn, or I could simply pass the bug to racarr, the author of most of these classes
[14:44] <kgunn> dandrader: ack
[14:45] <dandrader> kgunn, so, do I continue through this maze or pass it to racarr ?
[14:45] <kgunn> dandrader: continuing would be good in order to prep racarr  when he comes on
[15:13] <tsdgeos> Saviq: Cimi: good/bad news
[15:13] <tsdgeos> it also happens on the desktop
[15:13] <tsdgeos> just less often
[15:14] <tsdgeos> but if you go to apps (i have "more suggestions" and then "dash plugins") expand dash plugins
[15:14] <tsdgeos> and keep scrolling up/down
[15:14] <tsdgeos> it'll eventually lock
[15:14] <Cimi> tsdgeos, good
[15:15] <tsdgeos> i guess :D
[15:21] <Saviq> tsdgeos, you're getting somewhere, it's good, I'd say ;)
[15:36] <tsdgeos> Mirv: ping
[15:36] <tsdgeos> Saviq: or you, do you know if we still have that ppa qith qt 5.1 and unity compiled for it?
[15:37] <Saviq> tsdgeos, should be https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta-proper
[15:37] <tsdgeos> let's try that otp while i debug this
[16:00] <om26er> Saviq, is there a way to force apps running inside unity8 to run in -testability ?
[16:01] <Saviq> om26er, initctl set-env QT_LOAD_TESTABILITY=1 should work
[16:01] <Saviq> om26er, since we're running them through upstart now
[16:02] <Saviq> om26er, although that might not be the case for sufraceflinger, only for unity-mir
[16:02] <om26er> Saviq, right, I am going to give that a try. last time I ran tests under Mir apps were not coming to the font
[16:03] <mhr3> for sf you can just "stop unity8" and run it with that env
[16:03] <mhr3> should get propagated then
[16:05] <Saviq> om26er, right ↑
[16:06] <Saviq> om26er, for sf just stop unity8, set the env, start unity8 - the env var will be there for sf apps too
[16:06] <Saviq> MacSlow, you here for some time still?
[16:07] <om26er> Saviq, sure, I'll try to do something in the upstart override so that I just stop unity8;change the upstart override;start unity8
[16:07] <Saviq> otherwise dandrader, could you look at https://code.launchpad.net/~saviq/unity-mir/fix-inputarea/+merge/189647 and https://bugs.launchpad.net/unity8/+bug/1235215
[16:08] <Saviq> dandrader, I meant https://code.launchpad.net/~saviq/unity8/add-notifications-inputarea/+merge/189370
[16:09] <Saviq> dandrader, two bugs: bug #1233411 bug #1235215 bug #1233411 should be fixed
[16:09] <Saviq> that's three ;)
[16:10] <dandrader> Saviq, do you want me just to review the change or to test that this really fixes all those bugs?
[16:10] <Saviq> dandrader, isn't that the same thing? :D
[16:11] <Saviq> dandrader, that is, unless you're EOD'ing soon and/or have other things on your plate
[16:11] <Saviq> mterry, maybe you have some time still in your day and could tackle ↑↑↑↑?
[16:12] <MacSlow> Saviq, what's up?
[16:12] <Saviq> MacSlow, same ↑↑↑
[16:12] <dandrader> Saviq, no, I can stop trying to understand all the mir code related to focus (regarding the volume keys bug) and start reviewing your stuff, np
[16:12] <Saviq> dandrader, not passed on to racarr yet?
[16:12] <tsdgeos> meh
[16:12] <Saviq> tsdgeos, found it?
[16:13] <tsdgeos> ultra fail trying to run the shell with 5.1
[16:13] <tsdgeos> nope
[16:13] <Saviq> ;(
[16:13] <tsdgeos> can't start the phone with 5.1 :-/
[16:13] <Saviq> MacSlow, you're EOD already, so let's let someone from a western-er tz handle it
[16:13] <mterry> Saviq, I can look at those instead of the infographic thing for a bit, sure
[16:14] <tsdgeos> i have a sligth idea of what may be the cause
[16:14] <Saviq> mterry, dandrader, fight!
[16:14] <MacSlow> Saviq, ok... but doesn't all this lead to the need to fix InputFilterArea?!
[16:14] <tsdgeos> will check tomorrow morning
[16:14]  * tsdgeos waves
[16:14] <Saviq> MacSlow, I fixed it
[16:14] <MacSlow> Saviq, that's pure mir-related...
[16:14] <MacSlow> Saviq, ah... cool!
[16:14] <Saviq> MacSlow, nah, lp:unity-mir
[16:14] <MacSlow> Saviq, so it's solved then
[16:14] <Saviq> MacSlow, good news: fixed unity-mir; bad news: seems keyboard is broken for shell under mir, so wifi input is b0rked, flashing now to see
[16:14] <Saviq> MacSlow, yes
[16:15] <dandrader> Saviq, he's no online yet. kgunn asked me to keep looking at it to give racarr some input on the issue, once he comes online. But that's kinda hopeless considering the time I need just to make sense of all those mir  interfaces
[16:15] <MacSlow> Saviq, I can be back in ~2 hours if more hands an needed still
[16:15] <mterry> dandrader, I'll test the snap decision click-through thing?
[16:15] <MacSlow> Saviq, I'm done with the low-impact ui-tweaks for notifications.
[16:16] <mterry> Saviq, you said you had three bugs in your message to dandrader earlier, but two of the numbers were the same
[16:16] <MacSlow> Saviq, I'll be back in two hours an will see what you assigned to me :) deal?
[16:16] <dandrader> mterry, no, I'll do it
[16:17] <mterry> dandrader, OK, let me know if you want any testing help.  I can go back to my infographic problem  :)
[16:17] <Saviq> trying again
[16:17] <Saviq> bug #1233411 bug #1235215 bug #1235383
[16:17] <Saviq> \o/
[16:18] <Saviq> all are related to the two branches
[16:19] <kgunn> dandrader: go ahead and help Saviq on the borked osk
[16:20] <MacSlow> I'll be back in ~2 hours
[16:20] <kgunn> dandrader: just catch up with racarr when he comes on
[16:20] <Saviq> kgunn, borked osk is not yet confirmed
[16:21] <Saviq> kgunn, dandrader gtg, be back in ~1.5h to continue
[16:22] <mhr3> Saviq, scope-isactive wanted me to rename it to scope-needslove :)
[16:22] <kdub> who knows how the screen blanking and unblanking works in surfaceflinger on the nexus 4?
[16:23] <kdub> i'm trying to rule out that powerd (or something else) and mir are both trying to assert control over the display
[16:26] <kgunn> ricmm: rsalveti ^ maybe you guys know something about N4 screen blanking in the surfflinger case ?
[16:26] <kgunn> kdub: are you still able to repro ? (...i cannot)
[16:26] <rsalveti> kdub: powerd has a different path for mir/sf when blanking/unblanking
[16:26] <rsalveti> let me check the code
[16:27] <rsalveti> kdub: in powerd/src/display.c, check for sf_blank
[16:28] <rsalveti> it checks for /home/phablet/.display-mir, if available then it uses dbus instead
[16:28] <kdub> rsalveti, thanks
[16:28] <rsalveti> otherwise it uses the hybris sf_blank/unblank function calls
[16:30] <ricmm> kdub: only unity-mir controls the blanking interface
[16:31] <ricmm> the issue here is more about the GPU being in a low power state
[16:31] <ricmm> so an unblank() call fails
[16:31] <ricmm> powerd has to exit suspend for it to work
[16:34] <kdub> ricmm, so when powerd has exited suspend, the unblank call works?
[16:35] <kdub> i don't know that the gpu is involved though, hwc's blank call on the nexus 4 looks like it just calls fb ioctls
[16:36] <dednick_> Cimi: fixed typo
[16:37] <ricmm> kdub: yes
[16:37] <ricmm> kdub: press the power button
[16:37] <ricmm> you'll see that unity8 comes up
[16:38] <kdub> right
[16:56] <Cimi> weird bug
[16:57] <Cimi> lock screen half on screen
[16:57] <Cimi> on top of everything
[16:57] <Cimi> mterry,
[16:57] <Cimi> well I can debug...
[16:58] <kdub> ricmm, okay, so i see that its some interplay between powerd and mir (just using powerd and my basic fb testing program)
[16:59]  * kdub reads powerd code
[17:00] <mterry> Cimi, hello
[17:00] <mterry> Cimi, half on screen?
[17:01] <Cimi> mterry, I did slide to unlock
[17:01] <Cimi> mterry, but it's on screen
[17:01] <Cimi> mterry, lock screen moved of like 3gu
[17:01] <Cimi> mterry, i can see the app on background
[17:02] <mterry> Cimi, odd...
[17:02] <Cimi> well now it locked again
[17:02] <Cimi> mterry, but yeah, there is an edge case when it gets stuck
[17:03] <Cimi> mterry, not sure it's a flaw somewhere
[17:03] <Cimi> in the states logic
[17:05] <ricmm> kdub: it is, but its basically the suspend request
[17:05] <ricmm> usb cable holds a wakelock that will keep the system up
[17:05] <ricmm> but its still suspending some things
[17:09] <kdub> ricmm, and it does this through sysfs?
[17:11] <Cimi> mterry, I see we have a wifi panel in settings app
[17:11] <Cimi> mterry, time to integrate the last bit?
[17:12] <ricmm> kdub: not entirely sure of what it calls to suspend
[17:12] <mterry> Cimi, not for 13.10
[17:29] <Cimi> mhr3, you in the office tomo?
[17:29] <mhr3> Cimi, yep
[17:32] <Cimi> mhr3, so tomo we do the renderers
[17:52] <kdub> rsalveti, mfisch would either of you be the person to ask about how powerd on mako works?
[17:56] <Saviq> mhr3, it's next on my list tomorrow morning
[18:05] <MacSlow> Saviq, so what of the IFA-related bugs still need helping/testing hands?
[18:05] <Saviq> dandrader,  ↑?
[18:05] <dandrader> Saviq, compiling unity8 on my define at the moment
[18:05] <Saviq> dandrader, MacSlow, I can built unity-mir and unity8 packages for testing if you need it
[18:05] <Saviq> dandrader, k
[18:06] <Saviq> MacSlow, if you also want to test, I can have a set of packages in maybe 30 mins
[18:06] <dandrader> Saviq, there's also a need to build unity-mir for your bug fix?
[18:06] <Saviq> dandrader, yes, on Mir
[18:06] <Saviq> dandrader, the two linked branches work in concert
[18:07] <MacSlow> hm... I can build unity8 myself... only unity-mir I don't know anything about... not sure how much work it is to get into it... so packages for that would be good to have
[18:07] <dandrader> Saviq, ah, found it now
[18:09] <Saviq> MacSlow, coming right up
[18:11] <Saviq> dandrader, ugh, I think I didn't push to unity8....
[18:11] <dandrader> Saviq, so there's something missing in https://code.launchpad.net/~saviq/unity8/add-notifications-inputarea/+merge/189370 still?
[18:12] <Saviq> dandrader, on the contrary
[18:12] <Saviq> dandrader, there's one unnecessary commit
[18:12] <Saviq> dandrader, just pushed
[18:12] <dandrader> Saviq, ah, I see
[18:12] <Saviq> dandrader, sorry about that
[18:12] <dandrader> Saviq, so your unity-mir fix made that unity8 commit unnecessary
[18:12] <Saviq> dandrader, yes exactly
[18:13] <Saviq> dandrader, and it's now the correct solution in that branch - just 4 lines diff now
[18:13] <Saviq> well, ok, 6
[18:13] <MacSlow> Saviq, dandrader: IFA is now (with the unity-mir fix) only needed/required in Notifications.qml itself?!
[18:13] <Saviq> MacSlow, only in Shell.qml
[18:14] <dandrader> MacSlow, "IFA"?
[18:14] <Saviq> dandrader, InputFilterArea
[18:14] <MacSlow> dandrader,  :)
[18:14] <Saviq> MacSlow, there's only one IFA that covers all of the notifications at once
[18:14] <dandrader> acronyms...
[18:14] <MacSlow> Saviq, I know... but I remember from Friday it was the other way around... anyways.
[18:14] <MacSlow> dandrader, *sigh* yeah :)
[18:14] <Saviq> MacSlow, yeah, but that was because of the unity-mir problem
[18:15] <Saviq> dandrader, if you're anal, s/blockInput/enabled/ would probably be called for ;)
[18:15] <Saviq> dandrader, let me know if you are ;D
[18:16] <Saviq> dandrader, or maybe not, it's compatible with both SurfaceFlinger and Mir this way
[18:16] <Saviq> with enabled: it might not work correctly with SF
[18:23] <dandrader> Saviq, yes, that InputFilter API doesn't really make sense in Mir world. It has been kept just for API compatibility with SF
[18:23] <Saviq> dandrader, yeah
[18:31] <MacSlow> Saviq, looks like building your unity-mir branch on the device is not much of an issue... so I don't think I'll need the packages...
[18:31] <Saviq> MacSlow, sure it isn't
[18:31] <MacSlow> Saviq, just pulling in the build-dependencies...
[18:31] <Saviq> MacSlow, yeah, mk-build-dep; bzr bd is everything you need
[18:32] <MacSlow> Saviq, so I've your unity8 branch and your unity-mir one...
[18:33] <MacSlow> Saviq, so unity-mir is actually two shared-library objects...
[18:33] <MacSlow> which need to go where exactly?
[18:33] <Saviq> MacSlow, well, to be correct you should merge them on top of trunks - and that's when unity-mir needs upstart trunk
[18:33] <Saviq> MacSlow, into packages ;)
[18:33] <Saviq> MacSlow, or well, sudo make install
[18:33] <Saviq> MacSlow, but packages are good
[18:34] <MacSlow> Saviq, ok... I'll wait for those then :)
[18:34] <Saviq> MacSlow, bzr bd
[18:34] <Saviq> MacSlow, but yeah, if you want - I'll have the packages ready soon
[18:34] <Saviq> 10-15 mins hopefully
[18:34] <MacSlow> ok
[18:35] <Saviq> it still takes quite long to build, even with ccache
[18:35]  * Saviq cries for cross builds...
[18:44] <dandrader> Saviq, at Nokia we used scratchbox, which is a qemu chroot + native cross-compiler. Worked well.
[18:48] <kgunn> Saviq: so, https://code.launchpad.net/~saviq/unity-mir/fix-inputarea actually fixes the "answer phone call"
[18:49] <kgunn> Saviq: making sure i'm not missing something the mir guys need to be focusing on helping with
[19:06] <MacSlow> Saviq, unity-mir/fix-inputarea is installed on the device... now just building unity8/add-notification-inputarea
[19:23] <dandrader> MacSlow, is there a way to force the appearance of a notification?
[19:23] <MacSlow> dandrader, yes...
[19:24] <dandrader> MacSlow, or to fake an incoming phone call
[19:24] <dandrader> wanna test that bug fix from Saviq
[19:24] <MacSlow> dandrader, use the examples from lp:unity-notifications (exampels directory) to trigger any type you like
[19:24] <MacSlow> dandrader, there's sd-example-incoming-call.py to do just that
[19:25] <dandrader> MacSlow, great. thanks
[19:26] <MacSlow> dandrader, you testing on a Nexus4 or GalaxyNexus?
[19:27] <dandrader> MacSlow,  galaxy
[19:29] <dandrader> MacSlow,  "ImportError: No module named pynotify" <- doesn't that come from python-notify2? Just installed it but the errror continues
[19:30] <Saviq> dandrader, python-notify
[19:30] <Saviq> dandrader, not 2
[19:30] <MacSlow> dandrader, yeah ^
[19:30] <Saviq> dandrader, for the user-auth / wifi you'll need python-gi, too
[19:31] <MacSlow> dandrader, Saviq: I actually should unify this at some point
[19:31] <MacSlow> dandrader, Saviq: ... and also update the C-versions of the examples
[19:31] <Saviq> MacSlow, indeed - I think the tester from autopilot tests is probably a good start for that
[19:32] <MacSlow> hm... I'm not sure I'm really using mir on the device... despite having ~/.display-mir and having rebooted the device...
[19:32] <Saviq> dandrader, re: unity-mir
[19:33] <Saviq> dandrader, setSurface changes the surface, setEnabled does not
[19:33] <Saviq> dandrader, for changing surface, we need to uninstall it from the old one, install on the new one
[19:33] <Saviq> dandrader, when enabling, it remains on the same surface - no need to reinstall
[19:33] <elopio> hello!
[19:33] <kgunn> MacSlow: did you ps faux | grep surface ?
[19:33] <elopio> unity is not starting here, and I'm getting: Settings schema 'org.compiz.unityshell' does not contain a key named 'alt-tab-right'
[19:33] <elopio> any clue?
[19:34] <MacSlow> kgunn, now I did... no SF
[19:34] <kgunn> MacSlow: :) phew
[19:34] <MacSlow> kgunn, hm... nice then... seems there was some speed-improvement then
[19:35] <Saviq> MacSlow, yeah, it does feel more fluid, doesn't it
[19:36] <MacSlow> Saviq, although the scrolling of the elements in the weather-app is still a bit jerky
[19:36] <Saviq> MacSlow, probably not async
[19:36] <Saviq> for loading images
[19:36] <Saviq> MacSlow, UShape has an effect like that, too, we suspect
[19:37] <MacSlow> I see
[19:39] <dandrader> Saviq, ah, ok. because it takes a pointer to the InputArea class, not the geometry directly
[19:39] <Saviq> dandrader, yeah, well, we probably shouldn't install it at all (as it's installed already)
[19:40] <Saviq> dandrader, but maybe that's the only way to get it updated?
[19:40] <Saviq> dandrader, I wouldn't like to touch it if we're not positive it's needed :)
[19:40] <dandrader> Saviq, it's q QSet so it won't store two identical items
[19:40] <Saviq> dandrader, yeah, so we shouldn't even need to install it again
[19:40] <MacSlow> Saviq, dandrader, kgunn: ok... seems to work.
[19:40] <Saviq> \o/
[19:41] <dandrader> Saviq, unless it was never installed before. e.g.: the first time you enable the thing
[19:41] <Saviq> MacSlow, did you get keyboard working on Mir, too? in the wifi case?
[19:41] <MacSlow> I can no longer reproduce the bugs described here https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1235215
[19:41] <Saviq> dandrader, true
[19:41] <Saviq> MacSlow, i.e. can you connect to a new WiFi when focused on an app?
[19:41] <MacSlow> Saviq, bug-#?
[19:42] <Saviq> MacSlow, no bug there, I didn't yet confirm it's an issue
[19:42] <MacSlow> ah ok... one second...
[19:42] <Saviq> MacSlow, just trigger one of the extended snaps with wifi / user auth
[19:42] <Saviq> MacSlow, and see if keyboard behaves correctly
[19:42] <kgunn> MacSlow: dandrader Saviq ...this is good news on the phone call at least
[19:42] <Saviq> kgunn, yeah, that usecase will work
[19:42] <Saviq> kgunn, only possible problem is osk now
[19:43] <kgunn> Saviq: ok, still worth it to update the landing sheet for unity8 & unity-mir i would think...
[19:45] <Saviq> kgunn, yup
[19:45] <kgunn> Saviq: i put you on a invite just now...made  you optional...but since your up & on...would be grateful if you joined (no pressure if ur about to drop)
[19:46] <Saviq> kgunn, yeah, not in a state to join a HO now, running around the house here
[19:46] <kgunn> no worries
[19:48] <MacSlow> Saviq, kgunn, dandrader: the osk doesn't work (get any input) yet
[19:49] <MacSlow> Saviq, kgunn, dandrader: the osk comes up as I tap a text-field of an extended snap-decision, but entering text doesn't work
[19:50] <Saviq> MacSlow, yeah, input goes to the app in the back?
[19:50] <kgunn> MacSlow: help me...is that "new" with this fix for answering the incoming call
[19:50] <Saviq> kgunn, no, it's the same for search in dash
[19:50] <kgunn> ack
[19:50] <Saviq> kgunn, osk got broken somehow
[19:50] <MacSlow> kgunn, I don't know... I didn't test that before
[19:50] <Saviq> kgunn, will try and pinpoint the image where this happens
[19:50] <Saviq> s/happens/happened/
[19:51] <Saviq> MacSlow, try in dialer, for example - you'll probably get numbers typed into the dialer instead of text into the shell
[19:51] <MacSlow> Saviq, correct... taps on the osk "fall through"
[19:52] <Saviq> MacSlow, yup, /me tries on a fresh #84
[19:53] <Saviq> :/
[19:53] <Saviq> seems to work there
[19:53] <MacSlow> damn
[19:54] <Saviq> so the InputArea thing must've did something
[19:54] <Saviq> but then
[19:54] <Saviq> maybe it got fixed in the mean time
[19:54]  * Saviq will install the new packages to see
[19:54] <dandrader> yeah, I cannot type on the OSK.
[19:55] <dandrader> seems like touches go through to the surface below the OSK
[19:56] <Saviq> dandrader, but you saw that before you tried the input fixes, right?
[19:56] <Saviq> dandrader, that's what you reported during standup today?
[19:56] <MacSlow> Saviq, does the osk also use an InputFilterArea?
[19:56] <Saviq> MacSlow, it shouldn't be able to
[19:56] <Saviq> MacSlow, but then it's a special surface / client, so maybe
[19:56] <dandrader> Saviq, it's been quite a while since I last played with unity8+OSK so I really cannot tell at the moment
[19:56] <Saviq> dandrader, you said something on the standup today
[19:57] <Saviq> dandrader, that you couldn't type into search in dash
[19:57] <MacSlow> Saviq, just being naive here and guessing it might need a similar fix like the notifications did
[19:57] <Saviq> MacSlow, well, it's a regression here - it was working before for sure
[19:57] <Saviq> MacSlow, so I'll be checking if we caused it
[19:57] <MacSlow> Saviq, ok... if you know that for certain... then it sounds like a regression
[19:59] <dandrader> Saviq, yeah. last time I tried I couldn't event make it show up. unlike now
[19:59] <Saviq> dandrader, k
[19:59]  * Saviq digs
[20:00] <Saviq> MacSlow, you're off the hook, thanks for testing o/
[20:01] <MacSlow> Saviq, ok... I'll join the "fun" tomorrow again... good luck!
[20:01] <kgunn> MacSlow: thanks for staying and "playing"
[20:03] <dandrader> Saviq, I'm also looking at OSK-related code now in unity-mir to understand how things work there (and therefore what could have went wrong)
[20:03] <dandrader> "FYI"
[20:03] <Saviq> dandrader, thanks
[20:03] <Saviq> dandrader, I'll know in a few whether we actually broke it or not
[20:18] <kgunn> Saviq: you said "new unity-mir" causes the issue...but kind of implied...not the fix from https://code.launchpad.net/~saviq/unity-mir/fix-inputarea/+merge/189647
[20:18] <Saviq> dandrader, yeah, unity-mir trunk + my patch is introducing that, looking whether my patch has to do with it
[20:18] <Saviq> kgunn, both, for now
[20:18] <kgunn> ack
[20:18] <Saviq> kgunn, will now be rolling back a commit at a time
[20:18] <kgunn> Saviq: fun :-/
[20:19] <kgunn> thank goodness there shouldn't be many
[20:19] <Saviq> I wonder who let greyback go to an event three days before the deadline ;D
[20:19] <Saviq> kgunn, yeah, a handful
[20:19] <racarr> as for the shell receiving focus. I think I have a solid strategy, so we are looking at 30 minutes to get everything up to date and unity-mir build env
[20:19] <racarr> 1 hour to fix it, 1 hour of churn and nonsense :p
[20:20] <Saviq> kgunn, a handfull == 1...
[20:20] <Saviq> granted, one that has focus stuff
[20:20] <kgunn> :) i know i just looked...lol
[20:24] <Saviq> kgunn, "add workaround for handling of non-application sessions (like QtWebProcess and maliit)."
[20:24] <Saviq> kgunn, sthg smells funny
[20:24] <kgunn> i saw that too....
[20:24] <kgunn> complete with FIME
[20:24] <kgunn> or FIXME even
[20:29] <Saviq> kgunn, if I confirm that's the issue, what's the strategy? revert in unity-mir?
[20:30] <kgunn> Saviq: looking at bug...i think so
[20:30] <kgunn> Saviq: so risk is...you'll end up with loads of music app instances....which sucks
[20:30] <kgunn> but not as bad as not being able to answer the phone
[20:30] <Saviq> kgunn, or connect to wifi
[20:31] <Saviq> moment of truth
[20:32] <Saviq> kgunn, trunk good
[20:33]  * Saviq builds with fix again
[20:34] <Saviq> kgunn, yeah, fix → broken keyboard
[20:34] <Saviq> crap
[20:34]  * Saviq drags maliit down
[20:35] <Saviq> racarr, confirmed, the fix in unity-mir causes the issue with maliit
[20:36] <Saviq> ah, /me sees something
[20:36] <racarr> I am looking at the diff
[20:38] <Saviq> racarr, InputArea::setMirInputArea (this=0x518234e0, x=0.000000, y=740.000000, width=768.000000, height=540.000000)
[20:38] <Saviq> racarr, that should never happen, since x, y are in local coordinates
[20:39] <Saviq> racarr, must've been a workaround for the mapping issue
[20:39] <Saviq> racarr, must be something special in unity-mir
[20:40] <Saviq> racarr, yeah, OSKController.qml
[20:42]  * Saviq will find what's up
[20:43] <Saviq> ah
[20:43] <Saviq> nasty greyback
[20:48] <Saviq> racarr, kgunn, I can see the issue, not sure of a solution yet, though
[20:48] <kgunn> progress....thanks for staying at it
[20:48] <Saviq> racarr, do you know if OSK's surface is fullscreen?
[20:49] <kgunn> dandrader: ^ might know
[20:49] <racarr> Saviq: I dont think so but wouldnt be impossib;le
[20:51] <dandrader> Saviq, kgunn  In MeeGo it was fullscreen. don't know it if has changed
[20:51] <racarr> maybe it is then
[20:51] <racarr> I just thought it wasn't because I hadnt heart about making it full screen
[20:52] <Saviq> QRect(0,1480 768x540) QRect(0,740 768x540)
[20:53] <Saviq> the first one is the InputArea's rect *with* fix (incorrect)
[20:53] <Saviq> the latter is *without* fix
[20:53] <Saviq> the latter one is off-screen - and what Gerry was reffering to in his FIXME
[20:54] <Saviq> that the rectangle is incorrect somehow
[20:55] <Saviq> but I think I see what the issue is
[20:56] <Saviq> geometryChanged is in *parent's* coords
[20:56] <Saviq> whereas mapToScene is in *item's* coords
[20:58] <Saviq> racarr, kgunn ↑↑
[20:58] <Saviq> so we need to mapToScene from the parent, and all should be golden
[20:58] <kgunn> sweet...
[20:59] <kgunn> dandrader: can you hang around for one more mp retest ?
[20:59] <dandrader> kgunn, yep, which one?
[21:00] <Saviq> dandrader, same unity-mir fix, but a proper one
[21:00] <Saviq> keyboard: GOOD
[21:01] <dandrader> Saviq, did you push it?
[21:01] <Saviq> dandrader, testing
[21:03] <kgunn> dandrader: he's gonna say...phone call all good...and then push
[21:03] <Saviq> :S
[21:03] <kgunn> or not
[21:03]  * Saviq no get it
[21:07]  * kgunn wonders if Saviq noticed greyback got on
[21:07] <racarr> JUMP HIM
[21:07]  * greyback hides
[21:07] <racarr> IVE GOT AN ARM
[21:07] <racarr> HELP ME PIN HIM DOWN
[21:07]  * Saviq just thinks there's a reason for the FIXME
[21:08] <racarr> Good evening Gerry :p
[21:08] <Saviq> he's probably drunk anyway
[21:08] <racarr> arent we all it's 2 pm
[21:08] <racarr> err
[21:09] <racarr> :p
[21:09] <kgunn> drunk on life racarr
[21:10] <racarr> the sweet nectar of insanity.
[21:10] <racarr> * taps foot waiting on phone to install build deps*
 he's probably drunk anyway
[21:10] <greyback> I don't know whether that hurts more than amuses me
[21:10] <Saviq> see, he can't type
[21:10] <Saviq> greyback, why would it hurt?
[21:11] <greyback> You of all people throwing stereotypes around!
[21:11] <Saviq> AAARGH
[21:11] <Saviq> stupid /me
[21:11] <greyback> you ahould be ashamed! :D
[21:11] <Saviq> if I'd have updated unity8 to the fixed version, that'd probably make more sense
[21:11] <Saviq> greyback, how is it a stereotype?
[21:11] <Saviq> greyback, about Gerrys?
[21:12] <Saviq> greyback, I just know you - and good for you, having fun getting drunk there with mzanetti
[21:13] <greyback> Saviq: nah he's off on the formal Qt dinner. Instead zsombi and Christian and I had a few drinks at the Oktoberfest
[21:13] <Saviq> greyback, good for you anyway
[21:14] <greyback> Saviq: wish you were here :X
[21:14] <Saviq> YES
[21:14] <Saviq> lol
[21:14] <Saviq> dandrader, pushing
[21:15] <Saviq> kgunn, racarr, dandrader, got it
[21:15] <Saviq> too many realms
[21:15] <dandrader> Saviq, got it. try it out now
[21:15] <Saviq> greyback, remember that FIXME https://code.launchpad.net/~saviq/unity-mir/fix-inputarea/+merge/189647
[21:15] <dandrader> s/try/trying
[21:15] <Saviq> dandrader, I did already ;)
[21:16] <Saviq> greyback, I expect you found that the mapping gives you wrong output exactly how I made it wrong
[21:16] <Saviq> greyback, there's three coords in play there - scene's, item's and *parent's*
[21:17] <dandrader> ok, than EOD
[21:17] <greyback> Saviq: not forgotten, but it's been a busy day, I had no time ti sit to do anything
[21:17] <Saviq> greyback, no no
[21:17] <Saviq> greyback, geometryChanged is in *parent's* coords, but mapToScene takes item's coords, so we need to mapToScene on the parent, not on the item
[21:18] <greyback> Saviq: sounds logical
[21:19] <Saviq> greyback, yeah, but the default thing you do is this->mapToScene() (or at least I do)
[21:19] <greyback> Saviq: yep, was my plan
[21:19] <Saviq> and it was working for some (where your item was at parent's 0,0)
[21:19] <Saviq> but not for others
[21:19] <Saviq> so yeah, should be good now, and worky
[21:20] <Saviq> greyback, you're dismissed
[21:20] <greyback> Saviq: aye aye captain
[21:20]  * Saviq is a sucker for not being there
[21:21] <kgunn> you had your chance :)
[21:21] <kgunn> ...and we'd be totally screwed right now
[21:23] <kgunn> so...does this end up being a search and replace on 'this->' to parent->
[21:23] <Saviq> kgunn, no searching
[21:23] <Saviq> kgunn, just one place
[21:23] <Saviq> kgunn, where I was dumb enough to not think about it properly
[21:25] <thomi> Should unity8 be consuming 20% of CPU and 35% of memory on the mako all the time?
[21:25] <thomi> I'm guessing not...
[21:27] <Saviq> thomi, what version?
[21:27] <Saviq> thomi, there was a fixed release over the weekend
[21:28] <Saviq> thomi, for CPU at leat
[21:28] <Saviq> least
[21:29] <Saviq> thomi, actually, it wasn't released yet
[21:29] <Saviq> scratch that
[21:30] <Saviq> thomi, 7.82+13.10.20131005-0ubuntu1 should not be hogging your CPU
[21:30] <Saviq> or higher, of course
[21:30]  * thomi checks
[21:31] <thomi> I have 7.82+13.10.20131007-0ubuntu1
[21:31] <thomi> Saviq: it's more memory than CPU
[21:31] <Saviq> thomi, leaky leaky - Mir or surfaceflinger?
[21:31] <thomi> mir
[21:32] <Saviq> thomi, could be https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1235190
[21:32] <Saviq> although there's a bunch of different issues like that
[21:32] <Saviq> that we need to flesh out
[21:33] <thomi> Saviq: will add my info to that bug, thanks
[21:34] <kgunn> thomi: i think there's an upstart bug wrt leaking that is worse on mir seemingly...but also shows up on sf
[21:34] <kgunn> both eventually leak to death
[21:35] <Saviq> yeah, that too
[21:39] <Saviq> oups, I didn't think Daniel would EOD after /me tested :D
[21:39] <Saviq> kgunn, care to test http://people.canonical.com/~msawicz/inputarea/ ?
[21:39] <Saviq> kgunn, actually let me limit the amount of packages there
[21:40] <Saviq> a feck it, it's working after all
[21:41] <Saviq> ah and Gerry happroved
[21:43] <kgunn> even better
[21:43] <kgunn> i'll update the ask sheet
[21:44] <kgunn> oh...even too late for that
[21:44] <Saviq> kgunn, still, if you take the packages from the above url, install them and make sure the two usecases (receive / decline call and wifi password) work, that'd be grand
[21:45] <kgunn> Saviq: i would....but i actually don't have a gsm sim
[21:45] <Saviq> kgunn, you can use examples from lp:unity-notifications
[21:45] <kgunn> ah
[21:46] <Saviq> kgunn, same thing
[21:46] <Saviq> olli, fixed notification input, my fault for being dumb
[21:46] <Saviq> olli, are landing now
[21:51] <thomi> kgunn: I wasn't using upstart....
[21:54] <kgunn> damn you thomi
[21:58] <kgunn> Saviq: how to on the notification examples ?....just adb push the *.py and run from shell command line on device ?
[21:59] <Saviq> kgunn, yeah, you need to install python-notify and python-gi on the device, though
[21:59] <kgunn> cool
[22:00] <Saviq> kgunn, also, it's possibly best if you just bzr branch lp:unity-notifications on the device
[22:00] <Saviq> kgunn, faster, and you'll get the images and such
[22:00] <kgunn> ok
[22:00] <kgunn> Saviq: do i have to be sudo -u phablet -i for that ?
[22:00] <Saviq> kgunn, yes
[22:05] <racarr> testing my keyboard focus fix in t minus 1 :D
[22:05] <Saviq> racarr, let me know if I can help with that
[22:05] <kgunn> Saviq: ok...incoming call example worked
[22:06] <Saviq> kgunn, over app, too?
[22:06] <kgunn> osk using msg app works
[22:06] <kgunn> will try incoming call over app now
[22:07] <kgunn> Saviq: seems to work (work == i get a notification, i select accept, it dismisses and returns to app)
[22:07] <racarr> Saviq: thanks...it may be done...lets seee
[22:10] <racarr> ugh getting fail to start
[22:10] <racarr> I only rebuilt unity mir against things from trunk though...
[22:10] <thomi> kgunn: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1235190/comments/16
[22:12] <kgunn> thomi: kdub and i just chatting ...he's on the hunt....we're hoping its a clocking issue at the device level possibly
[22:12] <racarr> ok starting but not working yet
[22:13] <kgunn> racarr: worked for me...but i used his deb's which had a bunch of upstart stuff too
[22:13] <racarr> Saviq: how can I get things in to the unity8 environment?
[22:13] <racarr> kgunn: I am talking about
[22:13] <racarr> the branch I am working ont o fix the volume keys
[22:13] <kgunn> oh my bad racarr ...i'll slink away
[22:13] <thomi> kgunn: would that explain the very high memory usage?
[22:14] <Saviq> racarr, stop unity8; initctl set-env FOO=bar; start unity8
[22:14] <kgunn> thomi: no, high mem use could very well be that we don't have bypass enabled
[22:14] <kgunn> (so for every set of frame buffers....x2)
[22:14] <kgunn> (with high res displays...this obviously adds up)
[22:15] <kgunn> thomi: correction...you should get x2 once
[22:15] <kgunn> but still...its not cheap
[22:16] <thomi> hmmmm
[22:17] <thomi> how much memory does the mako have?
[22:17] <thomi> unity was using 35% of that... which seems waaaaay too high - even with a potential bypass issue
[22:18] <racarr> Saviq: ok so
[22:18] <racarr> mir now believes it is sending the volume up and down keys to the shell surface and it gets focus properly
[22:18] <racarr> but stll nothing when I press the volume keys
[22:18] <racarr> are we confident the rest is wired up?
[22:19] <racarr> If so it must be something
[22:19] <racarr> in papi mirserver
[22:19] <kgunn> thomi: you running top ?
[22:20] <thomi> kgunn: I was
[22:21] <kgunn> thomi: i would agree with you
[22:21] <kgunn> 30% is a lot
[22:21] <kgunn> thomi: so ...am running here...
[22:21] <kgunn> just noticed, that 30% seems transient
[22:21] <racarr> Saviq: w\hat I mean is I am getting key published and finished received events
[22:21] <racarr> which means its going all the way out to the client in this case the shell surface
[22:21] <kgunn> thomi: i specificially see it when the launcher is revealed
[22:21] <racarr> and the input reader at least is reading it off the socket and saying cool
[22:22] <thomi> hmmm, it was like that for at least 10 minutes for me
[22:22] <kgunn> thomi: oh, scratch that looking at wrong column
[22:26] <kgunn> thomi: what apps do you have open
[22:26] <kgunn> thomi: and do you have a crash file ?
[22:27] <kgunn> bbiab
[22:27] <thomi> kgunn: no apps open, and there's a _usr_lib_arm-linux-gnueabihf_indicator-network_indicator-network-service.32011.crash from about the right time
[22:29] <Saviq> racarr, yeah, it's wired up
[22:30] <Saviq> racarr, you can add:
[22:30] <Saviq>     Keys.onPressed: console.log(event)
[22:30] <Saviq>     Keys.onReleased: console.log(event)
[22:31] <Saviq> racarr, somewhere in the shell
[22:31] <Saviq> racarr, to see if it gets there
[22:31] <Saviq> racarr, lines 171-172 are where the volume keys are hooked up
[22:32] <Saviq> racarr, thing is, we've had problems with *any* keys getting to apps / shell from the event system
[22:32] <Saviq> racarr, OSK works, 'cause it works directly between toolkit and OSK
[22:33] <Saviq> racarr, but autopilot typing through /dev/uinput didn't work (well, and then it started working for me after some sessions)
[22:40] <racarr> Saviq: hmm ok. thanks
[22:41] <racarr> I heard there were some permission issues
[22:41] <racarr> in the past
[22:41] <racarr> but those have been fixed
[22:41] <Saviq> racarr, yup
[22:51] <racarr> Saviq: ok I am getting QQuickKeyEvents
[22:51] <racarr> maybe the mapping isn't correct
[22:51] <racarr> is there some like
[22:51] <racarr> printEventVerbosely
[22:51] <racarr> function
[22:54] <Saviq> racarr, no, you'll have to print the id http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-keyevent.html#accepted-prop
[22:54] <Saviq> racarr, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-keyevent.html#key-prop I mean
[22:55] <Saviq> racarr, and http://qt-project.org/doc/qt-5.0/qtcore/qt.html#Key-enum for a mapping
[22:55] <Saviq> fginther, http://10.97.0.26:8080/job/autopilot-testrunner-otto-saucy/927/console stuck?
[22:57] <Saviq> racarr, how difficult would it be, as a first step, to let key events "fall through" apps to the shell if they don't handle it?
[22:58] <Saviq> fginther, http://10.97.0.26:8080/job/autopilot-testrunner-otto-saucy/928/console suggests being stuck, too
[22:58] <Saviq> unless recording test results takes really long
[22:58] <racarr> Saviq: The problem is the shell isn't using the input filter
[22:59] <racarr> if the shell could use the input filter, then that would be the behavior
[22:59] <racarr> but how can we get
[22:59] <racarr> handle/not handle out of Qt?
[22:59] <Saviq> racarr, .accepted
[22:59] <racarr> hmm interesting
[23:00] <racarr> ill investigate with greyback soon
[23:00] <Saviq> racarr, anything that responds to a key event should set its accepted prop to true, so that it doesn't get further up the focus chain
[23:00] <Saviq> racarr, we could just "extend" that focus chain up to the shell for the generic case
[23:00] <Saviq> racarr, obviously input filter is needed for global hot keys
[23:00] <racarr> mm
[23:01] <Saviq> racarr, but that's not something we need to look at right now
[23:01] <Saviq> and it is something we need to talk to in a lot more detail
[23:03] <Saviq> ricmm, huh? what is ApplicationManager.volumeUp/DownKeyPressed?
[23:03] <racarr> Saviq: ok I am not getting qt::key_unknown but am also not getting anything I can find in the mapping
[23:04] <Saviq> racarr, right, so looks like the mapping fails in the QPA plugin?
[23:05] <racarr> Saviq: Yes. seems so....
[23:07] <racarr> wheeeeeeee...:p
[23:08] <racarr> ok
[23:08] <racarr> its not impossible it just needs to be added to an enum
[23:08] <racarr> digging deeper
[23:11] <ricmm> oh
[23:11] <ricmm> look at you guys
[23:12] <ricmm> well first of all we'd like to filter key events in the shell as the applications dont really need to read them directly
[23:12] <ricmm> second, the issue is that the android stack doesnt see the shell as a focused window for *keyboard* events
[23:13] <ricmm> motion ones are dispatched through another path and the focused window is irrelevant in that sense, as they deal with the touched window instead
[23:13] <ricmm> so input stack drops these events, mir-side
[23:13] <racarr> ok building a new qtubuntu
[23:13] <racarr> ricmm: It does see it as a focused window now :)
[23:13] <ricmm> and it still doesnt work?
[23:13] <racarr> well in the branch
[23:13] <racarr> I am working on
[23:13] <racarr> yes
[23:13] <racarr> key mapping seems to have an issue as well
[23:14] <racarr> it may just be the volume keysymd oesnt correspont to a unicode character
[23:14] <ricmm> wheres the branch?
[23:14] <racarr> so it has to go in that special array of keysyms
[23:14] <ricmm> scan codes are 114 and 115, they match linux/input.h types
[23:14] <racarr> ricmm: ~robertcarr/unity-mir/default-input-focus
[23:14] <racarr> I know it's not getting mapped to a qt key code though
[23:15] <racarr> or at least not the correct one lol
[23:15] <racarr> im pretty hopeful this is going to work right here :D
[23:16] <racarr> yep :)
[23:16] <ricmm> pro
[23:16] <racarr> preparing mps for qtubuntu and unity-mir now
[23:20] <racarr> Saviq: kgunn: Linked branches to https://bugs.launchpad.net/mir/+bug/1233245
[23:20] <kdub> thomi, can you reproduce that bug 'mir got slow' at the moment?
[23:20] <racarr> Saviq: of course this only solves
[23:20] <kdub> i have a magical command to try
[23:20] <racarr> the shell now receives input focus when nothing else has it
[23:20] <racarr> but still isn't getting volume events when an app has focus
[23:21] <racarr> we can implement that using the input filter paired with input injector approach
[23:21] <racarr> at a later date
[23:21] <racarr> perhaps?
[23:21] <Saviq> racarr, yeah, we need to think it through
[23:22] <racarr> if ".accepted" really works as seems
[23:22] <racarr> we can hack the heck out of the QPA and
[23:22] <racarr> inject stuff straight from the input filter
[23:22] <racarr> in to Qt
[23:22] <racarr> and short circuit all this nonsense
[23:22] <racarr> with what would be expected
[23:22] <racarr> i.e. the shell gets the event can consume it or pass it on
[23:22] <racarr> application gets a chance at the event
[23:22] <racarr> can consume it or pass it on
[23:22] <racarr> then the shell gets it one more time
[23:23] <Saviq> racarr, yeah, we'd need to differentiate between the "times" somehow
[23:23] <ricmm> racarr: this default_input_target only refers to the key event types?
[23:23] <ricmm> or does this prevent motion events from being dispatched to the session as well
[23:23] <racarr> yes. I thik it says like default_keyboard_input_target in the
[23:23] <racarr> class right?
[23:23] <racarr> ok so the problem is
[23:24] <racarr> in mir focus is tracked session->surface
[23:24] <Saviq> racarr, i.e. the first time would have to go through a global-hotkey-handler or something, the second it'd have to be injected below it
[23:24] <racarr> so we can't really give focus to the shell surface
[23:24] <racarr> without a session
[23:24] <racarr> so what this is doing, is whenever focus would otherwise be cleared
[23:24] <racarr> which happens when the shell is focused (because greyback calls, set_focus_to(NULL) on unfocusedCurrentApplication out of unity)
[23:24] <ricmm> I understand that, my question is if giving input focus to shell would prevent the application from getting motion events
[23:24] <racarr> it sets the keyboard
[23:24] <racarr> focus only
[23:24] <ricmm> ok then never give keyboard focus to the application
[23:25] <racarr> no it's fine
[23:25] <Saviq> ricmm, FWIW, IMO we should only filter the global hot key events before the app gets it, nothing else
[23:25] <racarr> its only giving it to the shell
[23:25] <racarr> when no application
[23:25] <racarr> has focus
[23:25] <ricmm> you are missing my point
[23:25] <racarr> ok
[23:25] <ricmm> if you never give keyboard focus to applications, but always to shell, you wont miss key events when in application
[23:25] <racarr> autopilot
[23:25] <Saviq> ricmm, then you need to give them focus *in* shell
[23:25] <racarr> uses real key events
[23:25] <racarr> to apps
[23:25] <ricmm> I prefer to have applications *not* get key events rather than not being able to use the volume keys whiel in application
[23:25] <ricmm> ah thats true
[23:26] <ricmm> then whats the solution for that case?
[23:26] <racarr> ricmm: My plan for taking them out of the application is to use the input injecter being developed for the HUD
[23:26] <racarr> bit
[23:26] <ricmm> injecting events to the shell directly from qtuubntu sounds bad
[23:26] <racarr> plus an event filter, and have in unity mir
[23:27] <racarr> like
[23:27] <racarr> "KeybindingEventFilter"
[23:27] <racarr> which supports like bind_key(int key_code, Surface target)
[23:27] <Saviq> ricmm, input will go like so:
[23:27] <racarr> and it looks for the keycode, and if it sees it
[23:27] <racarr> handles the event by injecting it to the surface
[23:27] <racarr> through the normal input injection mechanism
[23:27] <racarr> injecting it
[23:27] <racarr> to the shell surface in this case
[23:27] <Saviq> device → shell(hotkeys) → (app →) shell(standard)
[23:27] <racarr> instead of allowing it to propagate to the focused
[23:28] <racarr> surface
[23:28] <ricmm> as long as theres an injection mechanism that uses the normal event delivery thats fine
[23:28] <racarr> yes
[23:28] <racarr> that is what should hopefully land soon for the hud
[23:28] <ricmm> how soon
[23:28] <ricmm> considering tomorrow is tuesday
[23:28] <ricmm> :D
[23:28] <racarr> tomorrow?
[23:28] <ricmm> ok
[23:28] <racarr> It didn't get a real round of reviews this morning
[23:28] <racarr> because instead people just asked if it was needed -.-
[23:28] <racarr> but im pretty sure it is
[23:29] <racarr> https://code.launchpad.net/~robertcarr/mir/input-injecter-api/+merge/188904
[23:29] <ricmm> jesus 1200 lines
[23:29] <ricmm> ok so considering freeze is in 72 hours or less
[23:29] <racarr> ricmm: It's mostly
[23:29] <ricmm> what about just implementing a filter and delivering the event as a qt signal to the qml layer
[23:30] <racarr> if you look at android_input_lexicon.cpp and test_android_input_lexicon.cpp
[23:30] <racarr> you will see what it mostly is :p
[23:30] <racarr> sounds reasonable I guess
[23:30] <racarr> we need to land
[23:30] <racarr> the shell receiving focus fixes anyway
[23:30] <racarr> for autopilot
[23:30] <racarr> we also need to sort the HUD button, which is what the input-injecter is for
[23:30] <ricmm> right
[23:31] <ricmm> ok then
[23:31] <racarr> if input injecter isnt landed in the morning
[23:31] <racarr> well
[23:31] <racarr> I dunno
[23:32] <racarr> we need to land it really because we dont have a backup plan for the hud
[23:32] <ricmm> ok then
[23:32] <ricmm> what extra work does this require?
[23:32] <ricmm> unity-mir injector to deliver to hud surface?
[23:33] <racarr> ricmm: the problem is the shell input area along the bottom of the screen to show the hud button
[23:33] <racarr> is disabled because it would consume events from the client preventing them from seeing
[23:33] <racarr> the bring menu up events at the bottom
[23:33] <racarr> so uynity-mir needs to inject all events in that area
[23:33] <racarr> down to the client as well
[23:34] <ricmm> or it could use an EventFilter to register swipes in that region, and signal to Qt via other mechanisms
[23:34] <ricmm> while still letting events pass for clients
[23:35] <ricmm> I think that would work, as long as the math in the filter doesnt introduce an incredible overhead
[23:35] <racarr> I think the only real problem is
[23:35] <racarr> what is the math
[23:35] <racarr> can you adapt the existing code
[23:35] <racarr> to run in that context easily
[23:37] <ricmm> I dont know either of those answers, the second might be possible to do without a lot of pain
[23:38] <ricmm> the first... it would have to decide whether theres a bottom edge drag
[23:38] <ricmm> and signal when past the threshold for hud
[23:38] <Saviq> ricmm, racarr, the whole thing was designed to receive the whole input stream - both the shell and the app
[23:39] <Saviq> ricmm, racarr, there's an ugly side-channel called BottomBarVisibilityCommunicator or some such, that lets the app (panel) know what's happening
[23:39] <Saviq> ricmm, racarr, recognizing an edge swipe really needs all of the input
[23:40] <ricmm> thats doable with the filter
[23:40] <ricmm> its more about how to define the hud threshold for example
[23:40] <ricmm> as the filter would live in unity-mir
[23:44] <racarr> I need to understand the gesture recognizer more to comment better I guess
[23:44] <racarr> the way I have always imagined it working
[23:44] <racarr> is there is an InputFilter, which does like GestureRecognizer->dealWithEvent(event)
[23:45] <racarr> and eventually gesture recognizer may emit
[23:45] <racarr> signals to QML like
[23:45] <racarr> gesture happening, gesture over, etc
[23:45] <ricmm> right, well all that logic is internal to Qt right now
[23:45] <racarr> but as I understand there is "some issue" with adapting the Gesture recognizer
[23:45] <racarr> right
[23:45] <ricmm> so its not like we would want for the event filter to implement it all
[23:45] <ricmm> im talking specific to the hud case
[23:45] <racarr> maybe yeah
[23:45] <ricmm> where we just want to recognize something without registering for input explicitly
[23:49] <ricmm> uhh
[23:49] <ricmm> racarr: why dont we just make the shell be a monitor?
[23:50] <ricmm> as it works in the SF case
[23:50] <ricmm> there, we set up its surface as monitor
[23:50] <ricmm> and it just sets itself up accordingly
[23:52] <ricmm> with  InputReceptionMode::receives_all_input
[23:54]  * ricmm tries that out
[23:57] <ricmm> alright so that works fine
[23:59] <kgunn> kdub: did thomi ever chime back in ?
[23:59] <kgunn> kdub: i don't think mem use & slowness are related
[23:59] <kgunn> btw