I don't think we need to change the API. I just want to make sure the comment in the code is right, because it didn't match my understanding of how these values are used.
What confused me in the comment was the statement that OFF applied to attributes, because I don't think OFF applies to modes, not attributes. I think what we have is as follows: * OVERRIDE causes a parent node's attribute/mode to override child settings of the same attribute/mode, unless the child's attribute mode is PROTECTED. * PROTECTED applies to attributes and modes as described above. * INHERIT causes an attribute/mode to be ignored, and the node gets the value for that attribute/mode from parents. If none of those are set, the attribute/mode applies in the default behavior: child values override parent values. * Finally, ON and OFF apply to modes only, toggling their enabled state. These are ignored for attributes. You can OR these together so that a mode can be both ON and PROTECTED, but some combinations don't make sense, such as (PROTECTED|INHERIT). Does this sound right? Thanks for the help with this (and sorry for the trip down memory lane :-). -Paul > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Robert Osfield > Sent: Saturday, February 10, 2007 2:45 AM > To: osg users > Subject: Re: [osg-users] StateAttribute comment clarification > > On 2/9/07, Paul Martz <[EMAIL PROTECTED]> wrote: > > > In in here it masks out all but StateAttribute::OVERRIDE & > > > StateAttribute::PROTECTED so only these have meaning in > the case of > > > attributes. > > > > Yes, but setAttributeAndModes() handles the case where the override > > value is INHERIT (by removing the attribute). So it seems > to me that > > INHERIT does have a meaning for attributes. > > From what I recall INHERIT is used is removes the attribute > or mode thereby allow that parents value of that > attribute/mode to be inherited down. Its a looong time since > I wrote this stuff ;-) > > I'm open to tweaking the API to make things clearer, albeit > keeping backwards compatibility. > > Robert. > _______________________________________________ > osg-users mailing list > [email protected] > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
