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

[Foster T. B. <fbr...@ad...>]

Interesting... I think it's possible to abstract this one layer 
further. As I said earlier, I like to think of application state as the 
parameters of the application that need to be redefined when the 
application restarts. In this case, the location of the insertion point 
is part of the application state. The insertion point, then, is part of 
the subject that is constantly changing.

For Paste, the subject would have to include an insertion point that 
the "can_paste" predicate would find to be valid. When valid, paste is 
enabled. When selected, "do_paste" is given the current subject (or the 
part of the subject that it validated with its predicate) and the 
clipboard, and does the right thing.

In a drag-and-drop operation, the subject constantly changing as the 
data moves around the document. The predicate called "can_drop" is 
called every time the subject changes, and when the user raises the 
mouse button that is the equivalent of "selecting" the drop function. 
The "do_drop" function is given the current subject (the thing being 
dropped on) and the parameters (mouse location, dropped data, etc).

In both cases, then, we have a subject that the application is changing 
and passing to the validation predicates; the validation predicates are 
returning to the application whether or not the function it represents 
is valid given the current subject. The application then reflects to 
the user these results with UI element changes (enable/disable of menu 
items, cursor changes, etc). When the user "selects" a function (which 
we know to be valid, by the way, because of the predicate operations) 
the application simply signals that function with the subject 
information present.

One thing to note in this pipeline is the "pushing" of information. The 
data is never "fetched" in the sense that a function has to reach 
outside its domain to get at information it needs. The application 
pushes the subject to the predicate; the predicate pushes the result 
back to the application; the app pushes UI updates to the client; the 
client pushes the selection of a command to the application; the app 
pushes the current subject to the selected function operation. The 
reason this is important is because we want our application system to 
model a directed acyclic graph (DAG). Adam and Eve are founded on the 
principle that application software, for the most part, is an attempt 
at describing a system as a DAG. Unfortunately current OOP techniques 
don't enforce this very well, and code can easily become hard to keep 
all in your head at once. By "DAGing" at the foundational level, we 
keep the system maintained in a way that it is easy to get our heads 
wrapped around a given component. You can see this in the ASL already, 
as the only "get" function in the entire codebase (I believe) is in 
value_t.

Thoughts?

Blessings,
Foster

On Apr 4, 2005, at 10:46a, 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.

--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov