| === timchen1` is now known as timchen119 | ||
| 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 |
|---|---|---|
| ubot5 | bug 1444949 in unity8 (Ubuntu) "Launcher reordering interrupted by second touch causes launcher confusion" [Medium,In progress] https://launchpad.net/bugs/1444949 | 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:02 |
| 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:03 |
| Saviq | pstolowski, tsdgeos, any idea where bug #1447056 happens? | 09:53 |
| ubot5 | bug 1447056 in unity8 (Ubuntu) "Favourite scopes forcefully refreshed when opened from Manage Dash" [Undecided,New] https://launchpad.net/bugs/1447056 | 09:53 |
| 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:56 |
| pstolowski | Saviq, tsdgeos most likely shell plugin, but i can't see why without further investigation. setActive seems innocent after a brief look | 09:59 |
| tsdgeos | have i gone too far in the connect+lambda-ing = | 10:04 |
| tsdgeos | ? | 10:04 |
| tsdgeos | http://paste.ubuntu.com/10865338/ | 10:04 |
| tsdgeos | Saviq: mzanetti: ↑↑ | 10:05 |
| tsdgeos | hmmm | 10:06 |
| 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:07 |
| mzanetti | tsdgeos, yeah... careful with this | 10:08 |
| Saviq | tsdgeos, yeah exactly, when lambdas bitten us was because they don't get disconnected | 10:10 |
| Saviq | pstolowski, tsdgeos, FYI: bug #1447074 - dunno, maybe replace a string like CURRENT_QUERY in the canned url... | 10:30 |
| ubot5 | bug 1447074 in unity8 (Ubuntu) "Need a way to pass current search query with a URL" [Undecided,New] https://launchpad.net/bugs/1447074 | 10:30 |
| pstolowski | Saviq, is this because there is a delay between actually invoking the search after last keystrokes, so you still see old results? | 10:33 |
| Saviq | pstolowski, yeah | 10:34 |
| Saviq | pstolowski, you see the old Store icon, you continue typing, and click the old store icon | 10:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| MacSlow | Saviq, hm... | 10:40 |
| 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:41 |
| 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:46 |
| ubot5 | bug 1446846 in unity8 (Ubuntu) "Three consistent autopilot test failures" [High,Triaged] https://launchpad.net/bugs/1446846 | 10:46 |
| 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:47 |
| Saviq | mhall119, I think pads will be enough | 10:48 |
| mhall119 | ok | 10:48 |
| 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:54 |
| dandrader | Saviq, not Super_L | 10:55 |
| greyback | mhall119: done | 10:55 |
| dednick | Saviq: ok | 10:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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? | 10:59 |
| 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:00 |
| Saviq | you likely have the correct version from the demo-shell ppa | 11:01 |
| Saviq | mhall119, done | 11:01 |
| 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:02 |
| Saviq | MacSlow, that version is from demo-stuff PPA | 11:03 |
| Saviq | MacSlow, but it's only a build-depend | 11:03 |
| 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:04 |
| Saviq | dandrader, why do you say "maps Super_L to Meta"? | 11:05 |
| 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:06 |
| Saviq | along with qtmir, qtubuntu, ubuntu-keyboard, ubuntu-ui-toolkit, which are all interdependent | 11:07 |
| MacSlow | Saviq, so the jenkins failure of my branch is something I've to accept for the time being?! | 11:08 |
| Saviq | MacSlow, yes | 11:10 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| Saviq | (hint hint: it should be based off of mice, not keyboards) | 11:18 |
| Saviq | (isn't it?) | 11:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| Saviq | because for sure Super_L worked for me on the phone at least | 11:22 |
| 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:23 |
| 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:24 |
| Saviq | yeah, /me remembers a whole set of options in the keyboard settings panel, not there now | 11:25 |
| 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:26 |
| === MacSlow is now known as MacSlow|lunch | ||
| 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:28 |
| 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:33 |
| Saviq | /food | 11:38 |
| mzanetti | mhall119, takes a bit until it accepts that I've registered to UOS | 11:39 |
| 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 | 11:50 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === MacSlow|lunch is now known as MacSlow | ||
| Saviq | dandrader, you need to fix your editor to strip trailing whitespace on save ;) | 13:21 |
| dandrader | yeha | 13:23 |
| 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:40 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| * Saviq disagrees | 13:47 | |
| mzanetti | anyhow... we agree that tsdgeos can go ahead with the stopped one :D | 13:47 |
| Saviq | ;) | 13:47 |
| Saviq | Cyanogen in "strategic partnership" with Microsoft... | 13:48 |
| tsdgeos | yep | 13:49 |
| tsdgeos | they're going to ship all the apps | 13:49 |
| seb128 | hey there | 14:16 |
| 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:17 |
| seb128 | (on X for e.g GTK there is a xsettings set that GTK reads) | 14:18 |
| Saviq | seb128, more of a UITK question | 14:26 |
| Saviq | seb128, if not a Mir one, even, depending if they want it there | 14:26 |
| Saviq | or both.. | 14:27 |
| Saviq | definitely worth talking about | 14:27 |
| 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:29 |
| mterry | MacSlow, do you have an encrypted home dir? | 14:37 |
| 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 |
| ubot5 | bug 1435364 in unity8 (Ubuntu) "Lockscreen unresponsive after starting app from QtC or cmdline" [High,Triaged] https://launchpad.net/bugs/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:38 |
| dandrader | tsdgeos, that branch? | 14:39 |
| tsdgeos | i think that's what qmluitests said | 14:39 |
| tsdgeos | let me check | 14:39 |
| 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:40 |
| 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:56 |
| mterry | MacSlow, I won't assume you're looking into it until you tell me so :) Thanks for consideringn it | 14:57 |
| MacSlow | mterry, sure | 14:58 |
| sidi_ | What exactly does plugins/unityshell/ contain? | 15:15 |
| === dandrader is now known as dandrader|afk | ||
| sidi_ | is it the UI with a search bar on the top left corner? | 15:18 |
| 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:37 |
| seb128 | Saviq, greyback, thanks | 15:39 |
| Saviq | greyback, got a pointer to scancode → qt key mappings? | 16:03 |
| 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:05 |
| Saviq | ok this is bad/weird | 16:07 |
| * Saviq getting some crazy key code ;( | 16:08 | |
| 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:13 | |
| Saviq | greyback, any idea ↑? | 16:21 |
| greyback | Saviq: not a clue | 16:24 |
| Saviq | the bad value is like an order of magnitude wrong... | 16:26 |
| === dandrader|afk is now known as dandrader | ||
| dandrader | Saviq, should have stayed with the Home_Key... :) | 16:36 |
| dandrader | Saviq, 269025111 doesn't map to any key at all I think | 16:37 |
| dandrader | Saviq, should I start debugging or are you on it already? | 16:38 |
| 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:39 |
| Saviq | dandrader, greyback, http://pastebin.ubuntu.com/10866894/ | 16:41 |
| Saviq | that looks fine, doesn't it... | 16:42 |
| greyback | Saviq: isn't 269025111 the bad value? | 16:42 |
| 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:43 |
| 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:44 |
| dandrader | greyback, Saviq, there's a table in qtmir that maps XKB to Qt key codes | 16:45 |
| dandrader | in qteventfeeder.cpp | 16:45 |
| Saviq | ETOOMANYTABLE | 16:46 |
| Saviq | S | 16:46 |
| 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:47 |
| Saviq | ok there's nothing to say, I'm just getting some weird key code that's all | 16:48 |
| Saviq | dandrader, greyback, thanks, we're handling it in phablet | 16:49 |
| 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:08 |
| Saviq | greyback, alt is alt | 17:09 |
| greyback | Saviq: yeah, ignore me | 17:09 |
| Saviq | dandrader, seems we forgot about distinguishing between tap vs. long press | 18:23 |
| Saviq | <om26er> Saviq, if i slowly swipe from the bottom dash is reset first and then the bottom edge works. | 18:24 |
| Saviq | dandrader, ↑ | 18:24 |
| dandrader | Saviq, it's like its light. it blinks on press, not only after you release it | 18:25 |
| Saviq | om26er, ↑ | 18:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| om26er | Saviq, yeah, I think we need an agreement on how the functionality is supposed to be. | 18:33 |
| 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:34 |
| 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:35 |
| om26er | Saviq, hmm, ok. I'll go with that. | 18:36 |
| om26er | Saviq, | 18:36 |
| om26er | oops | 18:36 |
| 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:40 |
| om26er | Saviq, totally irrelevant: whats the progress on "scopes in right edge switcher" thing ? | 18:48 |
| Saviq | om26er, under design proto + testing | 18:51 |
| 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:52 |
| 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. | 18:59 |
| 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:00 |
| Saviq | om26er, I see what you mean, we'll get on it straight away in the morning | 19:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!