Menu
▾
▴
adobe-source-devel
|
From: David C. <unc...@un...> - 2005-04-03 00:08:36
|
How much thought has gone into using ASL for creating and managing menus? It seems like a logical extension to the current work with dialogs. I really like the idea of using sheets to enable and disable menu items. My main question is, how would it handle changing the user focus? It seems like each focusable object would have a dictionary of values, and the sheet would be updated to point to the appropriate dictionary when the focus changes. But I haven't learned enough about Adam yet to take this idea much farther than that initial concept. Example: the enabled state of the Undo command would be tied to whether there is anything to undo, or more technically, if the size of the current focus' undo stack is greater than zero. This all reminds me a lot of Cocoa bindings. Is this coincidental, or were bindings an influence in the design of ASL? -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Ralph T. <ra...@gm...> - 2005-04-03 01:14:03
|
From an implementation perspective menus need to either: a) be tied to windows b) be tied to the application (or main window) On Windows there isn't much difference between the approaches (except that some kinds of windows should be given the menu), but on MacOS it would be bad to have the menubar change when switching focus between two windows in the same application. From a GUI usability perspective it's better to only have one drop-down menu in an application, so (b) seems like a good bet. We could add a "document" window type, and have it automatically get the menu defined for the application on Windows. On MacOS the application menu could show when there are no windows for that application (like with Grab). Ralph On Apr 2, 2005 4:08 PM, David Catmull <unc...@un...> wrote: > How much thought has gone into using ASL for creating and managing > menus? It seems like a logical extension to the current work with > dialogs. I really like the idea of using sheets to enable and disable > menu items. > > My main question is, how would it handle changing the user focus? It > seems like each focusable object would have a dictionary of values, and > the sheet would be updated to point to the appropriate dictionary when > the focus changes. But I haven't learned enough about Adam yet to take > this idea much farther than that initial concept. > > Example: the enabled state of the Undo command would be tied to whether > there is anything to undo, or more technically, if the size of the > current focus' undo stack is greater than zero. > > This all reminds me a lot of Cocoa bindings. Is this coincidental, or > were bindings an influence in the design of ASL? > > -- > David Catmull > unc...@un... > http://www.uncommonplace.com/ |
|
From: Foster T. B. <fbr...@ad...> - 2005-04-04 16:21:39
|
The menu system is something that is relatively unexplored in the Adam and Eve domain, but we believe there is a way to make things generic for menus so they do what you intend for them to do. We have distilled the concept of a menu (currently) into two different kinds: - a flag selector - a function selector The first is the kind of menu with a check next to the current selection, toggles, etc. They are switchable and, I believe, similar to the way checkboxes behave today. The similarity falls off when you talk about how to enable and disable the menu item, which we'll cover in the next section. Before we talk about the second kind of menu item we have to talk about the notion of an application and document state. Note that there are two states we're talking about here, and it is important to keep them separated. The document state is the current state of the document model-- this varies widely depending on the application you are creating. In Photoshop, for example, this could be the number of layers in the document, the number of channels in a layer, etc. The application state is the current state of the UI of the application. Again, this varies widely depending on the application you are making. In Photoshop, this might be the current brush, current selected layer(s), etc. I like to think of these as the state variables that have to be redefined every time the application restarts. Those that are persistent within the document contribute to the document state. Now the other kind of menu is the kind where you are going to select an operation, a function to be performed on the document model. These menu items are very dependent upon both the current document state and the current application state. The combination of the two is what we like to call the "subject", and as the subject changes over time the list of menu items enabled and disabled should be updated. For instance if there was a "sort layers" menu item, one would want it enabled if there were two or more layers in the document, if there were two or more layers selected in the document, etc. The point is that the subject determines the enabled state of the menu items. Following the allegory of the function for a menu item, every function has at least one parameter, and this first parameter is the required subject for the function. The question of whether or not a menu item is enabled is based on whether or not the current subject meets the criteria necessary to perform that function at that time. The subject requirement for a menu item could very easily be "no subject" (as in the case of New Document) or "a collection of things" (as in the case of our fictional "sort layers"), or a singleton (as in the case of "Gaussian Blur"). These functions, however, sometimes need more than one parameter. In the example of, say, Gaussian Blur, there is not only the current document needed but the radius of the blur to get from the user. Adam and Eve in their current form are introduced when the subject gets you part of the way towards completely defining the parameters of the function, but there are still more needed. Adam is a command parameter modeling engine, and helps the user identify the valid parameters they need to fill in the rest of the requirements for a function to be performed. When the dialog is complete, the application has a complete list of parameters (subject included) that it can use to perform the requested function. That's where Adam and Eve as a dialog management system currently come in to play. Genericity is introduced when you can specify the requirements for a function as well as a predicate defining whether or not a subject matches the requirements for that function. For instance, we are not interested in defining "sort layers" as much as we are interested in defining a "sort" function, with a set of preconditions and postconditions that must be met in order for something to be sortable. If the predicate asserts the subject "is_sortable", then the menu item should be enabled for that subject. When developing the application, then, you don't need to write a "sort" function ever again - you just make sure you make something sortable, and as the subject changes to include it the menu item will "magically" enable and you'll be able to sort it (layers, channels, whatever, as long as "is_sortable" is true). Ideally you want to get to the point where the menu items not only handle themselves, but they reveal to you functionality you didn't know you had. The vision is to one day open up a menu and say, "Hey, I didn't know I could perform XXX with YYY", and when you select that function it just does the right thing, because the requirements of XXX have been met by YYY. There is a lot left to think about here, and I am interested in opening up a dialogue (no pun intended) about the concept of menu systems. There are a lot of issues in the best way of defining the subject, as there is something to be said about a subject being a collection of subjects, and predicates needing to be tested on each individual part of the subject (including an individual part that is a collection of things). Let's talk about this stuff. A lot of this comes from conversations I've had with Sean about the issues, and I'm sure he could talk about it with better clarity. Blessings, Foster On Apr 2, 2005, at 05:13p, Ralph Thomas wrote: > From an implementation perspective menus need to either: > > a) be tied to windows > b) be tied to the application (or main window) > > On Windows there isn't much difference between the approaches (except > that some kinds of windows should be given the menu), but on MacOS it > would be bad to have the menubar change when switching focus between > two windows in the same application. From a GUI usability perspective > it's better to only have one drop-down menu in an application, so (b) > seems like a good bet. > > We could add a "document" window type, and have it automatically get > the menu defined for the application on Windows. On MacOS the > application menu could show when there are no windows for that > application (like with Grab). > > Ralph > > On Apr 2, 2005 4:08 PM, David Catmull <unc...@un...> > wrote: >> How much thought has gone into using ASL for creating and managing >> menus? It seems like a logical extension to the current work with >> dialogs. I really like the idea of using sheets to enable and disable >> menu items. >> >> My main question is, how would it handle changing the user focus? It >> seems like each focusable object would have a dictionary of values, >> and >> the sheet would be updated to point to the appropriate dictionary when >> the focus changes. But I haven't learned enough about Adam yet to take >> this idea much farther than that initial concept. >> >> Example: the enabled state of the Undo command would be tied to >> whether >> there is anything to undo, or more technically, if the size of the >> current focus' undo stack is greater than zero. >> >> This all reminds me a lot of Cocoa bindings. Is this coincidental, or >> were bindings an influence in the design of ASL? >> >> -- >> David Catmull >> unc...@un... >> http://www.uncommonplace.com/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > -- 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 |
|
From: David C. <unc...@un...> - 2005-04-04 17:46:41
|
On Apr 4, 2005, at 9:21 AM, Foster T. Brereton wrote: > The first is the kind of menu with a check next to the current > selection, toggles, etc. They are switchable and, I believe, similar > to the way checkboxes behave today. ...and radio buttons. > For instance, we are not interested in defining "sort layers" as much > as we are interested in defining a "sort" function, with a set of > preconditions and postconditions that must be met in order for > something to be sortable. If the predicate asserts the subject > "is_sortable", then the menu item should be enabled for that subject. > When developing the application, then, you don't need to write a > "sort" function ever again - you just make sure you make something > sortable, and as the subject changes to include it the menu item will > "magically" enable and you'll be able to sort it (layers, channels, > whatever, as long as "is_sortable" is true). This sounds just like what I've been thinking. So far I've been examining the concepts of clipboard commands (cut/copy/paste) and drag and drop, since I started by considering Cut and then thought about how you ideally want to have as much commonality between clipboard and drag-and-drop actions. 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. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Sean P. <sp...@ad...> - 2005-04-04 19:52:01
|
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 |
|
From: David C. <unc...@un...> - 2005-04-04 20:02:10
|
On Apr 4, 2005, at 12:51 PM, Sean Parent wrote: > command(name: "Cut", function: @cut, precondition: !empty(subject) && > mutable(subject)); The selection must also be copiable. For example, a CodeWarrior project group can be selected, dragged, and deleted, but not copied. It's debatable whether this should be so in this specific case, but there may be other cases where something is selectable but contains inherently contextual data that cannot be exported. Overall, I think it's pretty exciting that we're thinking along the same lines here. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Sean P. <sp...@ad...> - 2005-04-04 21:03:32
|
I had noted that I'm assuming all subjects already meet the requirements for a regular type <http://opensource.adobe.com/group__concept__regular__type.html>. There may be cases where this is too strong (although I really doubt it) - if we had a requirement that "Cut" implies something is available on the shared clipboard (Cut normally doesn't, it is fine to have internal only representations), then there would be some other requirement "convertible_to_export_format(subject)" or some such item. The behavior you describe in CodeWarrior I would consider a bug - at least I can't see a valid reason why a project group isn't a regular type. After I sent my previous note - I realized that Paste has an additional parameter which must be satisfied - namely that we have a valid source - !empty(source) And we probably also need to require that the source type can be converted to the destination type - convertible(source, value_type(subject)) There is a nice symmetry hidden here, paste and copy are the same function with the source/subject reversed (perhaps source is then a bad name... but I can't think of a better at the moment although "predicate noun" would be the obvious choice it would be a horribly confusing one): command(name: "Copy", function: @copy, precondition: !empty(subject) && mutable(source) && contiguous(source) && convertible(subject, value_type(source)); command(name: "Paste", function: @paste, precondition: !empty(source) && mutable(subject) && contiguous(subject) && convertible(source, value_type(subject)); This implies our clipboard (as the default source) - could be implemented as as std::vector<adobe::value_t> (or an adobe::array_t) with the source being the range [begin(clipboard), end(clipboard) ) . We could extract this predicate into a function: is_copyable(source, destination) { return !empty(source) && mutable(destination) && contiguous(destination) && convertible(source, value_type(destination)); } And our descriptions would become (I'll use prenoun instead of source). command(name: "Copy", function: copy(subject, prenoun), precondition: is_copyable(subject, prenoun)); command(name: "Paste", function: copy(prenoun, subject), precondition: is_copyable(prenoun, subject)); Hmmm... There has to be some literature related to this published someplace. Anyone have ideas on where to look? Sean On Apr 4, 2005, at 1:02 PM, David Catmull wrote: > On Apr 4, 2005, at 12:51 PM, Sean Parent wrote: >> command(name: "Cut", function: @cut, precondition: !empty(subject) && >> mutable(subject)); > > The selection must also be copiable. For example, a CodeWarrior > project group can be selected, dragged, and deleted, but not copied. > It's debatable whether this should be so in this specific case, but > there may be other cases where something is selectable but contains > inherently contextual data that cannot be exported. > > Overall, I think it's pretty exciting that we're thinking along the > same lines here. > > -- > David Catmull > unc...@un... > http://www.uncommonplace.com/ > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel |
|
From: David C. <unc...@un...> - 2005-04-05 15:57:05
|
On Apr 4, 2005, at 2:02 PM, Sean Parent wrote:
> This implies our clipboard (as the default source) - could be
> implemented as as std::vector<adobe::value_t> (or an adobe::array_t)
> with the source being the range [begin(clipboard), end(clipboard) ) .
How would you examine such a clipboard for compatibility? What are the
elements of the array?
> is_copyable(source, destination) { return !empty(source) &&
> mutable(destination) && contiguous(destination) && convertible(source,
> value_type(destination)); }
What does "contiguous" refer to in this context?
--
David Catmull
unc...@un...
http://www.uncommonplace.com/
|
|
From: Sean P. <sp...@ad...> - 2005-04-05 18:42:19
|
On Apr 5, 2005, at 8:56 AM, David Catmull wrote:
> On Apr 4, 2005, at 2:02 PM, Sean Parent wrote:
>> This implies our clipboard (as the default source) - could be
>> implemented as as std::vector<adobe::value_t> (or an adobe::array_t)
>> with the source being the range [begin(clipboard), end(clipboard) ) .
>
> How would you examine such a clipboard for compatibility? What are the
> elements of the array?
The elements of the array or vector are whatever was cut (an
adobe::value_t can hold any regular type) - I'm not sure what you mean
by "examine for compatibility" but you can retrieve the type of an
adobe::value_t using the value_t::type() member function.
>
>> is_copyable(source, destination) { return !empty(source) &&
>> mutable(destination) && contiguous(destination) &&
>> convertible(source, value_type(destination)); }
>
> What does "contiguous" refer to in this context?
A single range - inserting into multiple ranges would be disallowed
(mostly because I'm not sure what it would mean).
>
> --
> David Catmull
> unc...@un...
> http://www.uncommonplace.com/
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
|
|
From: David C. <unc...@un...> - 2005-04-05 19:10:54
|
On Apr 5, 2005, at 11:42 AM, Sean Parent wrote: > I'm not sure what you mean by "examine for compatibility" but you can > retrieve the type of an adobe::value_t using the value_t::type() > member function. The clipboard must be examined to determine if its contents are compatible with the subject and can be pasted. This array is, in effect, the wrapper around the platform clipboard interface, correct? -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: David C. <unc...@un...> - 2005-04-05 15:57:07
|
On Apr 4, 2005, at 12:51 PM, Sean Parent wrote:
> 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).
I thought of a few different types of selections and insertion points
as I was examining that idea. Again, I define "insertion point" as a
location for inserting data (pasted or dropped), and the "current"
insertion point is where pasted data would go.
Ranges
Mainly seen in text. A selection is a range, from a start index to
and end index. The distinction between selection and insertion point is
blurry or nonexistant. New content placed at the current insertion
point replaces the selection.
List
A list or collection of items. A selection is a subset of the
items. If the order of the items is determined by the user, then an
insertion point indicates a position between two elements. If the items
are sorted, then the insertion point indicates "somewhere" in the list,
to be determined when the new content is received. This could include
hierarchical lists too, where an insertion point would include a
reference to a parent item.
Arrangement
As in drawing applications like Illustrator: a collection of
objects in n-space (where n is usually 2). A selection is a set of
objects, and an insertion point is a location within the space. The
current insertion point is the center of the space or of the view, or
in some apps it can be center of the selection.
I think Photoshop fits in the Arrangement category, though its floating
selections are more complex, since they re-merge with the current layer
when deselected. I'm tempted to make a separate category for that.
--
David Catmull
unc...@un...
http://www.uncommonplace.com/
|
|
From: Foster T. B. <fbr...@ad...> - 2005-04-04 18:14:25
|
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 |
|
From: David C. <unc...@un...> - 2005-04-04 19:34:00
|
On Apr 4, 2005, at 11:14 AM, Foster T. Brereton wrote: > 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. > The "do_drop" function is given the current subject (the thing being > dropped on) and the parameters (mouse location, dropped data, etc). Why have separate paste and drop functions? That was the point of my insertion point concept. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Ralph T. <ra...@gm...> - 2005-04-04 20:00:10
|
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 |
|
From: Foster T. B. <fbr...@ad...> - 2005-04-04 20:49:45
|
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 |
|
From: Sean P. <sp...@ad...> - 2005-04-05 18:39:24
|
On Apr 5, 2005, at 8:56 AM, David Catmull wrote: > On Apr 4, 2005, at 12:51 PM, Sean Parent wrote: >> 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). > > I thought of a few different types of selections and insertion points > as I was examining that idea. Again, I define "insertion point" as a > location for inserting data (pasted or dropped), and the "current" > insertion point is where pasted data would go. > > Ranges > Mainly seen in text. A selection is a range, from a start index to > and end index. The distinction between selection and insertion point > is blurry or nonexistant. New content placed at the current insertion > point replaces the selection. Ranges come up in many places - a selection in a scrolling list. This is why I proposed the notion of a collection - which would be a list of ranges, an insertion point is simply a collection comprised of a single empty range. A contiguous collection is a single range (empty or non-empty) which can also serve as an "insertion point" for operations which do a replace. > > List > A list or collection of items. A selection is a subset of the > items. If the order of the items is determined by the user, then an > insertion point indicates a position between two elements. If the > items are sorted, then the insertion point indicates "somewhere" in > the list, to be determined when the new content is received. This > could include hierarchical lists too, where an insertion point would > include a reference to a parent item. You can have a range within a hierarchy also (see the adobe::forest<> container). > > Arrangement > As in drawing applications like Illustrator: a collection of > objects in n-space (where n is usually 2). A selection is a set of > objects, and an insertion point is a location within the space. The > current insertion point is the center of the space or of the view, or > in some apps it can be center of the selection. I don't see a need for this yet - in Illustrator a collection of n objects is not denoted geometrically, rather by a collection within the art tree (using collection here as a defined it above). An "insertion point" is a location in the art tree and an x,y coordinate which is also part of the subject and applied to the new items. I'm not sure that this implies a transformation on inserted objects, or simply that new nodes in the tree pick up a default x,y location (artwork outside the tree only has relative positions). > > I think Photoshop fits in the Arrangement category, though its > floating selections are more complex, since they re-merge with the > current layer when deselected. I'm tempted to make a separate category > for that. Photoshop is actually simpler (and similar) - the "selection" in Photoshop is not a selection as denoted here - it is itself a channel which is part of the subject. > > -- > David Catmull > unc...@un... > http://www.uncommonplace.com/ > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel |
|
From: Sean P. <sp...@ad...> - 2005-04-05 20:02:26
|
On Apr 5, 2005, at 12:10 PM, David Catmull wrote: > On Apr 5, 2005, at 11:42 AM, Sean Parent wrote: >> I'm not sure what you mean by "examine for compatibility" but you can >> retrieve the type of an adobe::value_t using the value_t::type() >> member function. > > The clipboard must be examined to determine if its contents are > compatible with the subject and can be pasted. This array is, in > effect, the wrapper around the platform clipboard interface, correct? The connection with the platform clipboard interface (which probably has some set of interchange types and promises) would be handled by feeding that data into (and out from) the internal array. Not everything in the internal array could be fed to the platform clipboard "compatibility" for paste would be handled by our previously mentioned "is_convertible" function. The question is, is the contents of the clipboard convertible to the value type of the destination. This could be handled in the same way that value_t currently handles promotion of type - but would allow for lossy conversions (handling paths through the conversion process would be interesting but I don't think necessary as all the data types are known). Sean > > -- > David Catmull > unc...@un... > http://www.uncommonplace.com/ > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X