Re: [IndieUI Events] added UIZoomRequestEvent

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.

> 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.

> 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)?

> 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
>> 
>> 
>> 
> 
>