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