Good to hear from you. I hope I don't make myself too much of a
pain-in-the-butt.
> From: "Gavin Bell" <gavin@krypton.engr.sgi.com>
> Date: Fri, 28 Oct 1994 10:46:44 -0700
> Subject: Re: Inlining, name scoping, defining
>
> I filed this RFE just yesterday, which is what you want, I think. Note
> that it doesn't require any change to Inventor; it can be implemented
> as two new nodes:
>
> Mike Natkin made me think of this:
>
> Sometime you want a DEF/USE that is scoped by the file format; for
> example, I
> want to define a borderColor and interiorColor and then use a File node
> that
> uses them.
>
> I don't think DEF/USE is the right mechanism; you really want something
> that is
> scoped by Separators.
I can't really tell, is this you talking, or Mike?
> Which shouldn't be too hard to implement; it would look like:
>
> Define {
> name "BorderColor" # SFString
> value Material { .... } # SFNode
> }
Yes, I like this, looks clean. I gather that a defined
element is not "drawn" until it is used. (An earlier complaint/
misunderstanding? I had was that there seemed to be no way of
defining somehting without also having it be drawn when as you
to read the file. This was the case, right?)
You seem to say below that a defined element is put into a
dictionary. I assume that a "dictionary" is a keyed
collection object, where the key is the name string -- i.e.
I can fetch out the contents, if I know the ascii string name.
Is that correct?
(My addsion Wesely reference doesn't have an SbDict in it.)
Question: Which dictionary? The "current" dictionary? That is,
there is some construct, for example,
Dictionary {
name "Linas Stuff"
Define {
name "My Border Color"
Material { ...}
}
Define {
name "My Shape"
Coordinate3 { ...}
}
}
> File {
> name "stuff"
> ... contains:
> Use { name "BorderColor" }
> }
Well, you still have the name scoping question ...
You seem to hint that the Separator should do the scoping,
but I'm a little concerned with overloading the Separator
with too many features/functions. It already does a lot of
things, giving it one more responsiblity may in the long run
divert it from it's original intent -- to act as a
"collection class" to contain child geometry & material.
Maybe the "dictionary" could provide that scoping?
So we have the following example
File {
name "stuff" # ... contains: Use { name "BorderColor" }
# ERROR -- BorderColor not defined.
}
Dictionary { # create dictionary
name "Linas Stuff" # name the dictionary
Define { # add an entry
name "BorderColor"
Material { ...}
}
} # close dictionary
Dictionary { # create dictionary
name "Gavin Stuff" # name the dictionary
Define { # add an entry
name "BorderColor"
Material { ...}
}
} # close dictionary
Dictionary {
name "Linas Stuff" # ahha -- open an existing dictionary
File {
name "stuff" # ... contains: Use { name "BorderColor" }
# OK -- found BorderColor in this scope
}
}
File {
name "stuff" # ... contains: Use { name "BorderColor" }
# ERROR -- BorderColor not defined.
}
Dictionary {
name "Gavin Stuff" # ahha -- open an existing dictionary
File {
name "stuff" # ... contains: Use { name "BorderColor" }
# OK -- found BorderColor in this scope
}
}
> The implementation would need a new element, called perhaps
> "DefinitionsElement", derived from SoAccumulatedElement. It would
> store a list
> of { name, node, state_depth } triples, and implement appropriate
What's state depth?
> set/get/ and
> pop/ methods (if we think there will be lots of definitions, an SbDict
> would be
> better than a list, but the idea is the same).
Assume that there will be lots of definitions.
--linas