Menu
▾
▴
Re: [Adobe-source-devel] ASL and menus
|
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 |
