[09:02] <Saviq> mzanetti, I'm testing the silo for bug #1444949, why does the second touch even reach the app behind the launcher? it doesn't when you're not dragging?
[09:02] <Saviq> s/for/wrt/
[09:02] <mzanetti> Saviq, yeah... we noticed that too... albert reported a bug for that too already
[09:02] <mzanetti> not fixed yet
[09:03] <Saviq> ok
[09:03] <Saviq> it might even be a Qt issue, that touch-to-mouse conversion doesn't work when there's another touch in progress or something
[09:53] <Saviq> pstolowski, tsdgeos, any idea where bug #1447056 happens?
[09:56] <tsdgeos> Saviq: nope, i'd say scopes-shell since i don't think we have the hability to refresh a scope? unless it's the is the isActive property
[09:59] <pstolowski> Saviq, tsdgeos most likely shell plugin, but i can't see why without further investigation. setActive seems innocent after a brief look
[10:04] <tsdgeos> have i gone too far in the connect+lambda-ing =
[10:04] <tsdgeos> ?
[10:04] <tsdgeos> http://paste.ubuntu.com/10865338/
[10:05] <tsdgeos> Saviq: mzanetti: ↑↑
[10:06] <tsdgeos> hmmm
[10:07] <tsdgeos> actually i need to redo those
[10:07] <tsdgeos> it's not guaranteed "this" will still be around when all that stuff finishes
[10:08] <mzanetti> tsdgeos, yeah... careful with this
[10:10] <Saviq> tsdgeos, yeah exactly, when lambdas bitten us was because they don't get disconnected
[10:30] <Saviq> pstolowski, tsdgeos, FYI: bug #1447074 - dunno, maybe replace a string like CURRENT_QUERY in the canned url...
[10:33] <pstolowski> Saviq, is this because there is a delay between actually invoking the search after last keystrokes, so you still see old results?
[10:34] <Saviq> pstolowski, yeah
[10:34] <Saviq> pstolowski, you see the old Store icon, you continue typing, and click the old store icon
[10:35] <pstolowski> ack
[10:35] <tsdgeos> Saviq: but that's a bit "wrong"
[10:35] <Saviq> tsdgeos, what is?
[10:35] <tsdgeos> what if the new query would make the icon store disappear
[10:35] <tsdgeos> would you still pass the new query to the old item?
[10:35] <tsdgeos> it works for the store, but what guarantees it'll work for something else?
[10:36] <Saviq> tsdgeos, trueth
[10:36] <pstolowski> yes.. and i think this is really an edge case
[10:36] <Saviq> tsdgeos, but then, you're tapping on an item which is there before the new query completed
[10:36] <MacSlow> Saviq, the current failures on jenkins for my shell-rotation branch (build-dependencies) are to be expected?
[10:36] <Saviq> pstolowski, happens 100% times when I search for an app and go to the store then ;)
[10:37] <tsdgeos> otoh i guess the "old" item can be smart enough and do nothing or present a nice "error" if the new query is unprocessable by it
[10:37] <Saviq> MacSlow, where could it take the new require unity-api etc. from?
[10:38] <pstolowski> Saviq, yeah, sure, i'm just saying it's not something that negatively impacts experience. and it reminds me of the idea we discussed long time ago about graying results out until search completes
[10:39] <Saviq> pstolowski, well, it does negatively impact my user experience because I have to re-type the last two characters ;)
[10:39] <Saviq> pstolowski, but agreed this is not a show-stopper
[10:40] <MacSlow> Saviq, hm...
[10:41] <Saviq> MacSlow, we've no support in CI for dependency chains
[10:41] <Saviq> MacSlow, and there's new unity-api required in the branch prerequisite to yours
[10:46] <Saviq> dednick, I have bug #1446846 to you since two of those are indicators, and you looked at the autopilot stability in any case
[10:47] <mhall119> Saviq: wouldyou like me to create blueprints for these UOS sessions so that you can use them to track work items?
[10:47] <mhall119> or just add them to summit.u.c
[10:48] <Saviq> mhall119, I think pads will be enough
[10:48] <mhall119> ok
[10:54] <mhall119> Saviq: greyback can you register as attending the UOS so I can add you to these meetings?
[10:54] <greyback> ok
[10:54] <dandrader> Saviq, you there?
[10:54] <Saviq> dandrader, yup
[10:54] <Saviq> mhall119, doing
[10:54] <dandrader> Saviq, When I press my kdb's left "windows/start" key, Qt gets Qt::Key_Meta
[10:55] <dandrader> Saviq, not Super_L
[10:55] <greyback> mhall119: done
[10:55] <dednick> Saviq: ok
[10:56] <dandrader> Saviq, btw, what key should generate Qt::Key_Super_L, if any?
[10:56] <Saviq> mhall119, done
[10:56] <mhall119> thanks guys
[10:56] <Saviq> dandrader, windoze
[10:57] <dandrader> Saviq, !?
[10:57] <Saviq> dandrader, but on desktop it's taken over by unity
[10:57] <Saviq> dandrader, the one with the windows logo
[10:57] <Saviq> dandrader, http://en.wikipedia.org/wiki/Super_key_%28keyboard_button%29
[10:57] <dandrader> Saviq, ah, so Unity7 maps Super_L to Meta?
[10:57] <Saviq> does it?
[10:58] <MacSlow> Saviq, how "libunity-api-dev (>= 7.97)" managed to get in there I don't know 7.96 works just fine. But that's just part of the problem.
[10:58] <greyback> Saviq: dandrader: on my mac, the left apple key is Super_L
[10:58] <Saviq> MacSlow, it should not work fine, there's new API in there
[10:59] <Saviq> greyback, yeah, left Windows key is Super_L here, too
[10:59] <greyback> dandrader: sure you're not doing some xmodmap key re-mapping?
[11:00] <Saviq> MacSlow, https://code.launchpad.net/~dandrader/unity-api/shellRotation/+merge/242212
[11:00] <Saviq> MacSlow, `apt-cache policy libunity-api-dev` ?
[11:00] <MacSlow> Saviq, *sigh* I've been using build.sh for too long
[11:00] <Saviq> doesn't really matter
[11:00] <Saviq> build.sh manages that
[11:01] <Saviq> you likely have the correct version from the demo-shell ppa
[11:01] <Saviq> mhall119, done
[11:02] <MacSlow> Saviq, apt-cache reports none installed and install-candidate 7.97+bzr168+1~ubuntu15.04.1 ... I thought I installed everything via .debs on the device
[11:03] <Saviq> MacSlow, that version is from demo-stuff PPA
[11:03] <Saviq> MacSlow, but it's only a build-depend
[11:04] <Saviq> so it won't be on your phone unless you build on it
[11:04] <dandrader> greyback, Saviq, I have a stock unity7
[11:05] <Saviq> dandrader, why do you say "maps Super_L to Meta"?
[11:06] <greyback> dandrader: as a test, run "xev | grep -A 2 KeyPress" in a terminal, then tap your Windows key and see what it prints
[11:06] <MacSlow> Saviq, so what's the release-plan for libunity-api then... I don't think I can use the demo-stuff-ppa as a build-dependency :)
[11:06] <greyback> dandrader: that will at least show it is X which is munging your keys, not unity
[11:06] <Saviq> MacSlow, as every time in the past year, it will get released along unity8 in the same silo
[11:07] <Saviq> along with qtmir, qtubuntu, ubuntu-keyboard, ubuntu-ui-toolkit, which are all interdependent
[11:08] <MacSlow> Saviq, so the jenkins failure of my branch is something I've to accept for the time being?!
[11:10] <Saviq> MacSlow, yes
[11:13] <willcooke> You know how the Automatic mode for U8 is based on # of kbs, # of mice etc - and it's hard coded in the QML
[11:13] <Saviq> ???
[11:13] <willcooke> :D
[11:14] <Saviq> mzanetti, ↑
[11:14] <Saviq> yeah what about it?
[11:14] <willcooke> What would be super nice is if those numbers are moved from hard coded values to settings
[11:14]  * mzanetti nods
[11:14] <mzanetti> urgent?
[11:14] <willcooke> Do I propose a new User Story and get it in your backlog
[11:14] <willcooke> mzanetti, nahhh
[11:14] <Saviq> willcooke, mzanetti, waiteth
[11:15] <willcooke> just want to know how I go about formally requesting it
[11:15] <dandrader> greyback, it does say Super_L
[11:15] <Saviq> it's going to be the scenario selector's responsibility
[11:15] <mzanetti> willcooke, Saviq: ack. will do that when I prepare that branch for landing into trunk
[11:15] <mzanetti> Saviq, there's a card for that inputinfo stuff already
[11:16] <Saviq> no point in making it a setting?
[11:16] <Saviq> dandrader, I see you put the fake timers inside the test itself, I thought you'd put it in a shared bit in tests/utils for future use?
[11:16] <willcooke> so, end goal here is that the new snappy desktop could be installed on that x86 tablet Ive got for demos and it would switch with no hacks required from me
[11:16] <dandrader> Saviq, can be moved to separate files when needed
[11:16] <Saviq> dandrader, k
[11:16] <Saviq> unless we forget ;)
[11:17] <willcooke> the issue is that, because it's stupid, we can't say kbds > 0 because in their wisdom, they made the power button and the vol up/down button an entire keyboard
[11:17] <willcooke> ya rly
[11:17] <Saviq> yeah, obviously our decision making will need to be smarter
[11:18] <Saviq> (hint hint: it should be based off of mice, not keyboards)
[11:18] <Saviq> (isn't it?)
[11:19] <greyback> dandrader: hmm, then something higher than x remapping that key. not sure what that might be tbh
[11:19] <willcooke> Saviq, good call
[11:19] <willcooke> oh
[11:19] <dandrader> greyback, Saviq, Qt itself is doing it: "Qt::Key_Meta -> On OS X, this corresponds to the Control keys. On Windows keyboards, this key is mapped to the Windows key."
[11:19] <willcooke> I wonder...
[11:19] <Saviq> greyback, didn't he just say it *does* say Super_L?
[11:20] <Saviq> dandrader, well, yeah, Meta is a catch-all likely
[11:20] <dandrader> Saviq, that was with "xev | grep -A 2 KeyPress"
[11:20] <Saviq> dandrader, yes, and I get a Super_L there, too, where do you get Meta for it?
[11:20] <greyback> Saviq: yeah, but he was reporting Qt said Meta key was pressed.
[11:20] <Saviq> ah
[11:21] <dandrader> Saviq, so Qt gets a native Super_L event and send a Qt::Key_Meta to the application
[11:21] <Saviq> dandrader, interestingly I used Super_L when testing the new kernel with the new keycode, and that worked?
[11:21] <greyback> and in the xcb plugin, XC_Super_L maps straight to Qt's SuperL
[11:21] <Saviq> dandrader, does it send just the Meta or both Meta and Super_L?
[11:22] <Saviq> because for sure Super_L worked for me on the phone at least
[11:23] <dandrader> greyback, Saviq, http://paste.ubuntu.com/10865549/
[11:23] <dandrader> greyback, Saviq, that's ./plugins/platforms/xcb/qxcbkeyboard.cpp
[11:23] <Saviq> ok so it's xcb
[11:23] <greyback> dandrader: yuk
[11:23] <dandrader> Saviq, no, it sends only Meta
[11:23] <Saviq> yeah, yuk
[11:24] <Saviq> but
[11:24] <Saviq> what is rmod_masks.meta
[11:24] <greyback> dandrader: sure that code path being hit? That's only if super used as meta modifier, which is language/settings specific
[11:24] <Saviq> looks kinda configurable
[11:25] <Saviq> yeah, /me remembers a whole set of options in the keyboard settings panel, not there now
[11:26] <dandrader> greyback, no, but that's the only place I found where you have Meta and Super_L together
[11:26] <Saviq> dandrader, yeah, that's a configurable bit, you (a user) can decide to have it mapped to Meta
[11:26] <greyback> Saviq: yep, I'm struggling to find it. There was definitely an option to remap super key to a meta key something
[11:28] <Saviq> dandrader, there was a menu like so before http://askubuntu.com/questions/19558/what-are-the-meta-super-and-hyper-keys
[11:28] <Saviq> not sure where it's gone
[11:33] <mhall119> mzanetti: can you register as attending the UOS too so I can make you the host of http://summit.ubuntu.com/uos-1505/meeting/22440/demo-unity-8-in-desktop-mode/ ?
[11:38] <Saviq> /food
[11:39] <mzanetti> mhall119, takes a bit until it accepts that I've registered to UOS
[11:50] <mhall119> mzanetti: if you registered for the sprint in LP yes, it has to wait for the cron job to import it
[11:50] <mhall119> mzanetti: but you're all set now, thanks
[13:21] <Saviq> dandrader, you need to fix your editor to strip trailing whitespace on save ;)
[13:23] <dandrader> yeha
[13:40] <tsdgeos> Saviq: mzanetti: greyback: hmmmm, so i am doing the "show splashscreen without spinner if on spread but not running and no screenshot" part and realized for that i need to have a property that tells me "this is fake" which we don't have as a state, we have starting, running, suspended, stopped. I could easily add a new state to those but those live in qtmir and means deciding we'll inject the "fake" apps at the qtmir level now instead of when doing the
[13:40] <tsdgeos> work, alternatively i can put it in unity8 with a comment saying to decide it later or i can "abuse/reuse"  the stopped state. Opinion?
[13:42] <mzanetti> I think stopped is what it ism no?
[13:42] <mzanetti> s/ism/is,/
[13:42] <Saviq> yeah that's what "I ran the app but it died" means
[13:43] <Saviq> I think
[13:43] <mzanetti> yes
[13:43] <greyback> yeah, stopped means the app's process was OOM killed
[13:43] <mzanetti> "I haven't ran the app" is, it doesn't exist in the AppMan model
[13:43] <Saviq> yup
[13:43] <Saviq> tsdgeos, ↑
[13:44] <greyback> one could abuse the "stopped" state to cover those not-yet-started apps
[13:44] <mzanetti> greyback, IMO that's not even abusing it
[13:44] <mzanetti> it's exactly what it is is for
[13:44] <tsdgeos> well
[13:45] <tsdgeos> it is and it is not _:D
[13:45] <tsdgeos> the docu says
[13:45] <tsdgeos> it was OOM killed and stuff
[13:45] <tsdgeos> in this case it would be
[13:45] <tsdgeos> i rebooted and has not even started
[13:45] <tsdgeos> but ok, i'll use that one
[13:45] <mzanetti> ok. should be "it was killed by OOM or a reboot"
[13:45] <greyback> mzanetti: yeah, I debated writing "abuse"
[13:46] <greyback> it wasn't the initial intention anyway
[13:46] <greyback> and a "stopped" state does imply it was once running
[13:46] <Saviq> does it
[13:46] <mzanetti> yeah.
[13:46] <Saviq> it's a state, it's stopped
[13:46] <mzanetti> :D
[13:46] <Saviq> you could very well say "notRunning"
[13:46] <greyback> stopped != "not running"
[13:47]  * Saviq disagrees
[13:47] <mzanetti> anyhow... we agree that tsdgeos can go ahead with the stopped one :D
[13:47] <Saviq> ;)
[13:48] <Saviq> Cyanogen in "strategic partnership" with Microsoft...
[13:49] <tsdgeos> yep
[13:49] <tsdgeos> they're going to ship all the apps
[14:16] <seb128> hey there
[14:17] <seb128> how would things like changing user fonts work under unity8?
[14:17] <seb128> is that something worked on?
[14:17] <seb128> or having a bug/blueprint for tracking purpose?
[14:18] <seb128> (on X for e.g GTK there is a xsettings set that GTK reads)
[14:26] <Saviq> seb128, more of a UITK question
[14:26] <Saviq> seb128, if not a Mir one, even, depending if they want it there
[14:27] <Saviq> or both..
[14:27] <Saviq> definitely worth talking about
[14:29] <greyback> seb128: yeah would need some replacement for xsettings. gtk on wayland will have the same problem, so they must have a solution made somehow
[14:37] <mterry> MacSlow, do you have an encrypted home dir?
[14:38] <MacSlow> mterry, not anymore
[14:38] <mterry> MacSlow, excellent.  Then one option for you if you have down time is investigate bug 1435364
[14:38] <dandrader> MacSlow, if you're looking for reviews: https://code.launchpad.net/~dandrader/unity8/autoInstallTouchRegistry/+merge/256726
[14:38] <dandrader> MacSlow, would offload tsdgeos
[14:38] <tsdgeos> dandrader: isn't it crashing?
[14:39] <dandrader> tsdgeos, that branch?
[14:39] <tsdgeos> i think that's what qmluitests said
[14:39] <tsdgeos> let me check
[14:40] <tsdgeos> yeah https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/736/console
[14:40] <tsdgeos> QWARN  : tst_TouchRegistry::removeOldUndecidedCandidates() [TouchRegistry] Candidate for touch 0 defaulted!
[14:40] <tsdgeos> QFATAL : tst_TouchRegistry::removeOldUndecidedCandidates() Received signal 11
[14:40] <tsdgeos> FAIL!  : tst_TouchRegistry::removeOldUndecidedCandidates() Received a fatal error.
[14:40] <dandrader> tsdgeos, yeah, just saw that.
[14:56] <MacSlow> mterry, dandrader: I'll look at dandrader's branch first... since the QtCreator mount issue seems to need some preparation setup to reproduce
[14:56] <mterry> MacSlow, yeah no worries
[14:57] <mterry> MacSlow, I won't assume you're looking into it until you tell me so  :)  Thanks for consideringn it
[14:58] <MacSlow> mterry, sure
[15:15] <sidi_> What exactly does plugins/unityshell/ contain?
[15:18] <sidi_> is it the UI with a search bar on the top left corner?
[15:37] <Saviq> sidi_, I'm not familiar with the unity codebase, but yes, the dash (press super/windows key), launcher, the top panel with indicators etc., all that is a compiz plugin
[15:39] <seb128> Saviq, greyback, thanks
[16:03] <Saviq> greyback, got a pointer to scancode → qt key mappings?
[16:05] <greyback> Saviq: qtbase/src/plugins/platforms/xcb/qxcbkeyboard.cpp if you're talking X11
[16:05] <Saviq> yeah good enough
[16:05] <Saviq> tx
[16:05] <greyback> np
[16:07] <Saviq> ok this is bad/weird
[16:08]  * Saviq getting some crazy key code ;(
[16:13] <Saviq> dandrader|afk, we seem to have a problem, silo 25 has your branch built, but I'm getting some crazy key id (269025111, correct would be 16777299), even though native scan code looks correct - 133 for Super_L...)
[16:13]  * Saviq flashing from scratch
[16:21] <Saviq> greyback, any idea ↑?
[16:24] <greyback> Saviq: not a clue
[16:26] <Saviq> the bad value is like an order of magnitude wrong...
[16:36] <dandrader> Saviq, should have stayed with the Home_Key... :)
[16:37] <dandrader> Saviq, 269025111 doesn't map to any key at all I think
[16:38] <dandrader> Saviq, should I start debugging or are you on it already?
[16:39] <Saviq> dandrader, couldn't stay with Home unless we ate that key, and then people connecting keyboards would lose Home
[16:39] <greyback> Saviq: maybe MIR_CLIENT_INPUT_RECEIVER_REPORT=log will output the raw key events that unity8 sees
[16:39] <Saviq> dandrader, evdev says: key event at 1429720683.794992, 133 (KEY_COPY), up
[16:39] <Saviq> greyback, thanks, helpful
[16:41] <Saviq> dandrader, greyback, http://pastebin.ubuntu.com/10866894/
[16:42] <Saviq> that looks fine, doesn't it...
[16:42] <greyback> Saviq: isn't 269025111 the bad value?
[16:43] <Saviq> greyback, ah hmm, so maybe it's just a case that this is a not-mapped key_code
[16:43] <Saviq> since power is   key_code: 269025066
[16:43] <Saviq>   scan_code: 116
[16:44] <dandrader> ahh, 269025111 is an XKB value...
[16:44] <Saviq> in any case, evdev says it's key_copy, which is likely not mapped
[16:44] <greyback> Saviq: think mir uses this table: 3rd_party/android-deps/android/keycodes.h
[16:45] <dandrader> greyback, Saviq, there's a table in qtmir that maps XKB to Qt key codes
[16:45] <dandrader> in qteventfeeder.cpp
[16:46] <Saviq> ETOOMANYTABLE
[16:46] <Saviq> S
[16:47] <greyback> dandrader: true, but something has to map raw events to xkb, and I think that's mir's job
[16:47] <dandrader> greyback, yes
[16:47] <Saviq> XKB_KEY_XF86Copy
[16:48] <Saviq> ok there's nothing to say, I'm just getting some weird key code that's all
[16:49] <Saviq> dandrader, greyback, thanks, we're handling it in phablet
[17:08] <Saviq> dandrader, greyback, FYI: super in Mir == KEY_LEFTMETA
[17:08] <Saviq> or rather in raw events
[17:08] <Saviq> i.e. it's X11 that maps it to Super_L
[17:08] <greyback> Saviq: sounds wrong, isn't alt the meta key?
[17:09] <Saviq> greyback, alt is alt
[17:09] <greyback> Saviq: yeah, ignore me
[18:23] <Saviq> dandrader, seems we forgot about distinguishing between tap vs. long press
 Saviq, if i slowly swipe from the bottom dash is reset first and then the bottom edge works.
[18:24] <Saviq> dandrader, ↑
[18:25] <dandrader> Saviq, it's like its light. it blinks on press, not only after you release it
[18:28] <Saviq> om26er, ↑
[18:29] <Saviq> I'm not sure, could go for either
[18:29] <om26er> dandrader, aah, so we have to stick to this behavior done? unless something on the kernel is changed ?
[18:30] <Saviq> om26er, no, we could do what you say, dandrader's just making the point that it behaves like the light, you pressed it, so it acts
[18:31] <Saviq> om26er, and I get that argument, we'd need a designer here who actually thought this through
[18:31] <Saviq> both make some sense
[18:33] <om26er> Saviq, yeah, I think we need an agreement on how the functionality is supposed to be.
[18:34] <Saviq> om26er, there's very little detail on that tbh
[18:34] <Saviq> om26er, there's nothing planned for long press for the button for now
[18:34] <Saviq> om26er, and I agree with Daniel that it follows the HW behaviour
[18:35] <Saviq> om26er, so I'd say we should go for what it does now and once we have someone that actually thinks this through UX/design wise, we'll revisit
[18:36] <om26er> Saviq, hmm, ok. I'll go with that.
[18:36] <om26er> Saviq,
[18:36] <om26er> oops
[18:40] <om26er> Saviq, whats the regression potential of this change, I see it barely changes any old code.
[18:40] <om26er> except for random crashes :)
[18:48] <om26er> Saviq, totally irrelevant: whats the progress on "scopes in right edge switcher" thing ?
[18:51] <Saviq> om26er, under design proto + testing
[18:52] <Saviq> om26er, very little, it really could only affect bottom edge in apps, but even that's very unlikely since we're only monitoring events and not accepting them
[18:59] <om26er> Saviq, ok. btw the bottom edge behavior is very annoying inside apps as well, a lazy drag is now very likely to bring back dash.
[19:00] <om26er> also I have been just told that silos can land tomorrow as well. So probably would make sense to run this through design and if needed iterate on it tomorrow ?
[19:25] <Saviq> om26er, I see what you mean, we'll get on it straight away in the morning