> I think I was misled partly by the superficial similarity to a menu,
The syntax is dictated by the resource parser. The semantics are
implied later. Thus, we can use one file format/parser/data structure
for pretty much everything, and let the code decide what the data
means later.
A Resource is a tree structure. Each node has a list of subresources.
Each subresource can have a name and/or value or subresource.
So you see syntaxes like this:
name = value
name = { list of subresources }
value
{ list of subresources }
The menu parser, by convention, uses the first value in a list as the
string to use in the menu button. I chose this because the label
string is "part of" the menu, whereas for the mouse things the "Right"
isn't "part of" the resource, it's a way of locating it when needed.
So...
{File
{Quit Action() }
}
but
Mouse = {
Right = { Action() }
}
The menu resources are processed in order, so no name is needed, the
location in sequence is significant. However, for mouse bindings, we
need to locate a specific node and attach it to the mouse button
event, so it needs a name.
> partly by the short description of Mode() ("Change or use the tool
> mode") making it look as though calling Mode() multiple times without
> anything else between were useless, thus rendering the
> sequential-execution interpretation nonsensical.
That's a weird one, yes. You have to know that "Mode(Notify)"
activates the tool. Mode() does a lot of different types of things.
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
