[10:29] <Saviq> mzanetti, welcome back, FYI http://bazaar.launchpad.net/~robru/phablet-tools/further-fixes/view/head:/citrain is a useful-again version of the script
[10:30] <Saviq> actually it's been released to the overlay already I think
[10:49] <mzanetti> Saviq, hey ho. thanks
[11:01] <Guest42341> mzanetti, omg kodimote is great! :D the only think that doesn't work for me is the http password
[11:01] <mzanetti> Guest42341, glad you like it. will look into the password stuff. It should work, but I haven't used that in a while
[11:02] <Guest42341> mzanetti, i love it! :D i works great with my laziness +1
[17:19] <robru> Saviq: mzanetti should be in overlay ppa and phablet tools ppa, and  SDK ppa
[17:23] <mzanetti> robru, ?
[17:24] <mzanetti> you mean the new citrain tool?
[17:24] <robru> Yeah
[17:28] <mterry> mzanetti, let's say I'm writing qml, and I wanted to watch input events happen on my widget but still "fall through" to lower layers.  Is that easy?
[17:57] <Saviq> mterry, sure, .accepted = false
[17:58] <Saviq> mterry, http://doc.qt.io/qt-5/qml-qtquick-mouseevent.html#accepted-prop
[17:58] <mterry> Saviq, in my case I want to "monitor" the progress of a drag -- which would be complicated if I !accept the initial events, right?
[17:59] <Saviq> mterry, not sure, but indeed you might not get subsequent events when a drag is in progress
[17:59] <mterry> humph
[18:00] <Saviq> mterry, or at least, you'll need to decide whether it's a drag yourself
[18:07] <Saviq> mterry, just tested with http://paste.ubuntu.com/12864305/, a drag grabs the mouse indeed
[18:08] <mterry> Saviq, yeah figured.  Thanks for actually testing  :)
[18:08] <mterry> That makes some tutorial-redesign tricks harder
[18:08] <Saviq> mterry, http://doc.qt.io/qt-5/qml-qtquick-mousearea.html#propagateComposedEvents-prop *could* help, if drag is treated like a propagated event, but not sure
[18:08] <Saviq> mterry, what's your use case?
[18:12] <mterry> Saviq, trying to monitor the bottom-edge drag in an app so that we can fade out / hide the tutorial screen as it goes up / finishes
[18:13] <mterry> Saviq, so I'd like the app to get the drag, so it can show the bottom edge screen.  And I'd like us to watch it to fade on our side (we'd only do this for a known set of apps, so we know that the app isn't doing anything weird on its side)
[18:14] <mterry> Saviq, otherwise we'd need to have the app communicate to us where it's at with the drag.  Which is a complexity I'd *like* to avoid
[18:14] <mterry> Since it would need to be per-app (PageWithBottomEdge still isn't in sdk)
[18:16] <Saviq> mterry, oh that's not a drag even
[18:16] <Saviq> mterry, DDA handles that, all touch-based
[18:17] <mterry> DirecationalDRAGArea, right?   :)
[18:17] <Saviq> sure, not a MouseArea.drag I meant
[18:17] <Saviq> but still, likely that the touch is grabbed when it determines it wants it
[18:17] <mterry> Saviq, right.  Does that change anything?  I thought the same accepted=false stuff happened for touch too?
[18:17] <Saviq> dandrader|afk will know (obviously)
[18:20] <mterry> Will bug him tomorrow, thanks  :)
[18:20] <mterry> Maybe there's a way to fake it
[18:23] <Saviq> mterry, FWIW all touch events will go through the shell, regardless of whether they're sent to the app or not
[18:23] <Saviq> mterry, so maybe we need a monitoring-version of DDA, doubt it would be difficult to add
[18:26] <mterry> Saviq, because the shell is the Mir parent of the app?  that's good
[18:26] <Saviq> mterry, shell decides what input goes where, tes
[18:26] <Saviq> yes, even
[18:26] <mterry> :)
[18:27] <Saviq> that's how we can do DDA in the first place, and still pass input to apps on the edges
[18:33] <dandrader> Saviq, what?
[18:33] <Saviq> mterry, FWIW, that approach will obviously only work if the app did not modify the bottom DDA settings
[18:34] <Saviq> dandrader, long story short, we need to have a tutorial for the bottom edge that's triggered by an app that you launch, one that does have a bottom edge implemented
[18:35] <Saviq> dandrader, that tut is only supposed to be an overlay, while the app in question actually works as it would normally
[18:35] <Saviq> dandrader, so mterry was thinking to have a DDA on the bottom edge that would not accept any events, just monitor them
[18:35] <dandrader> if it's about monitoring touch input without disturbing the input dispatching that QQuickWindow does, TouchRegistry is what you want
[18:35] <dandrader> mterry, ^
[18:36] <Saviq> dandrader, well, sure, but he'd have to reimplement DDA's behaviour
[18:36] <dandrader> mterry, TouchRegistry::addTouchWatcher()
[18:36] <mterry> hmph, my irc isn't notifiying me of highlights right now
[18:36] <Saviq> dandrader, thought it would be easier to add a monitoring-only mode to DDA
[18:36]  * mterry reads back
[18:36] <Saviq> that being said
[18:37] <dandrader> Saviq, no, let's not make DDA a do-it-all frankenstein suffering from featuritus
[18:37] <Saviq> dandrader, well, better than just copying code
[18:38] <dandrader> Saviq, Have an item that takes touch input but rejects them and call TouchRegistry::addTouchWatcher() instead
[18:38] <dandrader> Saviq, mterry, it's not much code to do that
[18:38] <Saviq> dandrader, that still means you need to replicate what DDA is doing
[18:38] <Saviq> aaanyway
[18:38] <dandrader> Saviq, a quite small part
[18:39] <mterry> dandrader, I can take a look at that and see how bad it would be for me
[18:39] <mterry> dandrader, will poke if I have questions
[18:39] <Saviq> still less copypasta to just add a mode to DDA
[18:39] <Saviq> butt! I'm not really happy with that approach anyway, feels like it's gonna break a lot
[18:39] <mterry> Saviq, the general tutorial approach?
[18:39] <Saviq> mterry, for the bottom edge, yes
[18:40] <dandrader> Saviq, An item that simply monitors input coming through is not a DirectionalDragArea anymore
[18:40] <mterry> Saviq, yeah...  I pushed back a bit, but they were firm.  But the design just changed (was on contract), so I'll have another go on Wednesday
[18:40] <dandrader> Saviq, is something else
[18:40] <Saviq> dandrader, we can rename it ;)
[18:40] <mterry> Saviq, we are only going to do this for a few well-known apps that will behave well (we hope)
[18:40] <Saviq> mterry, I rather meant how we want to achieve the design
[18:40] <dandrader> Saviq, YourOneStopForTouchStuffItem
[18:41] <Saviq> dandrader, I disagree, but let's not dwell on it
[18:41] <mterry> dandrader, well to be fair, it's still acting like a directionaldragarea, just one that doesn't grab input right?
[18:42] <dandrader> Saviq, besides monitoring, does it also has to tell whether the touch point is performing a directional drag?
[18:42] <Saviq> dandrader, yes
[18:42] <mterry> Saviq, monitoring input seems like it should be fine to me (as a way to implement design)
[18:42] <dandrader> Saviq, ahhh, ok. now it's different...
[18:42] <Saviq> we didn't explain well, sry
[18:42] <Saviq> dandrader, we'd want everything DDA does, except for grabbing the input
[18:43] <dandrader> Saviq, ok
[18:43] <mterry> dandrader, (we basically want to pretend we know what's going on with a DDA in an app)
[18:43] <Saviq> mterry, especially because we're only looking at a few white-listed apps, could we not rely on the app reporting the bottom edge progress for us instead?
[18:43] <dandrader> mterry, it will only work if the app is also using a DDA and that DDA is using the same recognition parameters
[18:44] <Saviq> yeah, exactly
[18:44] <mterry> Saviq, oh we could for sure...  But that seemed worse than monitoring to me.  We'd need to patch like 6 apps to report over... dbus?  to the shell.  Felt easier to just monitor
[18:44] <dandrader> Saviq, mterry, and you still run the risk of getting it wrong if the timing is not the same
[18:44] <mterry> dandrader, Saviq: I suspect the apps we're talking about are all using copies of PageWithBottomEdge somewhere...
[18:45] <mterry> I haven't done a survey
[18:45] <mterry> Haven't nailed down the app list with Design yet
[18:46] <dandrader> mterry, this PageWithBottomEdge thing is from ui toolkit?
[18:47] <mterry> dandrader, not official part of the SDK yet.  Just a class that gets copied around a lot
[18:47] <mterry> dandrader, like libegg if you know GNOME stuff
[18:47] <dandrader> mterry, Saviq couldn't we make this bottom edge tutorial a component that those apps use?
[18:47] <Saviq> dandrader, we ~can't, since it's meant to cover indicators as well (and stop other edges)
[18:47] <mterry> dandrader, the tutorial needs to cover the screen (including main / side stages).  So bigger than the app
[18:48] <Saviq> mterry, well, we were to put DDA in the SDK for a while now
[18:48] <dandrader> right
[18:48] <mterry> dandrader, though Design wants to offer the component to apps to use for in-app tutorials too
[18:48] <Saviq> mterry, so that should be the goal IMO
[18:48] <mterry> Saviq, yeah...  for future stuff.  But doesn't help the shell with our redesign of the tutorial now
[18:48] <Saviq> mterry, right
[18:49] <dandrader> mterry, Saviq, well, the app could tell unity8 it's in tutorial mode or something so that unity8 does its part....
[18:49] <Saviq> dandrader, yeah, that'd be a long-term goal, but would require the "thing" that's driving it to be constant (i.e. part of SDK, which is unlikely to happen in the short term)
[18:50] <mterry> Eh.  Not sure that's any prettier than apps telling us about bottom drag
[18:50] <dandrader> Saviq, oh, so we're talking about a quick hack then
[18:50] <mterry> Especially since the strings and all that should live in one place
[18:50] <mterry> dandrader, Saviq: no....  this is not a quick hack
[18:50] <Saviq> just a temporary solution
[18:50] <Saviq> until we arrive in a better world
[18:50] <mterry> long term goal of apps having their own tutorials is separate from the shell tutorial
[18:50] <mterry> Saviq, no not even temporary
[18:50] <dandrader> mterry, right, apps telling us the bottom drag status would be better than this last idea of mine...
[18:50] <mterry> I think there's some miscommunication
[18:50] <Saviq> mterry, I meant just the bottom edge
[18:51] <Saviq> mterry, not in-app tutorial
[18:51] <mterry> Saviq, I still would want that in shell
[18:51] <Saviq> mterry, yes, but the noop-mode of DDA
[18:51] <Saviq> mterry, if we put DDA in SDK and instrument it
[18:51] <Saviq> mterry, that'd be more reliable than an overlay noop DDA IMO
[18:52] <mterry> Saviq, oh...  why would that be a temporary change?  regardless of where DDA lives, we'd want it to act like a no-op in this montoring case
[18:52] <mterry> Saviq, although if DDA were in SDK we'd guarantee same behavior as the app...
[18:52] <Saviq> mterry, I meant there would be no DDA in the shell on the bottom edge
[18:52] <Saviq> mterry, if DDA from SDK would report progress on $IPC
[18:53] <mterry> Saviq, oh oh, you're talking about that approach.  Sure we could do that over DBus or whatnot.  We could do that today by patching apps
[18:53] <Saviq> but yeah, OTOH as you said, 6 core apps should probably *not* change the DDA parameters from the defaults
[18:53] <mterry> Saviq, you really think monitoring will be flaky?
[18:54] <mterry> I probably need to survey the apps and see what their drag code looks like
[18:54] <Saviq> mterry, no, just feels really weird ;)
[18:54] <mterry> Saviq, I was surprised to see that SDK 1.3 added BottomEdgeHint but not PageWithBottomEdge.  Felt like a weird half stp