adobe-source-devel — ASL development topic discussion

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

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

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

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/

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

[Ralph T. <ra...@gm...>]

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

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

[Sean P. <sp...@ad...>]

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

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

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

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/

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

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/

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

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

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

Re: [Adobe-source-devel] Disabling buttons

[Sean P. <sea...@ma...>]

Correct!

Adam tracks which values contribute to which other values through all 
operations -

Any cell value contributing to an invariant is "poison".
Any cell value derived from a poison value is invalid.

Button right now are latches in a pipe (in the future, I want to change 
them to be latch controls, rather than the latch itself). A button 
receives a value and forwards it when clicked. If the value is invalid, 
the button is disabled.

Other controls enable/disable depending on if the cell they are bound 
to was "considered" or not. Every interface cell has a priority, if the 
priority or value contributes, then the cell was considered. Right now, 
considered isn't tracked at as fine a granularity as contributing 
(priority is tracked at the sheet level).

Sean

On Apr 2, 2005, at 5:56 PM, Ralph Thomas wrote:

> can_do_element_operation is in the invariant section, meaning that it
> should be true.
>
> I think what happens is:
>
>   * When "selection == @item_end" the invariant can_do_element
> operation is not satisfied
>   * "selection" caused to an invariant violation.
>   * .._params are dictionaries, all of which reference "selection"
>   * the buttons are bound to the .._params which contain a cell
> contributing to an invariant violation and are disabled.
>
> It seems like if a dictionary contains any cell which contributed to
> an invariant violation then anything bound to the dictionary is
> disabled.
>
> Ralph
>
> On Apr 2, 2005 4:08 PM, David Catmull <unc...@un...> 
> wrote:
>> I'm trying to understand how the list_box_emulator example works as 
>> far
>> as disabling the Insert and Delete buttons.
>>
>> There is a 'can_do_element_operation' in the sheet, and yet it is not
>> referenced anywhere. It looks like the buttons are being disabled
>> because they are bound to 'insert/delete_params' which both reference
>> 'selection' which is referenced in the invariant, but I still don't
>> quite follow how that works. What exactly is the connection between
>> 'insert/delete_params' and 'can_do_element_operation'? Is it just the
>> fact that 'selection' is in the definition of
>> 'can_do_element_operation'?
>>
>> --
>> 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
>>
>
>
> -------------------------------------------------------
> 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

Re: [Adobe-source-devel] Disabling buttons

[Ralph T. <ra...@gm...>]

can_do_element_operation is in the invariant section, meaning that it
should be true.

I think what happens is:

  * When "selection == @item_end" the invariant can_do_element
operation is not satisfied
  * "selection" caused to an invariant violation.
  * .._params are dictionaries, all of which reference "selection"
  * the buttons are bound to the .._params which contain a cell
contributing to an invariant violation and are disabled.

It seems like if a dictionary contains any cell which contributed to
an invariant violation then anything bound to the dictionary is
disabled.

Ralph

On Apr 2, 2005 4:08 PM, David Catmull <unc...@un...> wrote:
> I'm trying to understand how the list_box_emulator example works as far
> as disabling the Insert and Delete buttons.
> 
> There is a 'can_do_element_operation' in the sheet, and yet it is not
> referenced anywhere. It looks like the buttons are being disabled
> because they are bound to 'insert/delete_params' which both reference
> 'selection' which is referenced in the invariant, but I still don't
> quite follow how that works. What exactly is the connection between
> 'insert/delete_params' and 'can_do_element_operation'? Is it just the
> fact that 'selection' is in the definition of
> 'can_do_element_operation'?
> 
> --
> 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
>

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

[Ralph T. <ra...@gm...>]

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/

[Adobe-source-devel] Disabling buttons

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

I'm trying to understand how the list_box_emulator example works as far 
as disabling the Insert and Delete buttons.

There is a 'can_do_element_operation' in the sheet, and yet it is not 
referenced anywhere. It looks like the buttons are being disabled 
because they are bound to 'insert/delete_params' which both reference 
'selection' which is referenced in the invariant, but I still don't 
quite follow how that works. What exactly is the connection between 
'insert/delete_params' and 'can_do_element_operation'? Is it just the 
fact that 'selection' is in the definition of 
'can_do_element_operation'?

-- 
David Catmull
unc...@un...
http://www.uncommonplace.com/

[Adobe-source-devel] ASL and menus

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

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/

Re: [Adobe-source-devel] Small/mini control size fix

[Sean P. <sp...@ad...>]

On Mar 31, 2005, at 8:30 AM, David Catmull wrote:
>
> In Interface Builder I can place a control a lot closer to the edge 
> than where these are getting clipped - and it still looks good in IB's 
> Carbon Simulator, which I assume is a valid test - so I'm not sure 
> where the clipping comes from.

The clipping is happening because of the panels and outsets not being 
handled correctly. This seems to be a common point of breakage so I'll 
describe it here (and find a good place for it in the docs soon).

The idea with the outsets for a widget is that they describe the visual 
area beyond the visual alignment box that the widget hangs. This space 
is for parts of the control that should hang into white space. Examples 
include:

drop shadows on buttons
the part of the check on a check box that sticks above the box
the thin edge on the left side of a radio button (and right side if it 
has no label) to optically align it (the same way a letter "O" will 
hang a little into the margin in an app with good typography).
The white space around a control that the OS imposes

So the width and hight of the control should be the "tight visual 
bounds" - and the outset goes beyond that.

Right now outsets are used for two purposes:

To adjust panels so that they are big enough to hold their complete 
contents to correctly hide/show without clipping or shearing.
To warn (currently with a rather hostile assert) when visual elements 
collide.

A big problem seems to be how the first of these is handled - what 
currently happens is that when an outset of something in a container 
with no visual edge goes over the edge of the container, the outset of 
the container is increased to contain it.

This means that containers with non-visible edges (such as a panel) 
need to compensate. This is done by growing the bounds to include the 
offset, adjusting the position (if the offset is on the top or left 
side), and, if the view system is hierarchical, adjusting the origin so 
0,0 is in the same place as it would have been prior to adjusting the 
position.

Right now, Eve in our example app is running flat (and the client code 
is adjusting the hierarchies of HI views). For most widgets you want to 
do the same steps as above to compensate for the outset except for 
adjusting the origin. The way the example code is written, adjusting 
the origin correctly is a pain - we should be running with Eve in 
hierarchical mode.

I was considering when I started this e-mail changing Eve so that it 
would simply expand out the side of a panel rather than expanding the 
outset. The problem with this solution is it will fail for containers 
with some visual edges (consider a container with a divider line on the 
top - you don't want the line to grow some odd number of pixels on the 
left or right side to match the outsets of the content). So I don't 
have a better way to handle this - but hopefully this helps get the 
example code cleaned up.

Sean

Re: [Adobe-source-devel] Small/mini control size fix

[Sean P. <sp...@ad...>]

I'm not sure this helps much if at all -

The "fudge" factors still need to be applied for the most part to the 
outset. I think GetThemeMetric is most likely what GetBestControlRect 
calls so I doubt it saves you much. My recommendation would be to stop 
trying to share so much of the code, each widget is going to have to do 
some calculations and fundging - the hard coded values need to be made 
external, but otherwise just do the best you can. Go for a simple 
solution - not a clever one.

Sean


On Mar 31, 2005, at 11:13 AM, Foster T. Brereton wrote:

> My idea is to remove GetBestControlRect because of its inherent 
> bugginess, and replace it with a metric system similar to what I'm 
> envisioning Ralph is using on Windows. It'll use calls to 
> GetThemeMetric to calculate minimal sizes for controls, and then the 
> best_bounds calls will add the size/baseline of the text.
>
> This should remove the fudge system entirely, or at least minimize it 
> and systematize it so it's not so horrendous.
>
> Blessings,
> Foster
>
> On Mar 31, 2005, at 11:06a, David Catmull wrote:
>
>> On Mar 31, 2005, at 10:29 AM, Ralph Thomas wrote:
>>> So, is the problem that you can't get widget metrics from
>>> GetThemeMetric for small controls?
>>
>> Hm, I should do that instead of hard-coding 17 and 14. I forgot about 
>> theme metrics. The problem is that GetBestControlRect doesn't 
>> properly account for a control being set to small or mini.
>>
>> -- 
>> David Catmull
>> unc...@un...
>> http://www.uncommonplace.com/
>
> --
> 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
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/Info/Sentarus/hamr30
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] Small/mini control size fix

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

GetThemeMetric isn't working so well after all. For mini pushbutton 
height, it returns 16, but it should be 14. Small buttons are 17 pixels 
high.

-- 
David Catmull
unc...@un...
http://www.uncommonplace.com/

Re: [Adobe-source-devel] Small/mini control size fix

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

My idea is to remove GetBestControlRect because of its inherent 
bugginess, and replace it with a metric system similar to what I'm 
envisioning Ralph is using on Windows. It'll use calls to 
GetThemeMetric to calculate minimal sizes for controls, and then the 
best_bounds calls will add the size/baseline of the text.

This should remove the fudge system entirely, or at least minimize it 
and systematize it so it's not so horrendous.

Blessings,
Foster

On Mar 31, 2005, at 11:06a, David Catmull wrote:

> On Mar 31, 2005, at 10:29 AM, Ralph Thomas wrote:
>> So, is the problem that you can't get widget metrics from
>> GetThemeMetric for small controls?
>
> Hm, I should do that instead of hard-coding 17 and 14. I forgot about 
> theme metrics. The problem is that GetBestControlRect doesn't properly 
> account for a control being set to small or mini.
>
> -- 
> David Catmull
> unc...@un...
> http://www.uncommonplace.com/

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

Re: [Adobe-source-devel] Small/mini control size fix

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

On Mar 31, 2005, at 10:29 AM, Ralph Thomas wrote:
> So, is the problem that you can't get widget metrics from
> GetThemeMetric for small controls?

Hm, I should do that instead of hard-coding 17 and 14. I forgot about 
theme metrics. The problem is that GetBestControlRect doesn't properly 
account for a control being set to small or mini.

-- 
David Catmull
unc...@un...
http://www.uncommonplace.com/

Re: [Adobe-source-devel] Small/mini control size fix

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

All,

I think the clipping is due to the fudge system being applied 
inappropriately. There's enough stuff massively broken in there that 
I'll be spending some time fixing it up after the ASL 1.0.2 release. I 
also aim to take some of what Ralph has been working on in Windows and 
trying to see what is applicable to the Mac-- I trust something good 
will come of it.

Blessings,
Foster

On Mar 31, 2005, at 10:29a, Ralph Thomas wrote:

> I'm sorry that I don't know more about this problem on Mac (I know all
> about it on Windows ;-)).
>
> So, is the problem that you can't get widget metrics from
> GetThemeMetric for small controls? Because I think that you can use
> the HITheme* APIs to get the sizes of small and mini controls. There's
> more information here:
> http://developer.apple.com/releasenotes/Carbon/HIToolbox.html , but
> the real information is in the Carbon headers.
>
> Thanks!
>  Ralph
>
> On Mar 31, 2005 8:30 AM, David Catmull <unc...@un...> 
> wrote:
>> I'm experimenting with a workaround for the GetBestControlRect 
>> problem:
>> hard-code the height for small & mini buttons. It works, except that
>> buttons get a little clipped when they're at the side or bottom of a
>> group/tab box like the Update button in the Adam and Eve tabs of the
>> main window.
>>
>> In Interface Builder I can place a control a lot closer to the edge
>> than where these are getting clipped - and it still looks good in IB's
>> Carbon Simulator, which I assume is a valid test - so I'm not sure
>> where the clipping comes from.
>>
>> --
>> David Catmull
>> unc...@un...
>> http://www.uncommonplace.com/
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by Demarc:
>> A global provider of Threat Management Solutions.
>> Download our HomeAdmin security software for free today!
>> http://www.demarc.com/Info/Sentarus/hamr30
>> _______________________________________________
>> Adobe-source-devel mailing list
>> Ado...@li...
>> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/Info/Sentarus/hamr30
> _______________________________________________
> 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

Re: [Adobe-source-devel] Small/mini control size fix

[Ralph T. <ra...@gm...>]

I'm sorry that I don't know more about this problem on Mac (I know all
about it on Windows ;-)).

So, is the problem that you can't get widget metrics from
GetThemeMetric for small controls? Because I think that you can use
the HITheme* APIs to get the sizes of small and mini controls. There's
more information here:
http://developer.apple.com/releasenotes/Carbon/HIToolbox.html , but
the real information is in the Carbon headers.

Thanks!
 Ralph

On Mar 31, 2005 8:30 AM, David Catmull <unc...@un...> wrote:
> I'm experimenting with a workaround for the GetBestControlRect problem:
> hard-code the height for small & mini buttons. It works, except that
> buttons get a little clipped when they're at the side or bottom of a
> group/tab box like the Update button in the Adam and Eve tabs of the
> main window.
> 
> In Interface Builder I can place a control a lot closer to the edge
> than where these are getting clipped - and it still looks good in IB's
> Carbon Simulator, which I assume is a valid test - so I'm not sure
> where the clipping comes from.
> 
> --
> David Catmull
> unc...@un...
> http://www.uncommonplace.com/
> 
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/Info/Sentarus/hamr30
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>

[Adobe-source-devel] Small/mini control size fix

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

I'm experimenting with a workaround for the GetBestControlRect problem: 
hard-code the height for small & mini buttons. It works, except that 
buttons get a little clipped when they're at the side or bottom of a 
group/tab box like the Update button in the Adam and Eve tabs of the 
main window.

In Interface Builder I can place a control a lot closer to the edge 
than where these are getting clipped - and it still looks good in IB's 
Carbon Simulator, which I assume is a valid test - so I'm not sure 
where the clipping comes from.

-- 
David Catmull
unc...@un...
http://www.uncommonplace.com/

Re: [Adobe-source-devel] XCode projects

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

I fixed the application menu - the InfoPlist.strings file was 
overriding the bundle name string.

-- 
David Catmull
unc...@un...
http://www.uncommonplace.com/

Re: [Adobe-source-devel] XCode projects

[Sean P. <sp...@ad...>]

David,
That rocks! Thanks for all the help.
Sean

On Mar 30, 2005, at 6:08 PM, David Catmull wrote:

> I have now successfully gotten Adobe Begin to build and run with 
> XCode. The projects, and necessary code changes, have been checked in 
> to the sandbox. The only remaining issue is that the application menu 
> says "visual" instead of "Adobe Begin".
>
> -- 
> David Catmull
> unc...@un...
> http://www.uncommonplace.com/

[Adobe-source-devel] XCode projects

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

I have now successfully gotten Adobe Begin to build and run with XCode. 
The projects, and necessary code changes, have been checked in to the 
sandbox. The only remaining issue is that the application menu says 
"visual" instead of "Adobe Begin".

-- 
David Catmull
unc...@un...
http://www.uncommonplace.com/

Re: [Adobe-source-devel] Win32: ui-core fonts and fudges

[Sean P. <sp...@ad...>]

My intention has been that you can assume UTF-8, however, the intention 
is that we have a tokenized string system with runtime lookup for 
translations (we have something similar to what I want in use at 
Adobe... but not in a form that could be open sourced). So the UTF-8 
isn't just UTF-8, it is UTF-8 with markup. In the next couple of months 
I'll be working on a plan file so this will go into that but here is a 
preview:

All strings can be assumed to be UTF-8, however, they may contain XML 
markup (that is, a string is an XML fragment). Normally a string will 
be tagged as being "external", that is, it can be replaced at runtime 
with an appropriate translation:

"<xstr id='cancel'>Cancel</xstr>"

An external string is looked up at runtime from the id attribute and 
context. Context is provided by platform, locale, application, and 
location of use (such as the particular dialog). If no match is found, 
then the text provided directly in the XML is used as a default, 
english, translation. For common terms, the dictionary can be 
pre-seeded with common english terms so this can be abbreviated:

"<xstr id='cancel'/>"

These strings can include other markup, such as replacement points 
(with attributes), platform specific markup (like hot key markup for 
Windows). Every platform does not have to understand all of the markup. 
Prior to use, the string is passed through a function, xstr_to_xxxx() 
[xxxx might vary on usage, such as CFString for Mac]. These functions 
will resolve the markup and return an appropriate string. Because these 
strings are XML, this provides a way to specify UTF-8 code points 
directly in the string as escaped XML. The filters should assume that 
if the string isn't a valid XML fragment, it is simply raw UTF-8 
(however, if it is an invalid XML fragment, it should also issue a 
warning).

Before we go too much further with making the example client code into 
real library code, we should provide at least a rudimentary xstring 
system.

Sean


On Mar 28, 2005, at 9:13 AM, Foster T. Brereton wrote:

> Yes. I'd like to make the standard character encoding inside the ASL 
> to be UTF8. There isn't any internationalization support currently in 
> the application, but UTF8 is the wisest choice for the internal 
> format.
>
> Your UXTHEME work sounds very impressive! I am interested to take a 
> look at it when you think it's ready.
>
> Blessings,
> Foster
>
> ----- Original Message ----- From: "Ralph Thomas" <ra...@gm...>
> To: "Foster T. Brereton" <fbr...@ad...>
> Sent: Friday, March 25, 2005 5:13 PM
> Subject: Re: [Adobe-source-devel] Win32: ui-core fonts and fudges
>
>
>> So is it okay to standardize on UTF-8 in ui-core? By this I mean that
>> we assume that all strings going in and coming out of ui-core are in
>> UTF-8. This is very easy to do on Win32 (with WideCharToMultiByte and
>> friends) and MacOS (CFString supports UTF-8 as an encoding).
>>
>> UTF-8 could easily be put into the Eve/Adam files (although I guess
>> some care would have to be taken to correctly escape "). It has the
>> additional advantage of containing US-ASCII without any special
>> characters (so existing Eve/Adam files won't create illegible GUI).
>>
>> Thanks!
>>  Ralph
>>
>>
>> On Fri, 25 Mar 2005 09:14:50 -0800, Foster T. Brereton
>> <fbr...@ad...> wrote:
>>> Intriguing! Please keep us posted.
>>>
>>> A lot of the code in Win32 is from an older project. If there are 
>>> newer
>>> and better means of managing these UI elements I'm all for it.
>>>
>>> Blessings,
>>> Foster
>>>
>>> On Mar 24, 2005, at 11:07p, Ralph Thomas wrote:
>>>
>>> > Hi all,
>>> >
>>> > I've been reading through the Win32 ui-core code. I have two 
>>> questions:
>>> >
>>> >   1. Why is the font name hard-coded? Shouldn't DEFAULT_GUI_FONT be
>>> > used?
>>> >   2. How does i18n work? It looks like text is always in the 
>>> current
>>> > codepage (i.e.: not UTF-X).
>>> >
>>> > Also, I've been playing with the UXTHEME bits, and am working to
>>> > remove the fudges. I'm planning on doing this in such a way that 
>>> when
>>> > UXTHEME is available (i.e.: on Windows XP and 2003) it will be 
>>> used to
>>> > look up metrics, and when it's not available the values will be
>>> > calculated and fudged with constants. The UXTHEME font bits can 
>>> also
>>> > tell you about baselines inside widgets (I think -- I haven't 
>>> tested
>>> > it yet).
>>> >
>>> > I'm quite sure that the widget metrics can change on the fly. If 
>>> you
>>> > open Control Panel -> Accessibility -> Display Options, and enable
>>> > high-contrast mode then the sizes of various standard widgets 
>>> change.
>>> > Windows does this by sending a WM_THEMECHANGED message to all 
>>> windows
>>> > (and stock widgets know what to do, owner drawn need to capture the
>>> > message).
>>> >
>>> > I'll keep you updated on my UXTHEME research :).
>>> >
>>> > 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
>>>
>
>
>
> -------------------------------------------------------
> 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