diff --git a/Docs/README.add-ons b/Docs/README.add-ons index d4e3aa74f..1fabb7a1b 100644 --- a/Docs/README.add-ons +++ b/Docs/README.add-ons @@ -121,7 +121,7 @@ Sample addon-metadata.xml file ============================== Here is an example of an addon-metadata.xml file, for a hypothetical -add-on called "Flying Turtle" distributed by Joe User: +add-on called “Flying Turtle” distributed by Joe User: @@ -212,7 +212,7 @@ add-on called "Flying Turtle" distributed by Joe User: General rules ============= -We use the terms "field" or "node" interchangeably here to refer to +We use the terms “field” or “node” interchangeably here to refer to nodes of the addon-metadata.xml PropertyList file (technically, a field always has a value, possibly empty, therefore fields are all leaf nodes). @@ -236,7 +236,7 @@ otherwise isn't constrained. On the other hand, the add-on identifier - must contain only ASCII letters (A-Z, a-z) and dots ('.'); - must be in reverse DNS style (even if the domain doesn't exist), e.g., org.flightgear.addons.ATCChatter for an add-on distributed in - FGAddon, or user.joe.FlyingTurtle for Joe User's "Flying Turtle" + FGAddon, or user.joe.FlyingTurtle for Joe User's “Flying Turtle” add-on. Of course, if Joe User owns a domain name and uses it to distribute his add-on, he should put it here. @@ -262,7 +262,7 @@ contacting the add-on maintainers. The data in children nodes of /addon/maintainers may refer either to real persons or to more abstract entities such as mailing-lists. In case of a real person, the corresponding URL, if specified, is expected to be -the person's home page. On the other hand, if a declared "maintainer" is +the person's home page. On the other hand, if a declared “maintainer” is a mailing-list, a good use for the 'url' field is to indicate the address of a web page from which people can subscribe to the mailing-list. @@ -285,13 +285,9 @@ means a hard line break. Two \n in a row (i.e., a blank line) should be used to separate paragraphs. Example: This is a paragraph. -This is the second line of the same paragraph. It can be very, very, very -long and contain several sentences. +This is the second line of the same paragraph. It can be very, very, very long and contain several sentences. -This is a different paragraph. Again, don't break lines (i.e., don't press -Enter) unless a particular formatting reason makes it necessary. For instance, -it is okay to break lines in order to present a list of items, but not for -line wrapping. +This is a different paragraph. Again, don't break lines (i.e., don't press Enter) unless a particular formatting reason makes it necessary. For instance, it is okay to break lines in order to present a list of items, but not for line wrapping. Licensing terms =============== @@ -302,12 +298,12 @@ Nodes: /addon/license/designation The /add-on/license/designation node should describe the add-on licensing terms in a short but accurate way, if possible. If this is not -practically doable, use the value "Custom". If the add-on is distributed -under several licenses, use the value "Multiple". In all cases, make +practically doable, use the value “Custom”. If the add-on is distributed +under several licenses, use the value “Multiple”. In all cases, make sure the licensing terms are clearly specified in other files of the add-on (typically, at least README.txt or COPYING). Values for -/add-on/license/designation could be "GNU GPL version 2 or later", "CC0 -1.0 Universal", "3-clause BSD", etc. +/add-on/license/designation could be “GNU GPL version 2 or later”, “CC0 +1.0 Universal”, “3-clause BSD”, etc. In most cases, the add-on should contain a file containing the full license text. Use the /add-on/license/file node to point to this file: @@ -317,7 +313,7 @@ Windows. The /add-on/license/url node should contain a single URL if there is an official, stable URL for the license under which the add-on is -distributed. The term "official" here is to be interpreted in the +distributed. The term “official” here is to be interpreted in the context of the particular license. For instance, for a GNU license (GPL2, LGPL2.1, etc.), the URL domain must be gnu.org; for a CC license (CC0 1.0 Universal, CC-BY-SA 4.0...), it must be creativecommons.org, @@ -452,7 +448,7 @@ button.png, system.xml, etc.). The [addon=ADDON_ID]relative/path syntax is useful where resources are specified inside non-Nasal files (e.g., in property-rule configuration files, which use the XML format). For the particular case of Nasal code, -there is a better way that is explained below (see "Nasal API"): the +there is a better way that is explained below (see “Nasal API”): the resourcePath() method of addons.Addon objects returns a string like "[addon=ADDON_ID]relative/path" when you pass it the string "relative/path". This is a good thing to use, because then your Nasal @@ -740,7 +736,7 @@ Queries to the AddonManager: Read-only data members (attributes) of addons.Addon objects: id the add-on identifier, in reverse DNS style (string) - name the add-on "pretty name" (string) + name the add-on “pretty name” (string) version the add-on version (instance of addons.AddonVersion, ghost) authors the add-on authors (vector of addons.Author ghosts) diff --git a/Docs/README.effects b/Docs/README.effects index ce8acc274..d535de66a 100644 --- a/Docs/README.effects +++ b/Docs/README.effects @@ -217,8 +217,7 @@ texture-unit - has several child properties: color texenv-combine - combine-[rgb|alpha] - replace, modulate, add, add-signed, interpolate, subtract, dot3-rgb, - dot3-rgba + combine-[rgb|alpha] - replace, modulate, add, add-signed, interpolate, subtract, dot3-rgb, dot3-rgba source[0|1|2]-[rgb|alpha] - constant, primary_color, previous, texture, texture[0-7] operand[0|1|2]-[rgb|alpha] -src-color, one-minus-src-color, src-alpha, one-minus-src-alpha scale-[rgb|alpha] diff --git a/Docs/README.embedded-resources b/Docs/README.embedded-resources index 7c4807138..fa2457d38 100644 --- a/Docs/README.embedded-resources +++ b/Docs/README.embedded-resources @@ -13,7 +13,7 @@ Contents -------- 1. The CharArrayStream and ZlibStream classes -2. The "embedded resources" system +2. The “embedded resources” system 3. About the XML resource declaration files 4. The EmbeddedResourceProxy class @@ -24,7 +24,7 @@ Introduction The embedded resources system allows FlightGear to use data from files without relying on FG_ROOT to be set. This can be used, for instance, to grab the contents of XML files at FG build time, from any repository[1], -and use said contents in the C++ code. The term "embedded" is used to +and use said contents in the C++ code. The term “embedded” is used to avoid confusion with the ResourceProvider and ResourceManager classes provided by SimGear, which have nothing to do with the system described here. @@ -41,7 +41,7 @@ transparently. So, there is really no reason to worry about memory consumption, even for several dozens of XML files. fgrcc is the resource compiler: it turns arbitrary files into C++ code -the EmbeddedResourceManager can make use of, in order to "serve" the +the EmbeddedResourceManager can make use of, in order to “serve” the files' contents at runtime. It is named this way, because it fulfills the same role as Qt's rcc tool. It supports a thin superset of the XML-based format used by rcc for declaring resources[2][3]. @@ -104,7 +104,7 @@ interesting with compressed resources, because: 1) The in-memory static data is much smaller in general than the uncompressed contents, and it's the only one we really have to - "pay" for if one uses these stream-based interfaces. + “pay” for if one uses these stream-based interfaces. 2) The data is transparently decompressed on-demand as the end-user code reads from the ZlibDecompressorIStream or @@ -141,7 +141,7 @@ handle text and binary data in exactly the same way (std::string doesn't care, and neither do the other classes). -2) The "embedded resources" system +2) The “embedded resources” system ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The embedded resources system works this way: @@ -223,28 +223,28 @@ The embedded resources system works this way: EmbeddedResourceManager code in SimGear is so far completely agnostic of the kind of data stored in keys; this could be changed, though, if we wanted for example to be able to query - at runtime all available resources in a given "virtual - directory"); + at runtime all available resources in a given “virtual + directory”); - - a "locale" name, similar to what FlightGear's XML translation + - a “locale” name, similar to what FlightGear's XML translation files and FGLocale use. We used double quotes here, because - fgrcc and the EmbeddedResourceManager expect "locale" names to + fgrcc and the EmbeddedResourceManager expect “locale” names to be of one of these forms: * empty string: default locale, typically but not necessarily - English (it is "engineering English" in FlightGear, i.e., + English (it is “engineering English” in FlightGear, i.e., English written by programmers in the code, before translators possibly fix it up :) * en, fr, de, es, it... * en_GB, en_US, fr_FR, fr_CA, de_DE, de_CH, it_IT... There is no encoding part, contrary to POSIX locales, hence the - use of double quotes around the term "locale" in this context. + use of double quotes around the term “locale” in this context. The FGLocale::getPreferredLanguage() method returns the preferred - "locale" in the form described above, according to user choice + “locale” in the form described above, according to user choice (from fgfs' --language option) and/or settings (system locale). This allows FG to tell the EmbeddedResourceManager the preferred - "locale" for resource fetching (same syntax as in Qt's rcc tool for + “locale” for resource fetching (same syntax as in Qt's rcc tool for declaration in the XML file, using the 'lang' attribute on 'qresource' elements). @@ -266,9 +266,9 @@ The embedded resources system works this way: getResource(), getString(), getStreambuf() and getIStream()) has two overloads: - one taking only a virtual path (the key mentioned above); - - one taking a virtual path and a "locale" name. + - one taking a virtual path and a “locale” name. - (we'll write "locale" without enclosing double-quotes from now on, + (we'll write “locale” without enclosing double-quotes from now on, otherwise it gets too painful to read; but we're *not* talking about POSIX-style locales ending with an encoding part) @@ -445,15 +445,13 @@ Footnotes this would be, compared to having the files loaded from $FG_ROOT. Well, maybe for large files [apt.dat.gz & Co] that we would want to load but not see in the FGData repository at all. But then there - would be the requirement, of course, that "something" puts the files + would be the requirement, of course, that “something” puts the files in a clearly-defined, platform-dependent location known to the EmbeddedResourceManager. -[6] https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/python3-flightgear/ - rebuild-fgdata-embedded-resources +[6] https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/python3-flightgear/rebuild-fgdata-embedded-resources -[7] https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/ - embedded_resources/ +[7] https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/embedded_resources/ [8] We know that in some buggy C++ implementations, the std::ios_base::failure exception can't be caught, at least not under @@ -471,8 +469,6 @@ Footnotes 'i18n-and-init-work-v2' branch (not merged into 'next' at the time of this writing). -[10] https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/ - embedded_resources/EmbeddedResourceProxy.hxx +[10] https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/embedded_resources/EmbeddedResourceProxy.hxx -[11] https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/ - embedded_resources/embedded_resources_test.cxx +[11] https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/embedded_resources/embedded_resources_test.cxx diff --git a/Docs/README.mingw b/Docs/README.mingw index b0d47bf75..757cd9512 100644 --- a/Docs/README.mingw +++ b/Docs/README.mingw @@ -79,8 +79,7 @@ The header has to be updated with respect to MINGW. /* XXX This is from Win32's */ # ifndef APIENTRY # define GLUT_APIENTRY_DEFINED -! # if (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED) || defined(__BORLANDC__) || - defined(__LCC__) +! # if (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED) || defined(__BORLANDC__) || defined(__LCC__) # define APIENTRY __stdcall # else # define APIENTRY @@ -88,8 +87,7 @@ The header has to be updated with respect to MINGW. /* XXX This is from Win32's */ # ifndef APIENTRY # define GLUT_APIENTRY_DEFINED -! # if (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED) || defined(__BORLANDC__) || - defined(__LCC__) || defined(__MINGW32__) +! # if (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED) || defined(__BORLANDC__) || defined(__LCC__) || defined(__MINGW32__) # define APIENTRY __stdcall # else # define APIENTRY diff --git a/Docs/README.osgtext b/Docs/README.osgtext index 8a807319d..0070d3708 100644 --- a/Docs/README.osgtext +++ b/Docs/README.osgtext @@ -56,8 +56,7 @@ For the anxious reader, here is a complete example of a text node: --> true - - false + false false led.txf diff --git a/Docs/README.systems b/Docs/README.systems index 94ec3df26..95c11b29b 100644 --- a/Docs/README.systems +++ b/Docs/README.systems @@ -110,14 +110,13 @@ on an AN5812 pitot tube. ** The STATIC system The static system measures the static pressure. So all influences of airspeed are eliminated. -In real life this is however not always easy. Effects from angle of attack, side-slip, flap -defection, gear extension, engine power setting and airspeed are present and for the aircraft +In real life this is however not always easy. Effects from angle of attack, side-slip, flap defection, +gear extension, engine power setting and airspeed are present and for the aircraft designer it is not alway easy to find a good position for the static port. Usually the number of static systems are equal to the number of pitot systems. In Flightgear there are 3 types of static systems modelled. Type 0 (default): the perfect sensor. No measurement failures. -Type 1: Dual static ports on the fuselage sides. Side-slip angle influence only. this model - the whole pair. +Type 1: Dual static ports on the fuselage sides. Side-slip angle influence only. this model the whole pair. Type 2: Static port on the pitot tube. Both angle of attack and side-slip influence. If you want to use type 1 or 2: @@ -127,8 +126,8 @@ If you want to use type 1 or 2: 1 0.5 -The output property /systems/static[n]/pressure-inhg is filtered. Therefore, if you want to -see the effect of the measurement failure, "tau" should be 0.1 or smaller. +The output property /systems/static[n]/pressure-inhg is filtered. Therefore, if you want to see +the effect of the measurement failure, "tau" should be 0.1 or smaller. The "error-factor" should be between 0.2 and 0.7. Setting it to 0 equals a "perfect sensor". A setting of 1 means the whole (projected on static port face) impact pressure is applied. This is not realistic as usually there are more than one static pick-up points diff --git a/Docs/README.xmlhud b/Docs/README.xmlhud index b26c70a06..edac8c4bc 100644 --- a/Docs/README.xmlhud +++ b/Docs/README.xmlhud @@ -176,29 +176,17 @@ Example of Hud Ladder xml file. 70 0 false - - true - - false - - false - - false - - false - - false - - false - - 0.0 - - false - - false - - true + true + false + false + false + false + false + false + 0.0 + false + false + true @@ -224,8 +212,7 @@ Example of Hud Card xml file. 430 200 28 - heading + heading 4 360.0 0.0 @@ -245,8 +232,7 @@ Example of Hud Card xml file. false 0.0 true - fixed + fixed true @@ -336,21 +322,17 @@ Example of a Label xml file. 130 40 30 - mach + mach %4.2f blank NULL 1.0 4 - 2 + 2 0 true - false - false + false + false @@ -370,10 +352,8 @@ Example of a Turn Bank Indicator xml file. 45 60 10 - roll - sideslip + roll + sideslip 45.0 5.0 5 @@ -387,8 +367,8 @@ Example of a Turn Bank Indicator xml file. I have still got to implement dials (as in MIL-STD-1787b). REMEMBER IF YOU NEED TO INDICATE ANY OTHER PARAMETER ON THE HUD OTHER THAN WHAT IS PROVIDED AS -CALLBACK FUNCTIONS (PROPERTY NAMES LISTED BELOW) YOU HAVE TO FIDDLE WITH THE CODE, AS YET. LET -ME KNOW AND I SHALL INCLUDE THAT. +CALLBACK FUNCTIONS (PROPERTY NAMES LISTED BELOW) YOU HAVE TO FIDDLE WITH THE CODE, AS YET. LET ME +KNOW AND I SHALL INCLUDE THAT. anzg heading