* 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.
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
