Melchior
>
> * 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.
>
As I see it this proposal would satisfy the many who want to retain the
<red> <green> etc. tags and would appear to meet the requirements of OSG.
But I sure there are other solutions, or I might be getting it totally
wrong.
I hope the best is not getting in the way of good enough.
Vivian
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
