← Back to team overview

multi-touch-dev team mailing list archive

Re: GISpL: a (very rough) gesture language specification

 

Hi Florian,

> On Fri, 2011-03-04 at 20:43 +0100, Henrik Rydberg wrote:
> > This looks very interesting indeed! And timely too, as there should be
> > ample opportunity to test these ideas out in the coming six
> > months. Here are some comments and further ideas:
> > Regions - there may also be a need to specify the reverse - areas
> > where gestures are not recognized. Typical example would be a canvas
> > with icons on it.
> If I understand your example correctly, this can already be represented
> by layering smaller regions (for the icons) containing no gestures on
> top of the larger canvas region. Regions are managed as an ordered list;
> I'll clarify that in the spec.

Sounds good, thanks.
 
> > Features - I suppose those are restricted to temporal changes, in
> > addition to static features of the contact set. I take it you mean to
> > specify this set further, based on 2D and/or 3D projections?
> Yes, correct; I have about 10 different features implemented right now
> which can be fine-tuned using constraint values.

Ok, goodie.
 
> > Gesture - I have found it useful to organize gestures into
> > hierarchies, such that some gestures may hold or cancel other
> > gestures. A way to specify such relations in the language might be
> > useful.
> I was mostly thinking about putting such behaviors directly into the
> application - I'll think about how this might be represented.

The arbitration can become quite complex, and the problem seems to
exist on several levels; between gesture and touch events, between
different gesture types, pointer emulation, etc.

> > And there is the question of state. Part of the ideas floating around
> > here are based on gestural modifications of a state. Understanding and
> > specifying the rules for state transitions might be very powerful in
> > practise.
> Do you mean state in the formal sense of a deterministic finite
> automaton?

What I had in mind was basically anything that affects the meaning of
what happens on the device - anything from locking into a certain
gesture, like rotation, to traversing a menu hierachy, to selecting or
cancelling something, etc. Some of these things are arguably as
complex as the program itself, but with a language comes the benefit
of clarity of thought.

Hope this helps, and thanks again for looking into this!

Henrik



References