input proposal talk
since github comment threads are clearly untrackable, i'll add some thoughts here:
Mdo we need to establish the Deadzone concept here?
M^ that can be a part of the Axis proposal
Mif is raised two consecutive times with set to true within milliseconds, and the 's or did not change more than
probably out of scope, but this seems like a prime case for DPI awareness
Min response to our github discussion:
that being said, im ok with leaving it as is - I'd say we've already done more than the vast majority of pointer implementations and should feel happy with it.
but there is room for improvement / greater composability. since i dont have any terribly concrete recommendations for that (given that im still working on the axis proposal), perhaps it's best to shelve the conversation for silk 4. and maybe I rename the axis proposal to the Input Composability Proposal or whatevr
...Ultimately a logical device (which I guess we should define as a single physical pointer input mode with which a single user can input one or more points), regardless of the number of points that device is reporting to the software, will always have one button state per capture...it seems to me like defining a logical device in terms of physical is an unnecessary limitation - one that is common for good reason, but i think it could be stretched further. the current abstraction is pretty damn good already, but maybe an isn't a device, but rather the output of an (a mouse, touch screen, tablet pen), which could provide any number of points at any time as an expectation, which can live and die at will, have unique runtime IDs, etc, and can have button state themselves (e.g. their click pressure, "grip", or sub-points in the case of gestures or point-cluster-based input systems). This could remove the need for intermediary data structures like
that being said, im ok with leaving it as is - I'd say we've already done more than the vast majority of pointer implementations and should feel happy with it.
but there is room for improvement / greater composability. since i dont have any terribly concrete recommendations for that (given that im still working on the axis proposal), perhaps it's best to shelve the conversation for silk 4. and maybe I rename the axis proposal to the Input Composability Proposal or whatevr
Msome of my concerns about pointers may not have anything to do with pointers at all - i think it's more to do with the layer, which is also quite thoroughly thought out already and doesn't need any revisions at this point
Mi think i will take my ill-defined concerns into my own proposal and see what i can do with them
Mspeaking of runtime ids, I do think that individual s should contain a unique ID and individual pressure values
Pthey already contain pressure values in TargetPoint
Pas for unique IDs, I’m not sure this is something we can guarantee to get from all backends
Pwe just have to trust that the indices line up for the same touch
PI don’t want to break the world twice without good reason, if there’s something we want to do now we should do it now. Can you whip up an API?
Pnot yet, I did think about it. If anywhere we should do it at the InputContext level given that this is all silk logic, our backends don’t do deadzones for us. Not sure of an API for that though, the single float API was pretty limiting I felt.
Mill do my darnedest - do you need it today or can i cook a bit?
Mthats cool with me, im happy to include it in the "high level" part of my Axis proposal - i was thinking of having a more detailed deadzone description anyway
Pprobably don't need it today, no.
Myeah i agree we can't guarantee to get it, but in the case that it's not natively supported we can provide a default "persistence" implementation i'd be happy to write
Mok - ill try to wrap things up today bc this has been a bit of a Text Hell we've found ourselves in, but certainly no promises
Pyeah no worries. and for the axis stuff, while that's not a target for 3.0 initial release, it'll be good to propose it at the same meeting so we definitely know the base API is sufficiently extensible
Myeah agreed. personally i want to do my best to do both in parallel insofar as there is time for the sake of extensibility and creating intuitive API patterns, etc
Pah yeah absolutely
Mgrinding on this today, i have some Big Ideas im trying to prove out that should hopefully simplify things on both ends of the developer experience
Mwe'll see if that pans out or i strip it back
Mis it ok if the proposal comes with some form of implementation for certain things?
Mcould just be an example that is instead replaced with a spec
PIdeally the document doesn’t contain implementations as these make it harder to review. Usage examples are okay though.
Mok!