Curtis L. Olson wrote:
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 you misunderstood this a little. I'm currently doing this patch.
Vassilii offered to do review and testing. That aside, you'll see some
code this evening. Have just to remove one issue.
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.
When first talking about this, I instantly got the response, that it
will most likely not make it in 1.0, which is not very encouraging...
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.
The scope I thought about is actually not really difficult to reach. I
do just want to make changes a user makes in the option dialogs
(rendering options, level of detail, sound volume, maybe others)
persistent. For this I changed SGProperty node to include a new
attribute called "userarchive" and the writeProperties and writeNode
methods to include a new parameter indicating which is the desired
archive mode they should look upon. In preferences.xml I added this
attribute to all properties that are used in mentioned dialogs (adding
missing properties on the way).
Then in fg_commands.cxx I just dump the userarchivable properties of the
tree to ~/.flightgear/preferences.xml. And in fg_init.cxx I read this
file back. The only thing missing to a working version is that the
userarchive flag gets set on all properties that are read from this
file. This way a user could simply add other properties he wants to be
saved on exit.
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.
The dialog properties work pretty straight forward as far as I can tell.
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 ...
Isn't saving aircraft stuff more something for "Save flight"?
Regards,
Nine
_______________________________________________
Flightgear-devel mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
