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

[David C. <unc...@un...>]

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/