From: Melchior F. <mf...@ao...> - 2009-04-04 14:30:35
|
* Heiko Schulz -- Saturday 04 April 2009: > How would it be better, and would all what Tim wants to do, > be still possible? The features that Tim is talking about (effects and stuff), and the XML and property tree representation do IMHO not have much to do with each other. How can separate values be stored without vector property type: Just like now. Every "property" (red/green/...) is a an actual *property* (i.e. an SGPropertyNode). But we had that aleady ... What the best solution for the "dynamic" attribute is probably depends on the case. How often do we expect such color properties to change? Many of them in every frame? Or just a few every few minutes? One solution could be to have the properties just like now (with children possibly tied to memory): color/{red,green,blue,alpha} Add a listener to the parent "color", and trigger it when all color properties have been set, so that the code can update whatever needs to be updated. The triggering happens with SGPropertyNode::fireValueChanged(). This can be nicely done with a few helper functions. Of course, triggering the parent would have to be done manually in the property browser or via telnet, but that's certainly not the main use case and is IMHO acceptable. No intrusive changes with multiple bad side effects needed. m. |