RE: [Flightgear-devel] Internationalizing FlightGear.
Sounds sensible. Could the appropriate text..xml file be determined automatically in a repeatable, portable way at runtime (with optional override of course)? Perhaps if were the country code, or at least derived from it? Would this, or a similar scheme, also be suitable to localise the keyboard bindings. For instance, on my UK keyboard the engine select keys are shift-1, shift-', # and shift-4, ie engine two and three selectors are way over on the right hand side of the keyboard, " (double quote) and £ (GBP symbol) are shifted 2 and 3. I imagine that non English keyboards are even worse. Richard > -Original Message- > From: Curtis L. Olson [mailto:[EMAIL PROTECTED]] > Sent: 30 September 2002 8:46 pm > To: [EMAIL PROTECTED] > Subject: [Flightgear-devel] Internationalizing FlightGear. > > > Having given a very tiny bit of thought to 'internationalizing' > flightgear I thought perhaps a first start would be to provide > translated versions of menu.xml and options.xml > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis L. Olson wrote: > Having given a very tiny bit of thought to 'internationalizing' > flightgear I thought perhaps a first start would be to provide > translated versions of menu.xml and options.xml > > It would be nice to do this in a sensible organzied way so that when > we add a menu option to the default menu, we don't have a logistical > nightmare with maintaining the translated versions. > > Maybe something like: > > > .xml> > > > >/langauge/menu/file-text > > /langauge/menu/save-file-text > saveFlight > >. >. >. > > Then text.usa.xml (or whatever naming scheme we use) could look > something like > > > > File > Save File > > > > We could do something similar for the options.xml file. If I understand the properties load code well enough, it would be enought to have a .xml file which gets loaded after the default file, overriding everything defined in the language specific file. For example: menu.xml : File Save flight saveFlight ... menu.nl.xml would become: Bestand Vlucht opslaan ... Now we just need a loader which determines the default language and loads two files into one single root node. > > The idea would then be that we first load in the 'default' > translation, and then overwrite it with the local user specified > translation. > > This way, if a new option is added to FlightGear, the system will have > a default translation there and you don't see garbage or wierdness. > We only have to maintain one menu.xml/options.xml file and one > translations file per language. > > If an item is added to FlightGear and not translated, it will stick > out like a sore thumb and the individual translaters can add that to > their .xml file. This would countr for the above solution as well. We must keep in minf that there will be extensions to the menu.xml/options.xml files which don't affect the translation (scripting for example), so it would be nice if translations only require small language speciffic changes. > > Does this sound reasonable? Can we pull this off (or something > similar) with the property system? As far as I know, we could. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
Jim Wilson writes: > > Norman Vine <[EMAIL PROTECTED]> said: > > > If it isn't then you just need to load it before making your query to the > > elevation routine and then it should just work using a similar method to > > what Jim uses for Tower placement > > > > Actually it is used to get the ground elevation below the Aircraft (FDM) when > in tower view (or any view that is seperate from the aircraft's position). Yes that is what I meant sorry about the typo > The same method could be used to obtain ground levels for any location on the > fly, or in a batch mode. Exactly, this is what it was designed todo and how it was designed to be used but you are the only one so far to 'get it' :-) FYI - with just a slight modification to the top level routine the hitlist stuff can be used for general intersection testing. just use the appropriate eyepoint and 'ray' FWIW - I really don't understand why the FDM folks haven't been using this as I wrote it several years ago so that one could get an elevation per wheel Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Hi Curtis, hi to all, When you'll be OK on the way to translate FlightGear, I could do the french translation. I'm OK for the way below, but I couldn't have a good advice, I'm not dev ;-) Bye, Fabien Curtis L. Olson wrote: > Having given a very tiny bit of thought to 'internationalizing' > flightgear I thought perhaps a first start would be to provide > translated versions of menu.xml and options.xml > > It would be nice to do this in a sensible organzied way so that when > we add a menu option to the default menu, we don't have a logistical > nightmare with maintaining the translated versions. > > Maybe something like: > > > .xml> > > Does this sound reasonable? Can we pull this off (or something > similar) with the property system? > > Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis L. Olson wrote: > Having given a very tiny bit of thought to 'internationalizing' > flightgear I thought perhaps a first start would be to provide > translated versions of menu.xml and options.xml I'm looking forward to the Minnesotan translation. Will it sound like Prairie Home Companion, or Fargo? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Erik, THe only thing I'm concerned about is if we have 10 different menu..xml files and then we want to do some work on the GUI, the person doing this needs to make the change in 10 different places, and in 9 languages they are unfamiliar with. If we have one menu.xml file and one options.xml file, then one ".xml" file per language, then a person adding a menu option or adding a command line option only needs to add it to the one main xml file, and to the default translation file and it will then show up automatically for all other languages (although in the default language) and then it will stick out quite clearly so translaters can fix up the new additions quickly. Regards, Curt. Erik Hofman writes: > Curtis L. Olson wrote: > > Having given a very tiny bit of thought to 'internationalizing' > > flightgear I thought perhaps a first start would be to provide > > translated versions of menu.xml and options.xml > > > > It would be nice to do this in a sensible organzied way so that when > > we add a menu option to the default menu, we don't have a logistical > > nightmare with maintaining the translated versions. > > > > Maybe something like: > > > > > > .xml> > > > > > > > >/langauge/menu/file-text > > > > /langauge/menu/save-file-text > > saveFlight > > > >. > >. > >. > > > > Then text.usa.xml (or whatever naming scheme we use) could look > > something like > > > > > > > > File > > Save File > > > > > > > > We could do something similar for the options.xml file. > > If I understand the properties load code well enough, it would be > enought to have a .xml file which gets loaded after the > default file, overriding everything defined in the language specific file. > > For example: > > menu.xml : > > > > File > > Save flight > saveFlight > > > ... > > menu.nl.xml would become: > > > > Bestand > > Vlucht opslaan > > > ... > > Now we just need a loader which determines the default language and > loads two files into one single root node. > > > > > The idea would then be that we first load in the 'default' > > translation, and then overwrite it with the local user specified > > translation. > > > > This way, if a new option is added to FlightGear, the system will have > > a default translation there and you don't see garbage or wierdness. > > We only have to maintain one menu.xml/options.xml file and one > > translations file per language. > > > > If an item is added to FlightGear and not translated, it will stick > > out like a sore thumb and the individual translaters can add that to > > their .xml file. > > This would countr for the above solution as well. > We must keep in minf that there will be extensions to the > menu.xml/options.xml files which don't affect the translation (scripting > for example), so it would be nice if translations only require small > language speciffic changes. > > > > > Does this sound reasonable? Can we pull this off (or something > > similar) with the property system? > > As far as I know, we could. > > Erik > > > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
David Megginson writes: > Curtis L. Olson wrote: > > > Having given a very tiny bit of thought to 'internationalizing' > > flightgear I thought perhaps a first start would be to provide > > translated versions of menu.xml and options.xml > > I'm looking forward to the Minnesotan translation. Will it sound like > Prairie Home Companion, or Fargo? David, With the current property system, is it possible to do something like the following. In preferences.xml have an entry like: strings-fr.xml Then in menu.xml use a property value to specify the include file, something like: Then in menu.xml we could reference the strings property names (thus indirectly referencing the actual text) rather hard coding the text: /strings/file /strings/save-flight saveFlight /strings/load-flight loadFlight /strings/reset reInit The strings-fr.xml file would look something like (according to babelfish): Dossier Economiser le vol Vol de charge Remise The big thing that would need to be looked at is if we can include based on the contents of a property name, rather than just include some hard coded file name. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Internationalizing FlightGear.
Richard Bytheway writes: > Sounds sensible. > > Could the appropriate text..xml file be determined > automatically in a repeatable, portable way at runtime (with > optional override of course)? > Perhaps if were the country code, or at least derived > from it? > > Would this, or a similar scheme, also be suitable to localise the > keyboard bindings. For instance, on my UK keyboard the engine select > keys are shift-1, shift-', # and shift-4, ie engine two and three > selectors are way over on the right hand side of the keyboard, " > (double quote) and £ (GBP symbol) are shifted 2 and 3. > I imagine that non English keyboards are even worse. I bet if we could figure out the mechanism for doing text strings we could do something similar with key bindings. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Accelerations and Rates
I'm hitting a wall with my limited knowledge of calculus. Specifically, I'm looking at the following: - latitude-dot - longitude-dot - radius-dot - v-dot-local - v-dot-body - alpha-dot - beta-dot - phi-dot - theta-dot - psi-dot In flight.hxx, some of the *dot* values are referred to as 'rates', and some are referred to as 'accelerations' (i.e. rate of change in rate of change). So, here are some specific questions: 1. For those that represent angles (lat/lon/alpha/beta/phi/theta/psi), what are the units? radians/sec (rate of change), radians/sec/sec (acceleration), or something else? 2. For those that represent velecities (v-dot-local, v-dot-body), what are the units? feet/sec, feet/sec/sec, or something else? 3. Wouldn't radius-dot just be a straight-velocity (i.e. rate of change in the geocentric radius)? What's the unit in that case? I'd like to publish these as properties for the instrumentation to use, but I need to know what unit suffixes to add first. I'd also like to simplify flight.hxx, but that's a bit of a Herculean task (of the Augean-stables variety), so it will have to wait. Thanks in advance for any help, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Accelerations and Rates
David Megginson writes: > I'm hitting a wall with my limited knowledge of calculus. > Specifically, I'm looking at the following: > > - latitude-dot > - longitude-dot > - radius-dot > - v-dot-local > - v-dot-body > - alpha-dot > - beta-dot > - phi-dot > - theta-dot > - psi-dot I think "dot" means 'rate of change in' or 'derivative'. latitude-dot would be the rate of change in latitude. I.e. latitude is a position, latitude-dot is a velocity. If you had velocity-down (earth centered coordinates) then velocity-down-dot would be the change in velocity (or an acceleration.) > In flight.hxx, some of the *dot* values are referred to as 'rates', > and some are referred to as 'accelerations' (i.e. rate of change in > rate of change). So, here are some specific questions: > > 1. For those that represent angles (lat/lon/alpha/beta/phi/theta/psi), >what are the units? radians/sec (rate of change), radians/sec/sec >(acceleration), or something else? Typically we have been using the original LaRCsim units and conventions in the public fdm interface. LaRCsim parameters are defined as best as we have them defined here: http://www.flightgear.org/Docs/Flight/LaRCsim/LaRCsim-vars/LaRCsim-vars.html (This is a latex conversion of the original excel spread sheet which I don't think I have anymore.) > 2. For those that represent velecities (v-dot-local, v-dot-body), what >are the units? feet/sec, feet/sec/sec, or something else? Units are defined in the LaRCsim documentation listed above, assuming we have carried forward the original conventions. > 3. Wouldn't radius-dot just be a straight-velocity (i.e. rate of >change in the geocentric radius)? What's the unit in that case? Radius-dot would probably convert directly to vertical velocity in world coordinates. > I'd like to publish these as properties for the instrumentation to > use, but I need to know what unit suffixes to add first. I'd also > like to simplify flight.hxx, but that's a bit of a Herculean task > (of the Augean-stables variety), so it will have to wait. Sounds like you just need to point a river of properties at the problem. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis L. Olson <[EMAIL PROTECTED]> wrote : > The strings-fr.xml file would look something like (according > to babelfish): > > Dossier > Economiser le vol > Vol de charge > Remise babelfish is very funny ;-) Hopefully, someone already offered to help translating. Fichier Sauver le vol Ouvrir un vol Réinitialisation Anyway, I agree with you point. In the product I am managing in my company, we use IDENTIFIERS in the source code (here in a XML file) with a simple file name. At run-time, the file name is search in a set of include path that depends on the language tag. If IDENTIFIER can't be looked-up, the string "IDENTIFIER" is used, so we can see it is missing. I think it is also the spirit of GNU gettext but it uses plain english strings as identifiers. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Internationalizing FlightGear.
Hi, >From a user's perspective, a clever solution might be having a menu entry "Language" which defaults to English, but can be changed to French, German... The selection would then select the proper xml files for diplaying menu, messages etc. There are several programs having this, e.g. Ghostview (Windows Postscript viewer front end based on Ghostscript) just to name an example. Would this be hard to realize in FlightGear? Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Frederic BOUVIER writes:
> Curtis L. Olson <[EMAIL PROTECTED]> wrote :
>
> > The strings-fr.xml file would look something like (according
> > to babelfish):
> >
> > Dossier
> > Economiser le vol
> > Vol de charge
> > Remise
>
> babelfish is very funny ;-)
"Economiser le vol" was the funniest ("fly cheap!") -- I think that is
the funniest posting we've ever had with FlightGear. Did Curt really
got them from Babelfish, or did he have someone from the French
department at his university help him make them up.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
Norman Vine wrote: > FWIW - I really don't understand why the FDM folks haven't been using > this as I wrote it several years ago so that one could get an > elevation per wheel Landing gear struts compress, so there isn't a single point of intersection. Worse, they don't always point down. Even worse, the ground isn't always flat, so a plumb bob won't always tell you the right point even for a vertical landing gear strut. Elevation is the wrong metaphor for this problem. As is being discussed on the plib list, what is really needed is a generic vector intersection test. That would clobber both the mouse click picking problem and the gear strut test in a single blow. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Internationalizing FlightGear.
Michael Basler writes: > >From a user's perspective, a clever solution might be having a menu entry > "Language" which defaults to English, but can be changed to French, > German... The selection would then select the proper xml files for diplaying > menu, messages etc. There are several programs having this, e.g. Ghostview > (Windows Postscript viewer front end based on Ghostscript) just to name an > example. For their technical documents, the major aircraft manufacturers use something called 'effectivity' -- every pageblock, task, step etc. can have an effectivity label like For all jets with Pratt and Whitney engines. or For serial numbers 200-230. When these are put in computer-readable form, the publishing system can filter out unneeded material to create a customized manual for each airline (if they don't have any MD80's with GE engines, don't include the sections on GE engines). Language filtering is just a special case of effectivity. XML already has a simplistic mechanism for this using the pre-defined xml:lang attribute: airport Flughaven aéroport cornfield Personally, I'm not entirely happy with this. The fact is that we probably want to filter properties based not only on natural language but on operating system, GPU, resolution, input devices, and even user preferences (i.e. high/low level of detail). A general-purpose effectivity mechanism could be useful, as long as it was easy to learn and support. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Accelerations and Rates
Curtis L. Olson wrote: > http://www.flightgear.org/Docs/Flight/LaRCsim/LaRCsim-vars/LaRCsim-vars.html > > (This is a latex conversion of the original excel spread sheet which I > don't think I have anymore.) This one should be in the CVS of the Docs: ./CVS/fgfs/docs/FDM/LaRCsim/LaRCsim_generics_v_1.4.xls Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis L. Olson wrote: > Erik, > > THe only thing I'm concerned about is if we have 10 different > menu..xml files and then we want to do some work on the > GUI, the person doing this needs to make the change in 10 different > places, and in 9 languages they are unfamiliar with. > > If we have one menu.xml file and one options.xml file, then one > ".xml" file per language, then a person adding a menu > option or adding a command line option only needs to add it to the one > main xml file, and to the default translation file and it will then > show up automatically for all other languages (although in the default > language) and then it will stick out quite clearly so translaters can > fix up the new additions quickly. This is exactly what happens if you define load default file and load a language extension file containing only the translated parts. And then you have the option of loading two files, or just one file which includes the default in the first line. There is realy no difference between the two. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Accelerations and Rates
On Tue, Oct 01, 2002 at 10:18:36AM -0500, Curtis L. Olson wrote: > David Megginson writes: > > I'm hitting a wall with my limited knowledge of calculus. > > Specifically, I'm looking at the following: > > > > - latitude-dot > > - longitude-dot > > - radius-dot > > - v-dot-local > > - v-dot-body > > - alpha-dot > > - beta-dot > > - phi-dot > > - theta-dot > > - psi-dot > > I think "dot" means 'rate of change in' or 'derivative'. latitude-dot > would be the rate of change in latitude. I.e. latitude is a position, > latitude-dot is a velocity. If you had velocity-down (earth centered > coordinates) then velocity-down-dot would be the change in velocity > (or an acceleration.) latitude-dot is the rate of change of latitude but is not strictly velocity. For an angular measure, angle-dot * radius would be the (magnitude of) velocity. -- James (Jay) Treacy [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Erik Hofman writes: > Curtis L. Olson wrote: > > Erik, > > > > THe only thing I'm concerned about is if we have 10 different > > menu..xml files and then we want to do some work on the > > GUI, the person doing this needs to make the change in 10 different > > places, and in 9 languages they are unfamiliar with. > > > > If we have one menu.xml file and one options.xml file, then one > > ".xml" file per language, then a person adding a menu > > option or adding a command line option only needs to add it to the one > > main xml file, and to the default translation file and it will then > > show up automatically for all other languages (although in the default > > language) and then it will stick out quite clearly so translaters can > > fix up the new additions quickly. > > > This is exactly what happens if you define load default file and load a > language extension file containing only the translated parts. And then > you have the option of loading two files, or just one file which > includes the default in the first line. There is realy no difference > between the two. Well the difference is if you have one menu.xml for each languange, then when someone adds a new option to the default menu.xml and forgets to add it to all the other languange's menu.xml files you have a problem and you are headed towards a big mess. If you have one menu.xml file, then at least new additions will show up for people running other languages, the entries will just show up (most likely) in english. This will be a tip off that they need to go into their translations file and add an entry for the item that is coming up in english. Otherwise they won't even know something was added to the default menu.xml and they will all get out of sync (probably very quickly.) If we halt all development now and the menu.xml will never change in the future, then yes, the two approaches are pretty much equivalent. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
Andy Ross > Norman Vine wrote: > > FWIW - I really don't understand why the FDM folks haven't been using > > this as I wrote it several years ago so that one could get an > > elevation per wheel > > Landing gear struts compress, so there isn't a single point of > intersection. Worse, they don't always point down. Even worse, the > ground isn't always flat, so a plumb bob won't always tell you the > right point even for a vertical landing gear strut. > > Elevation is the wrong metaphor for this problem. As is being > discussed on the plib list, what is really needed is a generic vector > intersection test. That would clobber both the mouse click picking > problem and the gear strut test in a single blow. I understand That is why the hitlist mechanism works with a directed line segment ie a point and a direction and not a vertical vector. It just happens that the high level fgElevation routine uses a vertically directed line segment but the underlying routine certainly doesn't To keep things crystal clear I am using elevation to mean the ASL of the contact point but I agree, for me anyway it is much easier to just use the XYZ representation FYI PLib has similar routines, one for HOT and one for general intersection which also uses a directed line segment I really am beginning to wonder if anyone actually tries using the code we already have in place for doing these things !!! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis L. Olson wrote: > Erik Hofman writes: >>Curtis L. Olson wrote: >> >>>If we have one menu.xml file and one options.xml file, then one >>>".xml" file per language, then a person adding a menu >>>option or adding a command line option only needs to add it to the one >>>main xml file, and to the default translation file and it will then >>>show up automatically for all other languages (although in the default >>>language) and then it will stick out quite clearly so translaters can >>>fix up the new additions quickly. >> >> >>This is exactly what happens if you define load default file and load a >>language extension file containing only the translated parts. And then >>you have the option of loading two files, or just one file which >>includes the default in the first line. There is realy no difference >>between the two. > > Well the difference is if you have one menu.xml for each languange, > then when someone adds a new option to the default menu.xml and > forgets to add it to all the other languange's menu.xml files you have > a problem and you are headed towards a big mess. I don't get the point; 1. parts of the second xml file will *overwrite* previously read sections. 2. new parts added in the _first_ xml file will show up in English. This is what you are aiming for ins't it? Eri ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Erik Hofman writes: > I don't get the point; > > 1. parts of the second xml file will *overwrite* previously read sections. > > 2. new parts added in the _first_ xml file will show up in English. > > This is what you are aiming for ins't it? Well, ok sure, it just seems less optimal and involves more duplication and thus more opportunity to introduce human error. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Curtis L. Olson: > Well the difference is if you have one menu.xml for each languange, > then when someone adds a new option to the default menu.xml and > forgets to add it to all the other languange's menu.xml files you have > a problem and you are headed towards a big mess. This is true, but it's handlable. The way the Gnome i18n stuff works, the program is guaranteed to have american English text for everything. These strings are often hardcoded, and are used as the hash keys for translation lookups. So, in the worst case situation, a user of an internationalized program with incomplete translation sees the correct English text for the missing items. Since, sadly, this happens all the time with translated programs anyway, it's not a huge bug. :) Even better, since the translation tables are stored by themselves in (reasonably) non-threatening text files, non-technical users can go in there on their own, find the broken translation and fix it. The other big advantage to storing all the translations together per-language is that it better optimizes the work done. Typically, one person will do the translation for a single language, as Marcio has done for Portuguese. If you make them sift through all the translations for the the whole UI structure (which is probably split across many files), their task is more difficult and technical. Or stated another way: if you store the translations per-language in a single text file, the maintainer need only know English and the translation language and be able to edit an XML file. If you store it in the UI description too, then they need to understand the FlightGear UI structure as well. This shrinks the number of translators available, since they now have to be developers too. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internationalizing FlightGear.
Andy Ross writes: > This is true, but it's handlable. The way the Gnome i18n stuff works, > the program is guaranteed to have american English text for > everything. These strings are often hardcoded, and are used as the > hash keys for translation lookups. So, in the worst case situation, a > user of an internationalized program with incomplete translation sees > the correct English text for the missing items. Since, sadly, this > happens all the time with translated programs anyway, it's not a huge > bug. :) > > Even better, since the translation tables are stored by themselves in > (reasonably) non-threatening text files, non-technical users can go in > there on their own, find the broken translation and fix it. > > The other big advantage to storing all the translations together > per-language is that it better optimizes the work done. Typically, > one person will do the translation for a single language, as Marcio > has done for Portuguese. If you make them sift through all the > translations for the the whole UI structure (which is probably split > across many files), their task is more difficult and technical. > > Or stated another way: if you store the translations per-language in a > single text file, the maintainer need only know English and the > translation language and be able to edit an XML file. If you store it > in the UI description too, then they need to understand the FlightGear > UI structure as well. This shrinks the number of translators > available, since they now have to be developers too. Ok, I have set up a first stab at this and will commit it to cvs. You will need to do a cvs update both of the FlightGear source code and the FlightGear base package. This just affects the menus right now, but could/should be extended to do options.xml as well. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Accelerations and Rates
Once upon a time, you were sitting and writing: > > I think "dot" means 'rate of change in' or 'derivative'. latitude-dot > > would be the rate of change in latitude. I.e. latitude is a position, > > latitude-dot is a velocity. If you had velocity-down (earth centered > > coordinates) then velocity-down-dot would be the change in velocity > > (or an acceleration.) > > > latitude-dot is the rate of change of latitude but is not strictly > velocity. For an angular measure, angle-dot * radius would be the > (magnitude of) velocity. > There is also angular velocity, which is a velocity of a particle normalized by radii (with respect to a point, which is for this case, the center of earth). Angular acceleration defined as a time derivative of angular velocity (or second derivative of angular position). In fact, in classical (and analytical) mechanics, the terms "velocity" and "acceleration" describe rates of change of any coordinate of a system. These are "generalized" coordinates (with generalized speed and accel.). Moreover, there is also generalized momentum, which does not neccesarrily represent a linear/angular momentum (the derivative of the lagrangian by speed coordinate, for those of you who like Lagrangian mechanics). As for the question, I believe "dot" should represent a rate of change with respect to the general units of time, which are seconds (for most systems). So if X is a position in meters, and T is a time in seconds, dX/dT would be [m/s]. I know it's a silly answer though. Elady. //// (o)o) (-)-) booom ! ( ._.)(o) > < > < Elad (elady) J. Yarkoni "Elady" for friends or "Oh my God... - It's Him !" for fans (or turbofans). eMail: [EMAIL PROTECTED] WWW: http://www.ee.bgu.ac.il/~elady Dept. of ECE, BGU, Beer-Sheva, Israel, 84105. 972-8-647-2417. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
David Megginson writes: > > Norm, it depends a lot on documentation. There is far more code in > SimGear and FlightGear than most people know about or understand. > While I don't always keep it up to date, my 3-D model code and > property code gets used mainly because I provided documentation to > explain it to users. There's still a lot that I haven't had time to > document, and unsurprisingly, that's the stuff that rarely gets > touched. TEN DEEP BREATHS OK DAVID YOU ARE FULL OF IT What happened to all of the documentation that I provided for MY MATRIX routines that the 3-D Model code uses I even specifically requested that you put it back in that the routines were 'optimized' to the point that even I the author of the code had to look hard to see what the routine was actually doing TEN MORE DEEP BREATHS ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Accelerations and Rates
David Megginson writes: > > I'm hitting a wall with my limited knowledge of calculus. David You REALLY NEED to read this book !! - Original Message - From: "Norman Vine" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 30, 2002 7:23 PM Subject: [Flightgear-devel] 13.49 Maneuvering and Control of Surface and Underwater Vehicles, Fall 2000, Co > FYI > > A lot of good stuff here much of it is directly applicable > http://ocw.mit.edu/13/13.49/f00/index.html > > The book though aimed at the marine enviroment should be a good read > for any control-simulation engineer > > Norman > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Accelerations and Rates
David Megginson wrote: > In flight.hxx, some of the *dot* values are referred to as 'rates', > and some are referred to as 'accelerations' (i.e. rate of change in > rate of change). So, here are some specific questions: Strictly, the dot notataion refers to time derivative. So, if you have a variable X, "X dot" (written, unsurprisingly, as an X with a dot over it) is the same as dX/dt. "X dot dot" (two dots) is d^2X/dt^2, etc. If X refers to a position in meters, then X dot is the velocity in m/s, and X dot dot is the acceration in m/s^2, etc... This is presuming that the second is the canonical time unit (which it is). > 1. For those that represent angles (lat/lon/alpha/beta/phi/theta/psi), >what are the units? radians/sec (rate of change), radians/sec/sec >(acceleration), or something else? > > 2. For those that represent velecities (v-dot-local, v-dot-body), what >are the units? feet/sec, feet/sec/sec, or something else? > > 3. Wouldn't radius-dot just be a straight-velocity (i.e. rate of >change in the geocentric radius)? What's the unit in that case? Presumably the units are unchanged from the original. If lat/lon are in degrees, lat-dot will be in degrees per second. It's worth pointing out that there is a *lot* of duplication in the variables in flight.hxx. IMHO, the FDM's shouldn't be responsible for producing output in every coordinate system imaginable. We should just pick one and do the translations using a SimGear accessor library. For reference, YASim does all of its internal mechanics in a geocentric cartesian coordinate system. It never usees anglular measures except at the interface level. In these coordinates, the aircraft state is pleasingly simple: position: 3 doubles orientation: 9 floats (I use a matrix for simplicity; a quat would be smaller) velocity: 3 floats rotational velocity: 3 floats acceleration: 3 floats rotational acceleration: 3 floats All of the other flight.hxx output variables can be computed from these as needed. The only extra piece of information I can think of being necessary is the location of the cockpit, for the "pilot acceleration" values. But a good case could be made that the location of the cockpit is part of the 3D model, and not the FDM data anyway. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Accelerations and Rates
Andy Ross writes: > > For reference, YASim does all of its internal mechanics in a > geocentric cartesian coordinate system. It never usees anglular > measures except at the interface level. In these coordinates, the > aircraft state is pleasingly simple: > > position: 3 doubles > orientation: 9 floats (I use a matrix for simplicity; a quat would be > smaller) > velocity: 3 floats > rotational velocity: 3 floats > acceleration: 3 floats > rotational acceleration: 3 floats > Yep this is good stuff, IMO the ONLY time we should use the < lat, lon, elev > form is when we are communicating with the user, internally we should allways use the cartesian form the idea that the FDM has to convert from xyz to lat/lon for the View and the Model which in turn have to convert back into XYZ is simply extra 'error prone' busy work Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
Norman Vine writes: > What happened to all of the documentation that I provided for MY > MATRIX routines that the 3-D Model code uses A while ago I deleted some dead, commented-out code but have tried to avoid usage comments (i.e. "this function does X using parameters Y and Z and returns A") -- let me know what's missing. In any case, I was referring to out-of-line, task-oriented documentation, like fgfs-matrix-howto.html or something similar. Inline comments have some value when they can be extracted with a JavaDoc-like tool, but they generally won't help a lot. > I even specifically requested that you put it back in that the > routines were 'optimized' to the point that even I the author of > the code had to look hard to see what the routine was actually > doing Apologies if I've missed a patch. What lines need to be changed? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Accelerations and Rates
Andy Ross writes: > If X refers to a position in meters, then X dot is the velocity in > m/s, and X dot dot is the acceration in m/s^2, etc... This is > presuming that the second is the canonical time unit (which it is). So, would these property names be acceptable? /orientation/rates/angle-of-attack-rad_sec /orientation/rates/sideslip-rad_sec /orientation/rates/roll-rad_sec /orientation/rates/pitch-rad_sec /orientation/rates/heading-rad_sec /velocities/accelerations/speed-north-fps_sec /velocities/accelerations/speed-east-fps_sec /velocities/accelerations/speed-down-fps_sec /velocities/accelerations/uBody-fps_sed /velocities/accelerations/vBody-fps_sec /velocities/accelerations/wBody-fps_sec > It's worth pointing out that there is a *lot* of duplication in the > variables in flight.hxx. IMHO, the FDM's shouldn't be responsible for > producing output in every coordinate system imaginable. We should > just pick one and do the translations using a SimGear accessor > library. Agreed. We need to talk about strategies for cleaning flight.hxx up. I've made a couple of false starts but was quickly overwhelmed. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
Well hmmm... I don't think any harm was meant by David's comment. If anything he pointed out the lack of his own doc work. In any case it did take many hours to figure out how to fix that viewer problem. The only reason I did find it was because all the reported viewer bugs traced back to the ground elevation being wrong. Best, Jim Norman Vine <[EMAIL PROTECTED]> said: > What happened to all of the documentation that I provided > for MY MATRIX routines that the 3-D Model code uses > > I even specifically requested that you put it back in that > the routines were 'optimized' to the point that even I the > author of the code had to look hard to see what the routine > was actually doing > > TEN MORE DEEP BREATHS > > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
David Megginson writes: > Norman Vine writes: > > > What happened to all of the documentation that I provided for MY > > MATRIX routines that the 3-D Model code uses > > A while ago I deleted some dead, commented-out code but have tried to > avoid usage comments (i.e. "this function does X using parameters Y > and Z and returns A") -- let me know what's missing. > > In any case, I was referring to out-of-line, task-oriented > documentation, like > > fgfs-matrix-howto.html > > or something similar. Inline comments have some value when they can > be extracted with a JavaDoc-like tool, but they generally won't help a > lot. > > > I even specifically requested that you put it back in that the > > routines were 'optimized' to the point that even I the author of > > the code had to look hard to see what the routine was actually > > doing > > Apologies if I've missed a patch. What lines need to be changed? > > > All the best, > > > David > > -- > David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
David Megginson writes: > Norman Vine writes: > > > What happened to all of the documentation that I provided for MY > > MATRIX routines that the 3-D Model code uses > > > fgfs-matrix-howto.html > > or something similar. Inline comments have some value when they can > be extracted with a JavaDoc-like tool, but they generally won't help a > lot. This is all a matter of preference And IMO in your 'cleaning up' you have STRIPPED FGFS of much of it's 'real documentation'. It used to be I could use the CVS browser and see how things were before the 'grand rewrite' but the historical CVS seems to have disappeared so now we are deprived of that 'work around' also, so your standard argument "That's what we have CVS for" is no longer valid ! > > I even specifically requested that you put it back in that the > > routines were 'optimized' to the point that even I the author of > > the code had to look hard to see what the routine was actually > > doing > > What lines need to be changed? http://seneca.me.umn.edu/pipermail/flightgear-devel/2002-February/004312.htm l source-is-the-best-docs'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Documentation
Does anyone have any experience with moving from Doc++ to Doxygen? I'm thinking of making the move. Doxygen seems to be what I had hoped Doc++ would become, but seems to have stalled. It looks like many of the identifiers are the same. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
On Tue, 2002-10-01 at 10:06, Andy Ross wrote: > Norman Vine wrote: > > FWIW - I really don't understand why the FDM folks haven't been using > > this as I wrote it several years ago so that one could get an > > elevation per wheel I have to say, here, that this topic has always stirred up debate among those concerned about frame rates, so it wasn't clear to me until today that a) that code fast enough for the purpose was even there and b) that we could/should use it. > > Landing gear struts compress, so there isn't a single point of > intersection. Worse, they don't always point down. Even worse, the > ground isn't always flat, so a plumb bob won't always tell you the > right point even for a vertical landing gear strut. If you drop a plumb bob from the contact point, it will tell you the right point on the ground right at the time of contact. That's all you really need isn't it? > > Elevation is the wrong metaphor for this problem. As is being > discussed on the plib list, what is really needed is a generic vector > intersection test. That would clobber both the mouse click picking > problem and the gear strut test in a single blow. > > Andy > > -- > Andrew J. RossNextBus Information Systems > Senior Software Engineer Emeryville, CA > [EMAIL PROTECTED] http://www.nextbus.com > "Men go crazy in conflagrations. They only get better one by one." > - Sting (misquoted) > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Accelerations and Rates
On Tue, 2002-10-01 at 12:50, Andy Ross wrote: > David Megginson wrote: > > In flight.hxx, some of the *dot* values are referred to as 'rates', > > and some are referred to as 'accelerations' (i.e. rate of change in > > rate of change). So, here are some specific questions: > > Strictly, the dot notataion refers to time derivative. So, if you > have a variable X, "X dot" (written, unsurprisingly, as an X with a > dot over it) is the same as dX/dt. "X dot dot" (two dots) is > d^2X/dt^2, etc. > > If X refers to a position in meters, then X dot is the velocity in > m/s, and X dot dot is the acceration in m/s^2, etc... This is > presuming that the second is the canonical time unit (which it is). This is probably an obvious point and I really am trying to add to the discussion, but keep in mind that accels can be a displacement-dot-dot but also a velocity-dot > > > 1. For those that represent angles (lat/lon/alpha/beta/phi/theta/psi), > >what are the units? radians/sec (rate of change), radians/sec/sec > >(acceleration), or something else? > > > > 2. For those that represent velecities (v-dot-local, v-dot-body), what > >are the units? feet/sec, feet/sec/sec, or something else? > > > > 3. Wouldn't radius-dot just be a straight-velocity (i.e. rate of > >change in the geocentric radius)? What's the unit in that case? > > Presumably the units are unchanged from the original. If lat/lon are > in degrees, lat-dot will be in degrees per second. > > It's worth pointing out that there is a *lot* of duplication in the > variables in flight.hxx. IMHO, the FDM's shouldn't be responsible for > producing output in every coordinate system imaginable. We should > just pick one and do the translations using a SimGear accessor > library. > > For reference, YASim does all of its internal mechanics in a > geocentric cartesian coordinate system. It never usees anglular > measures except at the interface level. In these coordinates, the > aircraft state is pleasingly simple: > > position: 3 doubles > orientation: 9 floats (I use a matrix for simplicity; a quat would be > smaller) > velocity: 3 floats > rotational velocity: 3 floats > acceleration: 3 floats > rotational acceleration: 3 floats > > All of the other flight.hxx output variables can be computed from > these as needed. The only extra piece of information I can think of > being necessary is the location of the cockpit, for the "pilot > acceleration" values. But a good case could be made that the location > of the cockpit is part of the 3D model, and not the FDM data anyway. > > Andy > > -- > Andrew J. RossNextBus Information Systems > Senior Software Engineer Emeryville, CA > [EMAIL PROTECTED] http://www.nextbus.com > "Men go crazy in conflagrations. They only get better one by one." > - Sting (misquoted) > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Accelerations and Rates
On Tue, 2002-10-01 at 13:18, David Megginson wrote: > Andy Ross writes: > > > If X refers to a position in meters, then X dot is the velocity in > > m/s, and X dot dot is the acceration in m/s^2, etc... This is > > presuming that the second is the canonical time unit (which it is). > > So, would these property names be acceptable? > > /orientation/rates/angle-of-attack-rad_sec > /orientation/rates/sideslip-rad_sec > /orientation/rates/roll-rad_sec > /orientation/rates/pitch-rad_sec > /orientation/rates/heading-rad_sec > > /velocities/accelerations/speed-north-fps_sec > /velocities/accelerations/speed-east-fps_sec > /velocities/accelerations/speed-down-fps_sec > /velocities/accelerations/uBody-fps_sed > /velocities/accelerations/vBody-fps_sec > /velocities/accelerations/wBody-fps_sec > > > It's worth pointing out that there is a *lot* of duplication in the > > variables in flight.hxx. IMHO, the FDM's shouldn't be responsible for > > producing output in every coordinate system imaginable. We should > > just pick one and do the translations using a SimGear accessor > > library. > > Agreed. We need to talk about strategies for cleaning flight.hxx up. > I've made a couple of false starts but was quickly overwhelmed. It is, however, senseless to repeat math that's already done in the FDM's such as the transform matrices, for example. LaRCsim and JSBSim already calculate that stuff (because the implementation, not the interface, requires it). Another thing, IMO, you risk a maintenance nightmare if you spread the code that calculates aircraft state all over. Dynamics are what the FDM's do, even if its not always convenient. > > > All the best, > > > David > > -- > David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Documentation
Jon S Berndt writes: > > Does anyone have any experience with moving from Doc++ to > Doxygen? I'm thinking of making the move. Doxygen seems to > be what I had hoped Doc++ would become, but seems to have > stalled. It looks like many of the identifiers are the Jon Doxygen started life as Doc++ so just % doxygen -g see below before running this command % doxygen Doxyfile Make these changes to the generated Doxyfile substituting your $PATH of course #--- # configuration options related to the input files #--- # The INPUT tag can be used to specify the files and/or directories that contain # documented source files. You may enter file names like "myfile.cpp" or # directories like "/usr/src/myproject". Separate the files or directories # with spaces. INPUT = "/src/fg2/FlightGear/src/FDM/JSBSim" # If the value of the INPUT tag contains directories, you can use the # FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp # and *.h) to filter out the source-files in the directories. If left # blank all files are included. FILE_PATTERNS = *.cpp *.h # The RECURSIVE tag can be used to turn specify whether or not subdirectories # should be searched for input files as well. Possible values are YES and NO. # If left blank NO is used. RECURSIVE = YES ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] What Do Navaids Look Like?
Here's a good page for when we add navaid transmitters to the scenery (fairly soon): http://www.xuser.com/~daled/navaids/ All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with latest CVS code?
John, Did you do a "cvs update -d" in the base directory? Curt. John Wojnaroski writes: > Well, I was going to send Curtis the latest and greatest 3D cloud code. > > Did a fresh checkout and build of SimGear and FlightGear plus the base > package before applying the changes and running a few tests, but the program > is aborting when reading the command options line in "test" which is: > > #!/bin/sh > /usr/local/bin/fgfs --fg-root=/usr/local/FlightGear > > and reports the following > > : > : > Reading menu entries. > ./test: line 3: 23369 Aborted >/usr/local/bin/fgfs --fg-root=/usr/local/FlightGear > > This is with the CVS version prior to adding any changes or patches for the > 3D cloud code. > > Any ideas, suggestions > John W. > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] ASP PHOTO GALLERY
Norman Vine writes: > FYI > > http://www.ngs.noaa.gov/AERO/ASPphoto/aspphoto.html Very nice -- we can use these to add more taxiways and aprons. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
David Megginson writes: > Norman Vine writes: > > > It used to be I could use the CVS browser and see > > how things were before the 'grand rewrite' but the historical CVS seems > > to have disappeared so now we are deprived of that 'work around' also > > We might still be able to talk Curt into restoring the full archive. At some point I want to make an archive of all things 0.7.x, but I haven't found the time yet. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Nvidia compiler under "open source"
Hi, I'm not sure if it's new or not but I think Nvidia is getting more and more respect among Open Source comunity. They are opening the Nvidia compiler. The source code is available at: developer.nvidia.com or www.cgshaders.org -- Sergio Roth Linux user#226380 SuSE 8.0 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ASP PHOTO GALLERY
FYI http://www.ngs.noaa.gov/AERO/ASPphoto/aspphoto.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What Do Navaids Look Like?
The physics geek in me says: That's tricky stuff. (Antennas are cool) David Megginson wrote: > Here's a good page for when we add navaid transmitters to the scenery > (fairly soon): > > http://www.xuser.com/~daled/navaids/ > > All the best, > > David > > -- > David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- "The modern definition of 'racist' is someone who is winning an argument with a liberal." --Peter Brimelow ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Documentation
> Jon S Berndt writes: > > > > Does anyone have any experience with moving from Doc++ to > > Doxygen? I'm thinking of making the move. Doxygen seems to > > be what I had hoped Doc++ would become, but seems to have > > stalled. It looks like many of the identifiers are the > > Jon > > Doxygen started life as Doc++ so just > > % doxygen -g > see below before running this command > % doxygen Doxyfile > ... > ... Many thanks. I take it you have used Doxygen? I did read in the history notes of the project that it grew out of Doc++. The Doxygen web site is pretty nice - I hope I find it as easy to use as Doc++ was. Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] Documentation
Jon Berndt writes: > > Jon S Berndt writes: > > > > > > Does anyone have any experience with moving from Doc++ to > > > Doxygen? I'm thinking of making the move. Doxygen seems to > > > be what I had hoped Doc++ would become, but seems to have > > > stalled. It looks like many of the identifiers are the > > > > Jon > > > > Doxygen started life as Doc++ so just > > > > % doxygen -g > > see below before running this command > > % doxygen Doxyfile > > > ... > > ... > > Many thanks. I take it you have used Doxygen? I did read in the history > notes of the project that it grew out of Doc++. The Doxygen web site is > pretty nice - I hope I find it as easy to use as Doc++ was. For what it's worth, most of the SimGear API is documented with doxygen. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Documentation
Jon Berndt writes: > > Jon S Berndt writes: > > > > > > Does anyone have any experience with moving from Doc++ to > > > Doxygen? I'm thinking of making the move. Doxygen seems to > > > be what I had hoped Doc++ would become, but seems to have > > > stalled. It looks like many of the identifiers are the > > > > Doxygen started life as Doc++ so just > > > > % doxygen -g > > see below before running this command > > % doxygen Doxyfile > > > ... > > ... > > I take it you have used Doxygen? Nope :-) I guessed that given it's lineage the standard invocation proceedure might 'just work'. and it did ! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Documentation
> For what it's worth, most of the SimGear API is documented with > doxygen. > > Curt. I knew that - I took a look the other day and decided that Doxygen would be satisfactory. :-) Just downloaded it. I'll be trying it out. Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Problem with latest CVS code?
> John, > > Did you do a "cvs update -d" in the base directory? > Not exactly, but I did a download of the latest snapshot from rockfish and untarred the file to /usr/local/FlightGear John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with latest CVS code?
John Wojnaroski writes: > > > > > John, > > > > Did you do a "cvs update -d" in the base directory? > > > Not exactly, but I did a download of the latest snapshot from rockfish and > untarred the file to /usr/local/FlightGear There were some changes today, so you may want to grab the next snapshot that comes available. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
Norman Vine writes: > I really am beginning to wonder if anyone actually tries using > the code we already have in place for doing these things !!! Norm, it depends a lot on documentation. There is far more code in SimGear and FlightGear than most people know about or understand. While I don't always keep it up to date, my 3-D model code and property code gets used mainly because I provided documentation to explain it to users. There's still a lot that I haven't had time to document, and unsurprisingly, that's the stuff that rarely gets touched. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Back Soon...
Just to let everyone know, I haven't given up on the Spitfire model. I've been looking for new accomodation, now that's found I anticipate I'll be without internet for a 2 week period (or less). It looks like I can get ADSL this time, fingers crossed. Later, Chris. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
Norman Vine writes: > It used to be I could use the CVS browser and see > how things were before the 'grand rewrite' but the historical CVS seems > to have disappeared so now we are deprived of that 'work around' also We might still be able to talk Curt into restoring the full archive. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem with latest CVS code?
Well, I was going to send Curtis the latest and greatest 3D cloud code. Did a fresh checkout and build of SimGear and FlightGear plus the base package before applying the changes and running a few tests, but the program is aborting when reading the command options line in "test" which is: #!/bin/sh /usr/local/bin/fgfs --fg-root=/usr/local/FlightGear and reports the following : : Reading menu entries. ./test: line 3: 23369 Aborted /usr/local/bin/fgfs --fg-root=/usr/local/FlightGear This is with the CVS version prior to adding any changes or patches for the 3D cloud code. Any ideas, suggestions John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
