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

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

Here are my thoughts:

The buddy list is the document, and the document model specifies buddy 
groups and buddies and the containment hierarchy therein. The problem 
comes when it's time to represent the document model visually, as we 
would need some sort of list box widget. The semantics of that list box 
widget is where the real challenge comes, and would be a good problem 
to explore. My guess is one would start with a list_box_t that has some 
sort of item_t inside of it with a collection of callbacks for various 
operations on a specific list item (selection, double click, etc). Some 
operations (like dragging around inside the list) might be something 
handled internally within the list, but notification would still have 
to be send to a callback.

Right now Adam is used to manage the validity of parameters going to a 
command. The use you have outlined below is a little different, as 
you're talking about managing the state of the document model during 
the execution of the application. I'm not quite sure how Adam in its 
current state would handle this... according to what you have below 
you'd be dynamically adding and removing cells to represent various 
aspects of a buddy in the buddy list-- tricky. Currently I don't think 
it's possible to remove cells from a sheet at runtime.

So I think there's a distinction that needs to be made between Adam 
managing the modeling of command parameters and Adam managing the 
entire document and application state. I think of Adam as being more 
"short term" use. Having an Adam-like system for managing a document 
model is something we've spent a little time talking about, but think 
it will be a different problem that the kind Adam is built to solve.

Blessings,
Foster

On Apr 4, 2005, at 01:00p, Ralph Thomas wrote:

> On Apr 4, 2005 11:14 AM, Foster T. Brereton <fbr...@ad...> wrote:
>> 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?
>
> I have some questions (more than thoughts ;-)). Perhaps if we answer
> them then we'll have a better understanding of what we need to make.
>
>  1. How should I think of data in the GUI?
>  2. How do I push updates to data in the GUI?
>
> As an example, think of a buddy list in an instant messaging program.
> The list of buddies is known some time after the application starts,
> and is always subject to change. In order to determine which menu
> items should be available attributes of the currently selected buddy
> need to be known to Adam. The buddy is a data model, and so is the
> list of buddies (we can define a data model simply as something with
> properties to bind).
>
> You could write a single model as a special entry in an Eve file (like
> a non-visible widget), and then bind it's properties to cells in the
> Adam sheet. This isn't straightforward (to me!) for accessing data
> model properties which are arrays of other data models.
>
> I imagine that once there's a way of representing/reflecting data into
> the GUI domain it will be easy to update it.
>
> Thanks,
>  Ralph

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