=== mzanetti_ is now known as mzanetti [11:02] greyback, mir currently doesn't provide the display's physical size (although it has API for that). Do you mind if I made qtmir fallback to querying ro.sf.lcd_density android property (in case the mir property is empty, as it is now)? [11:03] dandrader: why do we need it? [11:04] greyback, I would like EdgeDragArea's properties to be based on physical sizes instead of grid units [11:04] I'd rather Mir fixes the API. We shouldn't have to work around Mir faults [11:04] greyback, sure, they will fix it. but might take some time. I don't want to be blocked by that [11:04] but for middle-ground, make it a giant REMOVEME [11:18] dandrader, /me not sure we want to make edge areas oblivious of GRID_UNIT_PX [11:19] Saviq, why? a user's finger lives in the physical world [11:19] as the idea behind switching e.g. a big phone from 50 to 40 GU wide is to make touch targets bigger, too [11:19] and how is the edge touch target different... especially if these days we have them smart about non-edge-swipes [11:20] dandrader, yeah, but the user's finger might just be bigger/older/less dexterous [11:21] I do think we might actually need a per-device factor, to potentially cater for worse touch hw [11:21] Saviq, but does that make the finger grid unit based? [11:21] dandrader, it does make it the user's decision on what size the grid is [11:22] Saviq, making it based on physical units doesn't mean it's worse for bigger/older/less dexterous fingers. I don't see the relationship [11:23] dandrader, you sure? [11:23] dandrader, don't get me wrong, I don't have data on this or anything [11:24] dandrader, I'm just raising a concern [11:24] dandrader, already on arale it's tricky to drag from the edge because they're "sharp" [11:25] so if we make the edge area smaller because it's more dense, it might get even trickier [11:25] Saviq, physical units means mm, not pixels! [11:26] dandrader, I know, but we're not doing anything in the phone in mm [11:26] dandrader, that's why we have the grid, some people like their mm bigger than others ;) [11:26] that's our way of dealing with dpi difference [11:27] Saviq, a gesture is not a graphical UI item, it's an action that happens in the physical world. you edge-swipe the same way regardless of the screen dpi or how big the ui elements are [11:28] dandrader, well that's the thing I'm not so sure of, but ok :) [11:28] Saviq, edge-swipe properies have to be made so that false-negatives don't happen anyway, as they're very frustrating [11:29] Saviq, do you want to make grid units also scale timers? like make animations slower? :-) [11:29] Saviq, as the big old finger is also slower [11:29] dandrader, that's reaching, isn't it ;) [11:30] dandrader, I'm just saying that if you increase touch targets (i.e. item sizes) everywhere in the UI by switching to the "zoomed" mode or whatever we call it [11:30] that might be an indication that we should make the edge swipes somewhat more forgiving, too [11:31] dunno, not really sure it's us who should have the discussion anyway (without some user testing data) === dandrader is now known as dandrader|afk === MacSlow is now known as MacSlow|lunch === dandrader|afk is now known as dandrader === marcusto_ is now known as marcustomlinson === MacSlow|lunch is now known as MacSlow [14:04] Saviq, how's landing-006 looking so far? [14:05] dandrader, just flashed again after the tweaks from Gerry and Robert [14:21] elopio, hey, on cleaning up py2, you might also have a look at libautopilot-qt, it pulls qt4 onto the phone whenever I install unity8-autopilot... and IIUC there's a dep loop between libautopilot-qt and autopilot-qt{4,5} [14:23] Saviq: can you please report a bug? I will tell jfunk to put it close to the top, as this unneeded deps makes running tests in read-only harder than it should be. [14:23] elopio, sure, doing [14:25] elopio, hmm actually it seems like it might be our issue after all, we should depend autopilot-qt5 instead [14:26] elopio, could you include that change in your branch? [14:29] Saviq: instead of libautopilot-qt? [14:30] elopio, yeah, libautopilot-qt says "This is a compatibility package depending on both the Qt4 and Qt5 drivers." [14:30] and then autopilot-qt5 says "Replaces: libautopilot-qt (<< 1.4+14.10.20140724.1-0ubuntu2)" [14:31] Saviq: ok, but autopilot-qt5 doesn't install qttestability-autopilot [14:31] elopio, then you might need to add that (even if it's weird that it doesn't...) [14:32] Saviq: yes. I don't fully understand this, I'd prefer to do it in a different branch. [14:32] ah right, qttestability-autopilot needs either of autopilot-qt{4,5} [14:32] I'll give it a try. [14:32] elopio, it's fine, there's no way to determine which of autopilot-qt{4,5} it needs [14:33] elopio, so you need to add both autopilot-qt5 and qttestability-autopilot [14:33] Saviq: yes, but I'll make a new branch, if you don't mind. [14:33] elopio, your call [14:34] elopio, I can take care of that then [14:34] elopio, thought it'd make sense in the same branch, but if you think not, I'll do [14:34] Saviq: don't worry, I'm have the changes and I'll push. [14:34] k [14:34] we'll know soon enough [14:39] Saviq: the toolkit depends on libautopilot-qt, so we'll need to change it there too to be useful. I'll file bugs about that. [14:39] elopio, sure, same as with py2 ;) [14:40] elopio, http://paste.ubuntu.com/10550731/ [14:40] oh shit :) [14:40] so yeah, I think we didn't get the memo to transition from libautopilot-qt [14:45] we can't make autopilot-qt5 depend on qttestability-autopilot, because there would be a loop in there. [14:45] maybe a libautopilot-qt5 makes sense. [14:45] I'll talk to veebers on monday. He should know. [15:39] mzanetti, are you still reviewing the shellRotation branch? [15:40] dandrader, not right now... but given we can't go into vivid with that it's not totally high priority atm is it? [15:40] dandrader, I'll continue next week for sure. but feel like having to fix that darn dpr thing [15:42] mzanetti, we can't land right now becuse it needs the autopilot test paulliu [15:43] dandrader, ack. so yes, I'll continue reviewing, but it's not on the top of my priority list atm [15:43] mzanetti, as for landing in vivid, as far as I understood with would just merge it to trunk and create a separate branch from which we would cherry pick changes for vivid [15:43] Saviq, right? ^ [15:43] yeah... that sounds about right [15:43] mzanetti, sure [15:44] dandrader, we'd like to do that, yes, but we don't have buy-in from foundations yet [15:45] Saviq, or we could do the other way round: have a branch like lp:unity8/devel and cherry pick non-feature stuff onto lp:unity8, as mir guys were doing in the past [15:45] let's call it staging [15:45] :D [15:46] dandrader, long story short, we don't want that, not without automation running on those [15:48] dandrader, we have a long-standing request in the CI team backlog for that, actually [15:49] dandrader, but ultimately, without an archive to put the built packages into, we're doomed, 'cause as soon as you change something in unity-api, for example, you can't build against vivid [15:49] so we need a target for the releases, which we'd like to be a PPA on top of vivid === jhodapp_ is now known as jhodapp === dandrader is now known as dandrader|lunch === jfunk is now known as jfunk-lunch === alan_g is now known as alan_g|EOW === dandrader|lunch is now known as dandrader === jfunk-lu_ is now known as jfunk