Erik Hofman
> Vivian Meazza wrote:
>
> > Just to add that it doesn't work properly under my Cygwin, but then my
> home
> > directory is home/vivian meazza/. That's automatically generated by
> Cygwin
> > and I'm not changing it. I note, however that XP users will install FG
> in
> > C:\program fi
Stefan Seifert wrote:
Curtis L. Olson wrote:
I should also point out that I received an error message when the new
system couldn't load my preferences if they didn't exist. We should
see an error message in this case.
You received an error message and you should see an error message?
See
Vivian Meazza wrote:
Just to add that it doesn't work properly under my Cygwin, but then my home
directory is home/vivian meazza/. That's automatically generated by Cygwin
and I'm not changing it. I note, however that XP users will install FG in
C:\program files\FlightGear.
Could you test the
Curtis L. Olson wrote:
I should also point out that I received an error message when the new
system couldn't load my preferences if they didn't exist. We should
see an error message in this case.
You received an error message and you should see an error message? Seems
to me like that's the s
Oliver Schroeder wrote:
Yes, I noticed options.?xx before. And I did'nt explicitly meant that part.
But cd into the src directory and do a "grep -r argv *". What you will see is
for sure not simple and generic. And I just thought it might be helpful to
sort things out.
I did'nt look too deep
On Thursday 22 December 2005 14:57, Frederic Bouvier wrote:
> Oliver Schroeder wrote:
> > Would it help to have a generic central commandline-parser, which forces
> > developers to provide a description?
>
> Perhaps you should provide us a definition for a generic central
> commandline-parser, be
Vassilii Khachaturov wrote:
What about an option that would say "save preferences changes upon exit"?
And only save the options if it's ON? (I've first seen this in the Norton
Commander smth like over 10 years ago, very handy.) The same place could
be used to add an option to "reset to machine-w
Oliver Schroeder wrote:
> Hi List.
>
> I think that our command line processing is way to scattered and thus
> error-prone. Don't feel affronted, I just decided for myself to never touch
> anything related to commandline processing in flightgear.
>
> Would it help to have a generic central comma
Hi List.
I think that our command line processing is way to scattered and thus
error-prone. Don't feel affronted, I just decided for myself to never touch
anything related to commandline processing in flightgear.
Would it help to have a generic central commandline-parser, which forces
develo
Vivian Meazza wrote:
Further, I do NOT want the code automatically saving my changes, we should
be given the option on exit. Apart from downloading a new version of
preferences.xml, is there any way back to the default values: there should
be?
Is there an option to disable this facility? In its
> > Vivian Meazza wrote:
> > > Further, I do NOT want the code automatically saving my changes, we
> > should
> > > be given the option on exit. Apart from downloading a new version of
> > > preferences.xml, is there any way back to the default values: there
> > should
> > > be?
> > >
> >
> > Just
Vivian Meazza wrote:
Stefan Seifert
Vivian Meazza wrote:
Further, I do NOT want the code automatically saving my changes, we
should
be given the option on exit. Apart from downloading a new version of
preferences.xml, is there any way back to the default values: there
Stefan Seifert
> Vivian Meazza wrote:
> > Further, I do NOT want the code automatically saving my changes, we
> should
> > be given the option on exit. Apart from downloading a new version of
> > preferences.xml, is there any way back to the default values: there
> should
> > be?
> >
>
> Just d
Vivian Meazza wrote:
Further, I do NOT want the code automatically saving my changes, we should
be given the option on exit. Apart from downloading a new version of
preferences.xml, is there any way back to the default values: there should
be?
Just delete the generated preferences.xml?
Nine
Martin Spott
> Erik Hofman wrote:
>
> > 1. $FG_ROOT should be a global value
> > 2. ~/.fgfsrc should be a personal preference
> > 3. "fgfs --fg-root" should be a one time option overriding the defaults
> >
> > Does anybody have any objection to reversing the order?
>
> _I_ don't object, to my im
Erik Hofman wrote:
I noticed that currently $FG_ROOT has priority over --fg-root in
~/.fgfsrc(.) which in return has priority over --fg-root at
the command line.
Duh, forget it. It *is* in the right order. It's just that --fg-root got
ignored somehow. I'll investigate some further.
Erik
-
Erik Hofman wrote:
> 1. $FG_ROOT should be a global value
> 2. ~/.fgfsrc should be a personal preference
> 3. "fgfs --fg-root" should be a one time option overriding the defaults
>
> Does anybody have any objection to reversing the order?
_I_ don't object, to my impression you proposal is the on
Hi,
I noticed that currently $FG_ROOT has priority over --fg-root in
~/.fgfsrc(.) which in return has priority over --fg-root at
the command line.
To me this seems exactly opposite to what one expects. Personally I feel:
1. $FG_ROOT should be a global value
2. ~/.fgfsrc should be a persona
18 matches
Mail list logo
