Re: [Flightgear-devel] Options saving patches
Stefan Seifert wrote: Also nice would be any review of the code :) and of course some info about how the chances are for inclusion. I must say I like the idea, but given it's current state (no windows support) I would like to postpone it until after FlightGear 1.0 is released. There are a few small issues that I would like to see added (or to see changed) but that's nothing major; like the option to ignore this feature all together. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Options saving patches
Erik Hofman wrote : Stefan Seifert wrote: Also nice would be any review of the code :) and of course some info about how the chances are for inclusion. I must say I like the idea, but given it's current state (no windows support) I would like to postpone it until after FlightGear 1.0 is released. What is missing for windows ? There are a few small issues that I would like to see added (or to see changed) but that's nothing major; like the option to ignore this feature all together. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Options saving patches
Frederic Bouvier wrote: What is missing for windows ? Stefan Seifert wrote: Missing is support for Windows, where the directory should be like %PROFILE%/Application Data/FlightGear (or such). Also I don't know if Windows supports the mkdir function. Would be nice if someone could port. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Options saving patches
Erik Hofman a écrit : Frederic Bouvier wrote: What is missing for windows ? Stefan Seifert wrote: Missing is support for Windows, where the directory should be like %PROFILE%/Application Data/FlightGear (or such). Also I don't know if Windows supports the mkdir function. Would be nice if someone could port. there is a mkdir function in windows. Well actually, there is a _mkdir function like this : #*ifdef* _MSC_VER ret = ( _mkdir( path_.c_str() ) == 0 ); #*else* ret = ( mkdir( path_.c_str(), 0755 ) == 0 ); #*endif* What's wrong in storing informations in %APPDATA%/flightgear.org just like fgrun and fgadmin ( they both use fltk for that ) ? Anyway, this is a minor effort. If you commit this patch, I will send you a windows port. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Proposal: New way to add commandline options
Hi, I was thinking, FlightGear is already able to handle way more options than advertised when running fgfs -h -v How would we all fell about minimizing the number of command line options in favor of the --prop:prop=value method and make sure all of them are explained in a document rather than the help message. As a temporary measure we could make sure the current options are still available, but not made public in the help message. How do you all feel about that? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Options saving patches
Sorry to be annoying yet again, but that's what I'm best at: * Erik Hofman -- Saturday 17 December 2005 10:48: I must say I like the idea, but given it's current state (no windows support) I would like to postpone it until after FlightGear 1.0 is released. And I would like to postpone the 1.0 release, until FlightGear is ready to be called 1.0. Saving GUI states is one piece of that puzzle, as are landing/taxi lights. There are no finished patches available for that yet? So? What keeps us from working on them and waiting until they are finished? (No, I won't be working on that, but I'm also not pressing for 1.0.) Either the 1.0 number means anything, then fgfs better be complete. Or it doesn't mean anything, then let's release it when it's done and call the next releases 0.9.10++. Or is there a compelling reason to rush out 1.0 *now*? One that we aren't told for whatever reason? Does anyone pay for it whose business depends on it? (MathWorks?) Or is it that fgfs needs for some reason to be called 1.0.0 for SCALE 2006? And why? Other reasons? Do we deserve to know about them? Doesn't look like it. I'm now sufficiently fed up with the secret 1.0 agenda, that I'll stop contributing until after this monstrosity is out. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Proposal: New way to add commandline options
Erik Hofman a écrit : Hi, I was thinking, FlightGear is already able to handle way more options than advertised when running fgfs -h -v How would we all fell about minimizing the number of command line options in favor of the --prop:prop=value method and make sure all of them are explained in a document rather than the help message. As a temporary measure we could make sure the current options are still available, but not made public in the help message. How do you all feel about that? I don't see the real benefit of this naming change. I rather see the burden of changing fgrun. And there are options that are not reduced to a property assignment. Why not documenting current options in a text file ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Melchior FRANZ wrote: Sorry to be annoying yet again, but that's what I'm best at: * Erik Hofman -- Saturday 17 December 2005 10:48: I must say I like the idea, but given it's current state (no windows support) I would like to postpone it until after FlightGear 1.0 is released. And I would like to postpone the 1.0 release, until FlightGear is ready to be called 1.0. What's this, now you want releases that have missing options for some OS'es?? Saving GUI states is one piece of that puzzle, as are landing/taxi lights. There are no finished patches available for Give me a patch and I'll commit it, until then there's little room for discussion. that yet? So? What keeps us from working on them and waiting until they are finished? (No, I won't be working on that, but I'm also not pressing for 1.0.) I don't like the idea of FlightGear 0.9.9.1223 just because no one cared to implement taxi lights. As a matter of fact I've seen several multi million dollar simulators that didn't implement them, Why? Probably because they're just eye-candy and add little to the simulator part of the program. I'm now sufficiently fed up with the secret 1.0 agenda, that I'll stop contributing until after this monstrosity is out. Lighten up, I just started looking at this patch since Fred promised to fill in the missing gaps. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Proposal: New way to add commandline options
Frederic Bouvier wrote: I don't see the real benefit of this naming change. I rather see the burden of changing fgrun. And there are options that are not reduced to a property assignment. True, those should be kept. But the main reason I started this was because: 1. We have at least two options for boolean assignment 2. We have more than two options for string assignments When using the --prop: method this will be reduced to just one option with one of several arguments. 3. The options.xml (and associated language files) are rather hard to maintain. Not to mention the fact that the non English versions are hopelessly out of date. 4. I think the --prop: method would make utilities like fgrun a lot easier to maintain since it can maintain a simple database of properties and it's arguments instead of a lot of different options. But it's not like I want to push this all of a sudden. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Erik Hofman wrote: Lighten up, I just started looking at this patch since Fred promised to fill in the missing gaps. I just noticed, that this patch could break compilation, since in sg_patch.cxx the new method is called makeDir and in the header it's still makedir. I know, I should always test before sending, but it was late yesterday and it was only a coding style fix... I'm about to add a --fghome command line option along with FGHOME enviroment variable support as of Melchior's request. Hope to post a new version today, which should be worth porting. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Stefan Seifert wrote: Erik Hofman wrote: Lighten up, I just started looking at this patch since Fred promised to fill in the missing gaps. I just noticed, that this patch could break compilation, since in sg_patch.cxx the new method is called makeDir and in the header it's still makedir. I know, I should always test before sending, but it was late yesterday and it was only a coding style fix... I noticed this already. I think I like it to be called create() instead, but that's a different matter. I'm about to add a --fghome command line option along with FGHOME enviroment variable support as of Melchior's request. Hope to post a new version today, which should be worth porting. I haven't checked the code yet, but I seem to recall this is already available somewhere? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Erik Hofman wrote: I noticed this already. I think I like it to be called create() instead, but that's a different matter. Maybe createDir? Because it's a member of SGPath which may as well be the path to a file. So it'd be confusing if path_to_a_file.create() created a directory. I haven't checked the code yet, but I seem to recall this is already available somewhere? Don't know. The other code uses the HOME environment variable, which my patch is using, too. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] need assistance with /sim/startup/browser-app and debugging property system values please (Help problem)
Warning: long append
The problem with help on mac os x (possibly other platforms) --
http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/
040462.html -- is still occurring.
somehow something is switching /sim/startup/browser-app from open
after it is set in Main/options.cxx, but before options are processed
from the command line
(help works if I start fgfs with --browser-app=open)
I am using the following arguments to fgfs to generate a log to
examine the problem:
--log-level=info --trace-write=/sim/startup/browser-app --trace-read=/
sim/startup/browser-app
Using grep on the source tree, I see the following /browser strings:
[/src/fgdev9.9] ima% find . -name '*.[ch]xx' -print | xargs grep $1 /
dev/null
./src/FlightGear/src/GUI/gui_funcs.cxx:string help_app =
fgGetString(/sim/startup/browser-app);
./src/FlightGear/src/Main/options.cxx:fgSetString(/sim/startup/
browser-app, webrun.bat);
./src/FlightGear/src/Main/options.cxx:fgSetString(/sim/startup/
browser-app, open);
./src/FlightGear/src/Main/options.cxx:fgSetString(/sim/startup/
browser-app, launchWebJumper);
./src/FlightGear/src/Main/options.cxx:fgSetString(/sim/startup/
browser-app, envp);
./src/FlightGear/src/Main/options.cxx:// SG_LOG( SG_GENERAL,
SG_INFO, help app is fgGetString( /sim/startup/browser-app ) );
./src/FlightGear/src/Main/options.cxx: SG_LOG( SG_GENERAL,
SG_ALERT, help app is fgGetString( /sim/startup/browser-
app ) );
./src/FlightGear/src/Main/options.cxx:{browser-
app, true, OPTION_STRING, /sim/startup/browser-
app, false, , 0 },
The tracing functions aren't seeing ANY changes to /sim/startup/
browser-app (from the log I guess they start after
/sim/startup/browser-app is set in Main/options.cxx, but these
functions are not seeing any changes after they start
either.)
By the time the app is up and running and I select Help from the Help
menu, the value has been changed
(it should be open on mac os x, but is netscape which is not
installed on the system).
Does anyone have any suggestions on how to explore the problem in gdb
to see what is going on? Where is a value like /sim/startup/browser-
app stored in memory
in a running copy of fgfs? Any suggestions on which property
functions to look at?
Thank you
Ima
A partial runtime log follows (help information lines prepended by
*** )
Using Mac OS X hack for initializing C++ stdio...
*** help app is open
*** Tracing writes for property /sim/startup/browser-app
*** Tracing reads for property /sim/startup/browser-app
Finished command line arguments
Initializing splash screen
ATI Radeon 7500 OpenGL Engine
Max texture size = 2048
Depth buffer bits = 16
Loading Airport Database ...
Data file version = 715
[FINISHED LOADING]
Loading Navaid Databases
opening file: /src/fgdev9.9/data/Navaids/carrier_nav.dat
opening file: /src/fgdev9.9/data/Navaids/TACAN_freq.dat
Standardising rwy number from B to 0B
Fixes
Attempting to set starting position for KDCA:33
runway = -77.0383, 38.856 length = 1585.26 heading = 142.76
Position for KDCA is (-77.0328, 38.8504) new heading is 322.76
Searching for airport code = KDCA
Position for KDCA is (-77.0398, 38.8515)
Initializing Time
Current greenwich mean time = Sat Dec 17 11:19:54 2005
Current local time = Sat Dec 17 06:19:54 2005
Reading timezone info from: /src/fgdev9.9/data/Timezone/zone.tab
Using zonename = /src/fgdev9.9/data/Timezone/America/New_York
First time, doing precise gst
snip
Initializing environment subsystem
2005/12/17 10:51
KDCA 171051Z 35003KT 10SM OVC250 01/M04 A3041 RMK AO2 SLP296 T00061039
METAR from weather.noaa.gov
closest station w/ metar = KDCA
WIND: [EMAIL PROTECTED] knots
Altitude = 15
Temp at alt (C) = 1
Temp sea level (C) = 1.02786
Altitude = 15
Dewpoint at alt (C) = -4
Dewpoint at sea level (C) = -3.997
Initializing Lighting interpolation tables.
Initializing Interpolator for /src/fgdev9.9/data/Lighting/ambient
Initializing Interpolator for /src/fgdev9.9/data/Lighting/diffuse
Initializing Interpolator for /src/fgdev9.9/data/Lighting/specular
Initializing Interpolator for /src/fgdev9.9/data/Lighting/sky
Reading sound sound from /src/fgdev9.9/data/Aircraft/A-10/Sounds/A-10-
sound.xml
Loading sound information for: engine
Loading sound information for: whine
Loading sound information for: engine
Loading sound information for: whine
Loading sound information for: rumble
Loading sound information for: rumble
Loading sound information for: rumble
Loading sound information for: gear
Loading sound information for: gear-lock
Loading sound information for: gear-lock
Loading sound information for: gear
Loading sound information for: gear-lock
Loading sound information for: gear-lock
Loading sound information for: gear
Loading sound information for: gear-lock
Loading sound information for: gear-lock
Loading sound information for: squeal
Loading sound information for: squeal
Loading sound information
Re: [Flightgear-devel] Re: Options saving patches
Melchior FRANZ wrote: Either the 1.0 number means anything, then fgfs better be complete. Or it doesn't mean anything, then let's release it when it's done and call the next releases 0.9.10++. Or is there a compelling reason to rush out 1.0 *now*? One that we aren't told for whatever reason? Does anyone pay for it whose business depends on it? (MathWorks?) Or is it that fgfs needs for some reason to be called 1.0.0 for SCALE 2006? And why? Other reasons? Do we deserve to know about them? Doesn't look like it. I'm now sufficiently fed up with the secret 1.0 agenda, that I'll stop contributing until after this monstrosity is out. Huh!?! We are making a huge controversy over the difference of plus or minus 0.0.1 Maybe we should drop the arbitrary version numbering scheme (and I do see the version numbers as 99.9.9% arbitrary) and go with code names for our releases. Would that make people happier? Curt. -- Curtis Olsonhttp://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
Re: [Flightgear-devel] Re: Options saving patches
On Saturday 17 December 2005 16:10, Curtis L. Olson wrote: Maybe we should drop the arbitrary version numbering scheme (and I do see the version numbers as 99.9.9% arbitrary) and go with code names for our releases. Would that make people happier? Curt. No what would make us more happy is to know why there is such an urgency to have two FG releases in the space of a couple of months when up till now we've been releasing about once per year. What has prompted this change? This decision didn't involve the developers at all. Not even a guys what do you think about having another release in January that just contains bug fixes? Are we changing to a frequent release cycle or what? When will the next release be after 1.0? March or April? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
Paul Surgeon wrote: On Saturday 17 December 2005 13:40, Erik Hofman wrote: Melchior FRANZ wrote: Sorry to be annoying yet again, but that's what I'm best at: * Erik Hofman -- Saturday 17 December 2005 10:48: I must say I like the idea, but given it's current state (no windows support) I would like to postpone it until after FlightGear 1.0 is released. And I would like to postpone the 1.0 release, until FlightGear is ready to be called 1.0. What's this, now you want releases that have missing options for some OS'es?? No, that's not what Melchior implied or said at all. What he said is that he would prefer if we hold off with ANY 1.0 release until FG is ready to be called version 1.0. He didn't mention any OS's in an exclusion list did he? Give me a patch and I'll commit it, until then there's little room for discussion. So in other words all the developers, we're going to release 1.0 whether they like it or not because you or Curt say so?! I thought this was a community project but I was clearly wrong. It would appear that we have zero say over this matter and even less chance of getting any honest answers from either you or Curt. I'm now sufficiently fed up with the secret 1.0 agenda, that I'll stop contributing until after this monstrosity is out. Lighten up, I just started looking at this patch since Fred promised to fill in the missing gaps. I would also like to know what this urgency for a 1.0 release is but all we get are answers that skirt the issue or no answers at all. Look, if we took half the time that we spend worrying about arbitrary version numbers and spent it developing code and fixing bugs, we'd be at v2.0 by now. I'm sorry that some people get so bent out of whack over something so arbitrary, but I know that we just aren't going to make everyone happy all the time. There's no grand conspiracy here, no secrecy. Let's keep it clean here, there may be children in the room. Curt. -- Curtis Olsonhttp://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
Re: [Flightgear-devel] Re: Options saving patches
Paul Surgeon wrote: No what would make us more happy is to know why there is such an urgency to have two FG releases in the space of a couple of months when up till now we've been releasing about once per year. What has prompted this change? This decision didn't involve the developers at all. Not even a guys what do you think about having another release in January that just contains bug fixes? Are we changing to a frequent release cycle or what? When will the next release be after 1.0? March or April? Look, rolling out a new release is a massive effort. We need to do a release more than once a year. But my time can be very limited depending on what other paying projects I'm involved with during the year. So I try to find a balance between a new release date that is appropriate for the project and my available time. Discussing this with the development community is ok, but at the end of the day, I have to pick a time that matches my personal schedule, otherwise there will be no release at all. And we need releases, just like we need to invite people over to our homes ... sometimes that's the only way certain messes will get cleaned up. If you want to pay me a fair salary, then you would be most welcome to tell me how and when to spend my time doing whatever it is you want me to do. Until then, I need to make my own decisions that strike the best balance I can come up with between the needs of this project and the needs of my family and jobs. That means there are external constraints to the flightgear release schedule that discussion on the list has no affect on. It's not a perfect world, so I'm sure you and others have and will continue to have plenty to complain about. But I'm getting really sick of hearing about version numbers so this is my last message on the topic for a while. Curt. -- Curtis Olsonhttp://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
Re: [Flightgear-devel] Proposal: New way to add commandline options
Erik Hofman wrote: How would we all fell about minimizing the number of command line options in favor of the --prop:prop=value method and make sure all of them are explained in a document rather than the help message. I see three reasons opposing this idea: 1.) I'm not sure but I assume you can't use : inside a command line option on certain platforms (Windows). 2.) Too often people want to do 'command -h [-v] | grep -i keyword' in order to search for a certain option, they don't want to browse a supplemental text file. 3.) Every effort spent into another duplication of such information is waste. If someone really wants to revamp '-h -v' I suggest to create a method that browses the property tree and to force any available option to carry an explanation that is attached to the respective object in the mentioned tree. Duplication of such information unavoidable results in some sort of mess - _always_ :-)) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Options
Well, I wasn't going to way-in until someone mentioned Scale and Mathworks. Just to set the record straight, for the 747 we'll be using FG-0.9.8 modified to handle all the 747 subsystems, engine models, synthetic voice, etc, etc. All the source files were provided to the primary authors, but for what ever reason they chose not to incorporate the code into CVS or ongoing releases. Bottom line, it has become a real pain in the *** to keep in sync, so why bother 0.9.9 does nothing new, great, or better for stand-alone sims. No wonder the whole world of cockpit builders prefers MS Windows. Packing and moving the sim requires time and expenses. For Scale and Mathworks it cost several hundred dollars which were not reimbursed; all we got from Mathworks was a free lunch. For all those complaining, my advice is put a sock in it JW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
On Saturday 17 December 2005 11:40, Erik Hofman wrote: Lighten up, I just started looking at this patch since Fred promised to fill in the missing gaps. I was delighted to see a form of the options saving patches going into CVS, since I've been using the earlier versions with no troubles at all for some time now. I was less delighted to find that SG no longer builds... sg_path.cxx: In member function `void SGPath::create_dir(mode_t)': sg_path.cxx:203: error: `subdir' undeclared (first use this function) sg_path.cxx:203: error: (Each undeclared identifier is reported only once for each function it appears in.) make[3]: *** [sg_path.o] Error 1 I really hope this is made to work at least as well as the earlier patches because I think it's a _great_ feature and one that makes life with FG that little bit more pleasant... Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Proposal: New way to add commandline options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Spott schrieb: I see three reasons opposing this idea: 1.) I'm not sure but I assume you can't use : inside a command line option on certain platforms (Windows). I really can't imagine any problems that it might cause under windows (haven't tested it though) 2.) Too often people want to do 'command -h [-v] | grep -i keyword' in order to search for a certain option, they don't want to browse a supplemental text file. see next answer 3.) Every effort spent into another duplication of such information is waste. If someone really wants to revamp '-h -v' I suggest to create a method that browses the property tree and to force any available option to carry an explanation that is attached to the respective object in the mentioned tree. Duplication of such information unavoidable results in some sort of mess - _always_ :-)) If the '-h -v' can get the relevant information out of the property tree then that's the best way to go. The information would be aviable on the command line help and in the property tree browser. It would also stay up to date as there's only one source (redundancy is *bad*). CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDpIy4lhWtxOxWNFcRAt+xAKCnxgY2tvxP9EZpNBslAAbhuCn3iwCfcBcJ 8vMGYAqv/e6z4fEJjkn+QlU= =oGav -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
AJ MacLeod wrote: I really hope this is made to work at least as well as the earlier patches because I think it's a _great_ feature and one that makes life with FG that little bit more pleasant... Yeah well, I was trying to outsmarten myself, and got hit in the back. It took me way longer than anticipated (due to some local problems it took almost the whole day for me to get it in) and by the time I was (almost) finished I had to leave :-(. Thanks to Frederic it should compile and work all correctly again. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Options saving patches
I guess what Curt was saying is, him being the release manager of the project, has to find appropriate and free time do all the things for a release, which is fair enough and understandable. Perhaps we can have more people to help doing a release? Personally I've only witnessed one release of FG (0.9.9). And I don't know what's the policy of this whole project. But could anyone else share the workload of doing a release? Or it has to be Curt and Curt alone? If we can do releases at any time, then surely we would have more control on what we could put into a release? I think most people, especially developers, prefers figuring out a features list or goals for a release, and then work towards them. When these are done, then we might want to go for a one month or two months code freeze/bug fix/stabilising/testing, followed by the release. And perhaps we could figure out some sort of roadmap? Look, rolling out a new release is a massive effort. We need to do a release more than once a year. But my time can be very limited depending on what other paying projects I'm involved with during the year. So I try to find a balance between a new release date that is appropriate for the project and my available time. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] The next release (was Re: Options saving patches)
Paul Surgeon wrote: On Saturday 17 December 2005 13:40, Erik Hofman wrote: What's this, now you want releases that have missing options for some OS'es?? No, that's not what Melchior implied or said at all. What he said is that he would prefer if we hold off with ANY 1.0 release until FG is ready to be called version 1.0. He didn't mention any OS's in an exclusion list did he? Give me a patch and I'll commit it, until then there's little room for discussion. So in other words f*ck all the developers, we're going to release 1.0 whether they like it or not because you or Curt say so?! No, that's not what *Erik* implied or said at all. Come on, Paul. I thought this was a community project but I was clearly wrong. It would appear that we have zero say over this matter and even less chance of getting any honest answers from either you or Curt. This just seems way over the top to me. Here you write: I would also like to know what this urgency for a 1.0 release is but all we get are answers that skirt the issue or no answers at all. and in the other post you write: No what would make us more happy is to know why there is such an urgency to have two FG releases in the space of a couple of months when up till now we've been releasing about once per year. I haven't been able to be as involved as I'd like, and maybe by virtue of missing a post here and there I've somehow missed out on the key post that explains this -- but I don't have any sense of this urgency to release 1.0 at all. I *have* seen posts to the effect that either Curt or Erik or both (can't remember) would like to see the next release be a 1.0 release, and to that effect would like to hold off on new features, instead polishing/fixing what's present. And I remember seeing Curt express an unofficial desire to do a v1.0 release sometime in early 2006. But I haven't seen a post saying . . .and that release will occur early in January or something like that, and I haven't seen posts to the effect of please hurry up and identify bugs/get those bugfix patches in so we can do the 1.0 release. Have there been such posts? Maybe I've just missed the posts in question. But I don't see this urgency to release 1.0 in a hurry that you guys are concerned about. Yet obviously it seems very clearly there to the two of you -- so much so that it must be because of a secret agenda. I just spent 15 minutes googling the mailing list archives and can't find anything implying that there's a hurry to release 1.0. What am I missing? Right now, the infrastructure of the project is such that Curt has to handle the release pretty much solo, I guess. My understanding (perhaps wrong) is that Curt's time constraints mean that if a `launch window' gets missed, the next opportunity to release may be many months later. That's not the worst thing to happen, of course, if there's some sort of showstopper bug. And even if there isn't, I agree with you that calling a release 1.0 means something, and a release should be held up or called something else if it's not ready to be called that. The problem is that I don't think everyone agrees what 1.0 should mean -- that is, what the absolutely necessary qualities of the 1.0 release are. For instance, from my perspective, the absolute most important thing to have in the 1.0 release -- more important than any features of the simulator (including that the simulated aircraft even fly!) -- is solid accompanying documentation along with very clearly described channels for seeking help, reporting bugs, etc. But I'm probably in the extreme minority in that regard. Melchior thinks without landing lights, we're effectively saying that FG is a daytime simulator only, since nighttime landings are too unrealistic otherwise; there are other people here who disagree. Back in January, these were some of the things that various individuals suggested were necessary before a 1.0 release: - improving the Getting Started manual; - concentrating on making the c172 as nice as it can be; - fixing the JSBSim issue with gear handing when the aircraft is at stop; - polishing fgrun; - being able to switch aircraft from within FG; - being able to switch airports from within FG, and to choose airports by colloquial location name; - significant improvement in fps; - ability to save both options/configuration and flight status for later resumption; - a formalized procedure for collecting/handling/tracking bug reports; I'm sure there were more I'm not catching. Anyway, some of these have happened and some haven't; given that not everyone agreed with all of these things, what does the fact that some are missing mean for a a v1.0 release (if anything at all)? Some developers are bound to feel that some of these suggestions are absolutely not necessary for 1.0; others feel very strongly about including them. And we can set up some kind of voting procedure or something like that to create a requirements list for
RE: [Flightgear-devel] The next release (was Re: Options saving patches)
Hi All What a storm in a tea cup I could not care less what the next release is called but it would appear that the sooner it is called 1.0 the sooner we can all get on with our lives. Maybe we should just call the current version of FG FLIGHTGEAR-NOW and all the past versions FLIGHTGEAR-THEN Then Curt could do a release when he had the time and the will to do it Maybe we could name the releases after made up words like Intel did with their chips. I think Curt and Erik do a great job and are at our beck and call more than they should be. So I will be happy with the next release what ever it is called and when ever it arrives. But don't make it to soon as I have a pile of work to do on the 737 and don't feel like working on it night and day.:-) Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
