Re: [Adobe-source-devel] ASL and menus

[Sean P. <sp...@ad...>]

On Apr 4, 2005, at 10:46 AM, David Catmull wrote:

> To merge the two, I hit on an abstracted insertion point concept, 
> which defines where new data (pasted or dropped) will go. For paste, 
> the UI widget is told "get me your current insertion point; insert 
> this data at that point". For a drop, "get an insertion point for this 
> mouse location; insert this data at that point". The insertion point 
> would be an opaque data type that only the widget needs to understand. 
> It might not even be specific - in a sorted list, for example, the 
> final location depends on the actual data, so the insertion point 
> would just vaguely indicate "in the list" for all cases.


This is the direction I'd like to see it going. I always find it useful 
to think in terms of how would these things be expressed (this is why 
Adam/Eve2 have their own language, I just find it simpler to use a 
language as a notation for thinking)...

My basic thought is that the application has a "subject" - the 
application state that Foster was referring to. Each function in the 
application has a set of pre-conditions, when satisfied, the function 
is enabled. One important characteristic is that satisfying the 
preconditions shouldn't be entangled in the subject itself (that is - a 
subject shouldn't be "undoable" - it can be undone if it satisfying the 
preconditions of undo).

I'm still struggling with how to fully represent a subject but I do 
know that it needs to be able to represent collections within a 
container as well as ranges (perhaps a collection is represented as a 
list of ranges to merge the two concepts). It will also have a 
hierarchical component most likely mirroring the document structure... 
But let's say we have such a subject, it becomes useful to think about 
how we would describe the preconditions for a function (and you are 
correct, that we should be able to reuse these preconditions, not just 
for menus but for drag/drop and possibly for Adam - which is also 
modeling and validating pre-conditions).

I believe it is safe to assume that all subjects match the concept of a 
regular type.

command(name: "Cut", function: @cut, precondition: !empty(subject) && 
mutable(subject));
command(name: "Copy", function: @copy, precondition: !empty(subject));
command(name: "Paste", function: @paste, precondition: mutable(subject) 
&& contiguous(subject)); // a contiguous subject is a single range
command(name: "Undo", function: @undo, precondition: current(subject) 
!= begin(history(subject)));

Hopefully this helps to describe what I'm looking for. For the "drop" 
example, we find that it is exactly the same as paste, except our 
subject is being provided by our drop location, rather than our 
application state.

Sean