Melchior FRANZ wrote:
> * 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?
I can't really imagine all possible uses, but people are clever
with animations, and one could imagine "a fair number" being changed
every frame.
>
> 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.
Sounds like a very brittle hack to me when the update would
just happen if the property were a vector.
Tim
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
