Vassilii Khachaturov wrote:

For example I'd strongly consider the missing options saving a bug that
has to be fixed before we give FlightGear to all the people out there.
They are used to this behavior from nearly every program they use, and
will expect the same from FG. Others may think, that we lived without
this feature (who doesn't have his own private preferences.xml in the
search path?) and it would be too an intrusive change. But that's the
difference between a developer and an end user release.

Nine

I agree that this is a very serious feature for 1.0 inclusion.
Maybe if we just have several people "signing off" the patch before
inclusion (by 1) reading the code 2) testing it locally 3) sending an
email to the list it's OK from their point of view for the 1.0)
this will help.

Personally, I will be willing to do this to the above patch.

For what it's worth. There are many people that say, "We can't do a v1.0 release without feature XYZ" and then do nothing to impliment feature XYZ. Or they might say, how can we include feature A without including feature B, but no one has stepped forward to work on feature B but someone has finished feature A.

Not to sound like a broken record, but in the open source world, if no one steps forward to work on a particular feature, it just isn't going to happen. It won't get added to v1.0 if no one takes the responsibility upon themselves to do it.

So that said, your offer to actually work on a suggested feature is like a beacon in the darkness! :-)

I think that if you could get this working well, it would be worthy of inclusion in 1.0. However, I suspect there are a number of *really* tricky issues to deal with and that's probably why the feature doesn't work correctly now.

So before you get too far, I think I would be very interested in hearing how you plan to attack this, and perhaps what the scope of your patch might be.

Things to consider ... dumping out the entire property tree and reading it back will not accomplish the task because many properties represent derived values. And much of the simulator 'state' is maintained internally in the C/C++ code and will not react correctly if the appropriate initialization functions (and sequence of function calls) is not called. It can become really tricky stuff.

You may want to attack this in small steps ... for instance start out with just getting save/load of aircraft position working. Then move on to other chunks of the property tree adding and testing them one by one ...

Regards,

Curt.

--
Curtis Olson        http://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:        2f585eeea02e2c79d7b1d8c4963bae2d


_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to