[11:02] <dandrader> 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] <greyback> dandrader: why do we need it?
[11:04] <dandrader> greyback, I would like EdgeDragArea's properties to be based on physical sizes instead of grid units
[11:04] <greyback> I'd rather Mir fixes the API. We shouldn't have to work around Mir faults
[11:04] <dandrader> greyback, sure, they will fix it. but might take some time. I don't want to be blocked by that
[11:04] <greyback> but for middle-ground, make it a giant REMOVEME
[11:18] <Saviq> dandrader, /me not sure we want to make edge areas oblivious of GRID_UNIT_PX
[11:19] <dandrader> Saviq, why? a user's finger lives in the physical world
[11:19] <Saviq> 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] <Saviq> and how is the edge touch target different... especially if these days we have them smart about non-edge-swipes
[11:20] <Saviq> dandrader, yeah, but the user's finger might just be bigger/older/less dexterous
[11:21] <Saviq> I do think we might actually need a per-device factor, to potentially cater for worse touch hw
[11:21] <dandrader> Saviq, but does that make the finger grid unit based?
[11:21] <Saviq> dandrader, it does make it the user's decision on what size the grid is
[11:22] <dandrader> 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] <Saviq> dandrader, you sure?
[11:23] <Saviq> dandrader, don't get me wrong, I don't have data on this or anything
[11:24] <Saviq> dandrader, I'm just raising a concern
[11:24] <Saviq> dandrader, already on arale it's tricky to drag from the edge because they're "sharp"
[11:25] <Saviq> so if we make the edge area smaller because it's more dense, it might get even trickier
[11:25] <dandrader> Saviq, physical units means mm, not pixels!
[11:26] <Saviq> dandrader, I know, but we're not doing anything in the phone in mm
[11:26] <Saviq> dandrader, that's why we have the grid, some people like their mm bigger than others ;)
[11:26] <Saviq> that's our way of dealing with dpi difference
[11:27] <dandrader> 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] <Saviq> dandrader, well that's the thing I'm not so sure of, but ok :)
[11:28] <dandrader> Saviq, edge-swipe properies have to be made so that false-negatives don't happen anyway, as they're very frustrating
[11:29] <dandrader> Saviq, do you want to make grid units also scale timers? like make animations slower? :-)
[11:29] <dandrader> Saviq, as the big old finger is also slower
[11:29] <Saviq> dandrader, that's reaching, isn't it ;)
[11:30] <Saviq> 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] <Saviq> that might be an indication that we should make the edge swipes somewhat more forgiving, too
[11:31] <Saviq> dunno, not really sure it's us who should have the discussion anyway (without some user testing data)
[14:04] <dandrader> Saviq, how's landing-006 looking so far?
[14:05] <Saviq> dandrader, just flashed again after the tweaks from Gerry and Robert
[14:21] <Saviq> 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] <elopio> 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] <Saviq> elopio, sure, doing
[14:25] <Saviq> elopio, hmm actually it seems like it might be our issue after all, we should depend autopilot-qt5 instead
[14:26] <Saviq> elopio, could you include that change in your branch?
[14:29] <elopio> Saviq: instead of libautopilot-qt?
[14:30] <Saviq> elopio, yeah, libautopilot-qt says "This is a compatibility package depending on both the Qt4 and Qt5 drivers."
[14:30] <Saviq> and then autopilot-qt5 says "Replaces: libautopilot-qt (<< 1.4+14.10.20140724.1-0ubuntu2)"
[14:31] <elopio> Saviq: ok, but autopilot-qt5 doesn't install qttestability-autopilot
[14:31] <Saviq> elopio, then you might need to add that (even if it's weird that it doesn't...)
[14:32] <elopio> Saviq: yes. I don't fully understand this, I'd prefer to do it in a different branch.
[14:32] <Saviq> ah right, qttestability-autopilot needs either of autopilot-qt{4,5}
[14:32] <elopio> I'll give it a try.
[14:32] <Saviq> elopio, it's fine, there's no way to determine which of autopilot-qt{4,5} it needs
[14:33] <Saviq> elopio, so you need to add both autopilot-qt5 and qttestability-autopilot
[14:33] <elopio> Saviq: yes, but I'll make a new branch, if you don't mind.
[14:33] <Saviq> elopio, your call
[14:34] <Saviq> elopio, I can take care of that then
[14:34] <Saviq> elopio, thought it'd make sense in the same branch, but if you think not, I'll do
[14:34] <elopio> Saviq: don't worry, I'm have the changes and I'll push.
[14:34] <Saviq> k
[14:34] <Saviq> we'll know soon enough
[14:39] <elopio> 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] <Saviq> elopio, sure, same as with py2 ;)
[14:40] <Saviq> elopio, http://paste.ubuntu.com/10550731/
[14:40] <elopio> oh shit :)
[14:40] <Saviq> so yeah, I think we didn't get the memo to transition from libautopilot-qt
[14:45] <elopio> we can't make autopilot-qt5 depend on qttestability-autopilot, because there would be a loop in there.
[14:45] <elopio> maybe a libautopilot-qt5 makes sense.
[14:45] <elopio> I'll talk to veebers on monday. He should know.
[15:39] <dandrader> mzanetti, are you still reviewing the shellRotation branch?
[15:40] <mzanetti> 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] <mzanetti> dandrader, I'll continue next week for sure. but feel like having to fix that darn dpr thing
[15:42] <dandrader> mzanetti, we can't land right now becuse it needs the autopilot test paulliu
[15:43] <mzanetti> dandrader, ack. so yes, I'll continue reviewing, but it's not on the top of my priority list atm
[15:43] <dandrader> 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] <dandrader> Saviq, right? ^
[15:43] <mzanetti> yeah... that sounds about right
[15:43] <dandrader> mzanetti, sure
[15:44] <Saviq> dandrader, we'd like to do that, yes, but we don't have buy-in from foundations yet
[15:45] <dandrader> 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] <mzanetti> let's call it staging
[15:45] <mzanetti> :D
[15:46] <Saviq> dandrader, long story short, we don't want that, not without automation running on those
[15:48] <Saviq> dandrader, we have a long-standing request in the CI team backlog for that, actually
[15:49] <Saviq> 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] <Saviq> so we need a target for the releases, which we'd like to be a PPA on top of vivid