Let me jump in with my thoughts of the day.
Typically in the FlightGear project we have welcomed additive changes (aka
new features.)
We do not seem to be averse to complicated systems, complicated code,
complicated configuration files. Just look at some of the things we can do
with the gui configuration and all the things we can do with nasal.
With all due respect to Melchior, I don't think he has presented a strong
case against adding vectors into the property system. The examples he
listed early in this discussion really did not carry a lot of strength and
several of his points could be easily dismissed. If there is a strong case
to be made, I don't think it has been made yet.
With all due respect to Tim, slightly more compact xml representation for a
couple small parts of a couple files isn't a strong argument for adding new
complicated code.
Arrays of like elements have been part of computer programming every since I
saw my first computer program in 1983 ... probably well before that even.
Right now, I find it really hard to see why we would absolutely refuse a
submission that adds functionality without changing existing functionality.
FlightGear is full of example of this sort of thing. I just don't see why
the heels are dug so far in on this one
So in my view if we are discussing the addition of a feature that is
immediately useful for some developers, and it does not harm existing code
or features, but simply adds functionality, then this is right in line with
typical FlightGear development procedure.
If there is any one who doesn't want this particular code added, I think the
burden is on them to put forth a very strong case for why not. What
specifically is harmed? What specifically will break? What specific corner
are we painting ourselves into? And if a legitimate concern is raised,
then hopefully Tim can come back and address that. But so far I haven't
seen any concern that hasn't been reasonably addressed already by Tim.
If we say that we won't allow new code if there is already some way to do
most of what the new code does in some other way, then we might as well get
rid of nasal, because we can already do everything that nasal does in C++.
And why would we have migrated to C++ since we could already do everything
we wanted in C. Why would we add a menu and dialog system when we can
already do everything with command line options and keystrokes? Why make a
Mac version when there is already a windows version? I can think back to
early in the project when adding the property system itself was a highly
controversial move. The clear answer to why we've added much of our code
and features is convenience; ease of use ... and maybe only for a few
developers or end users ... not necessarily for everyone.
So after hearing all the discussion (maybe I'm forgetting something, but I
can't think of what that might be) I am having a really difficult time
seeing why we would prevent the addition of new code that simply adds
functionality without harming or changing or removing existing
functionality.
Without seeing anything so far that I would consider a compelling argument
against, I vote for giving Tim the green light here. Developer convenience
has almost always been a good enough reason in the past.
Best regards,
Curt.
On Sat, Apr 4, 2009 at 11:14 AM, LeeE <l...@spatial.plus.com> wrote:
> On Saturday 04 April 2009, 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?
> >
> > 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.
>
> I too think the that the real issue here is the representation in
> the property tree, not functionality. As long as the data is
> available in the property tree it shouldn't affect the
> functionality at all because it'll be trivial to convert from the
> current property tree representation of the data to the form
> required by OSG.
>
> I still can't see a good reason to make changes to the way the
> property tree represents data unless the overhead of accessing
> three or four property tree nodes, instead of just one, has a
> significant impact on performance.
>
> How frequently does this data need to be accessed?
>
> LeeE
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
