Spec, section 3.3.2

[Brian T Rice]

On Sun, 20 Apr 2003, David Hilvert wrote:

> In section 3.3.2, under the description of 'Command', the meaning of the
> phrase 'interaction context' is not immediately obvious.

Hrm. Yes, that is unclear, and I may have wrongly referred to the formal
TUNES Context term, which is supposed to refer to a TUNES language
evaluator plus its state (a very rough description).

First, "event" should most likely read "Gesture", since I renamed that
term. But more to the point, the perspective I have in mind there is that
Commands are parsed from input according in a late-bound kind of way...
that is, gestures are channelled in to the currently active region and
whatever semantics it supports into some object which represents some
domain action relevant at the time and place.

This arose from a paper I read that covered some research done for Garnet
I believe, titling their system UIMS. I can't seem to find the paper on a
cursory search, though. Anyway, mouse gestures and keyboard gestures would
be subject to a regular-expression style matcher, which would collect them
into a recursive structure that had some relevant semantic meaning. For
example, the click-and-drag concept could be captured from:

<pointer-down x,y><pointer-move>*<pointer-up z,w>

all the gestures would have their normal information required to describe
what happened like in any modern GUI event system. But once parsed, there
would be one object remaining:

<click-drag x,y z,w>

describing the whole sequence as a larger action. Until a full expression
were satisfied, the handler could produce a set of possible matches and
choose some default to match for. The lower-level events could still be
retained if this made sense, but there's also the possibility of matching
the matches themselves against higher-order patterns, like a single
pattern for click-drag against move-file, copy-file, or link-file
non-deterministically (I know I'm picking a horrible low-level example,
but it's one everyone knows) when in the context of a file shell.

<move-file foo.bar path1 path2>

The more interesting idea is that whatever handles the events can react
differently in a structured way and build up meaningful things:
text-editing commands for a text system, program-editing commands (even
refactorings) for a programming system (even if it's built on top of a
text system), or game-playing commands for a game. The intent of the
research was to automate collection of "undo" information and to keep the
undo level rather high without excessive programming effort. It also
provides a high-level programming-by-example capability through redo's.

I am indeed working this into the Slate interface system, based on CLIM
whose architecture does support this idea, but no CLIM system really does
it. However, they have input contexts with their own parsers; it's just
more ad hoc. I've been delaying the explanation of the Slate GUI until
it's running and I can just demo it for people and show them the running
code.

I suppose if the gesture-collector can be considered a mini TUNES language
(which object-regex's count as), then the Context term reference counts.
What do you think?

-- 
Brian T. Rice
LOGOS Research and Development
mailto:water@tunes.org
http://tunes.org/~water/