Re: [IndieUI Events] added UIZoomRequestEvent

On Wed, Nov 14, 2012 at 1:18 PM, James Craig <jcraig@apple.com> wrote:

>
> On Nov 14, 2012, at 11:53 AM, Rick Byers <rbyers@google.com> wrote:
>
> Thanks James.
> Are you coupling adding 'scale' to adding 'start/change/end' because the
> desired semantics would be 'scale change since start'?
>
>
> That was the thought, yes. It seems more manageable from a development
> standpoint. e.g., Use hardware-accelerated scale/position transforms during
> the operation, then set the element's determined size once the operation
> was completed.
>

I agree that's probably more convenient for applications, but I'm not sure
it's a big difference in practice (trivial to have 'absScale *=
event.scale').

Another avenue to look at this from is the scenario where an application
starts receiving a zoom or pan halfway through the user action causing a
sequence of events (eg. due to the DOM changing during an action).  Does
the app want the ability to say 'I missed the start of this sequence, I'll
ignore all these events' vs. 'I missed the start, but I can pick up here as
if I had been listening all along change'?  Or is it OK for that scenario
to be indistinguishable from an action that just started?  Personally I'm
having a hard time imagining an application scenario where the extra
complexity provides value - but maybe someone smarter than me can come up
with a good use case?

Also, is there any reason for pan and zoom to be inconsistent here?  I.e.
if scale is absolute, then the pan X/Y values should be absolute from the
start of the pan operation (instead of deltas from the last operation).

If we go with start/move/end then we need to address the targetting issue.
 Can the element being targeted by the event stream change between start
and end?  The default assumption is yes, but then we might need 'over' and
'out' events (as for mouse events).  Touch events on the other hand always
target the element where the touch 'started' (a mistake IMHO - causes some
problems).  Pointer events have a nice hybrid of defaulting to the mouse
event behavior but having a 'setCapture' API (with got/lost capture events)
to allow the API to get the alternate behavior if desired.  If we have no
start/end events then we avoid this complexity entirely.

> If instead the semantics of 'scale' were 'incremental scale change from
> last event' then perhaps we can separate it from the question of
> start/change/end?
>
>
> When used with UI interfaces allowing continuous input, this seems like
> floating point math and performance could become pain points. Imagine
> getting a series of hundreds or thousands of discrete zoomrequest events,
> each with a scale factor of something like 1.00000000000000734 or
> 0.9999999999999999993628.
>

That was my first thought too, but I'm not convinced it would be a problem
in practice.  Eg., I have a hard time imaging any reasonable input
technology that would let me scale something with precision finer than
0.1%.  So we're probably talking more like 1.007 and 0.994.  Right?

> Whether or not we need start/change/end for scale and pan is also a great
> question.  It's certainly strictly more powerful, but I'm not sure how much
> value it adds in practice.  One disadvantage of splitting it out is that I
> wouldn't be surprised to find apps have bugs in scenarios where they are
> intermixed (eg. panstart, zoomstart, zoomchange, zoomend, panchange,
> zoomstart, etc...).
>
>
> Good point. Do you think we should we consider combining them into an
> single set with deltaX, deltaY, scaleFactor (hmm… and rotation)?
>

That's certainly one reasonable option, especially from a
touchscreen-centric view.  I'm having trouble justifying it from a
modality-independent perspective though.

One interesting case to consider for both these questions is how multiple
> simultaneous input modalities should be handled. But perhaps that's unusual
> enough that we don't need to worry too much about it (eg. it seems almost
> certainly overkill to have a mechanism to support multiple pending pan/zoom
> operations - i.e. with some source identifier to correlate change events
> with a specific start event).
>
> Thanks,
>    Rick
>
>
>
> On Tue, Nov 13, 2012 at 4:21 PM, James Craig <jcraig@apple.com> wrote:
>
>> As noted in the working group charter, gestures and discussion of what
>> they represent are explicitly listed as out-of-scope. Please try to phrase
>> your requests or suggestions in a way that can be inferred as independent
>> from a particular modality or user interface paradigm.
>>
>> I think the core of your request for a scale value is legitimate, but I
>> don't think that would work well with the current 'discrete' events
>> architecture, which is why I added this editorial note:
>>
>> This may need to be split into zoomstartrequest, zoomchangerequest, and
>> zoomendrequest events.
>>
>> I've just updated the note to mention the possible addition of a scale
>> attribute:
>>
>> This may need to be split into zoomstartrequest, zoomchangerequest, and
>> zoomendrequest events, with an optional scale attribute.
>>
>>
>>
>> On Nov 13, 2012, at 2:13 PM, Rick Byers <rbyers@google.com> wrote:
>>
>> Great!
>> To be able to use UIZoomRequestEvent from touch screen pinch gestures,
>> we'd need a floating-point 'scale' value (pinch is only useful if the app
>> can match the expansion to the finger movement).
>>
>> Rick
>>
>>
>>
>>
>> On Sun, Nov 11, 2012 at 10:43 PM, James Craig <jcraig@apple.com> wrote:
>>
>>> Added UIZoomRequestEvent
>>>
>>> changeset
>>> https://dvcs.w3.org/hg/IndieUI/rev/d98997ee66c7
>>>
>>> Latest:
>>>
>>> https://dvcs.w3.org/hg/IndieUI/raw-file/tip/src/indie-ui-events.html#UIZoomRequestEvent
>>>
>>>
>>>
>>
>>
>
>