fly/flightgear
1
0
Fork 0
Code Activity

Add-ons: more specific file names for the interface between FG core and add-ons

Browse source 
The add-on framework now uses the following files in each add-on
directory:
  - addon-config.xml (previously: config.xml)
  - addon-main.nas   (previously: main.nas)

This is consistent with the addon-metadata.xml file that is already part
of the interface between FG core and add-ons. The goal is to make it
clearer, when browsing an add-on directory, which files belong to the
"FG core <-> add-on" interface and which files belong to the add-on
proper. This will be beneficial also when more files are added to the
"FG core <-> add-on" interface, such as possibly addon-events.xml in the
future.

This change is incompatible, thus it is the right time to do *before*
2018.2.1 is out, especially considering that this upcoming release
already has incompatible changes in the add-on API, namely the
requirement of the addon-metadata.xml file and the type of the argument
passed to each add-on's main() function. We'll try harder not to break
compatibility in the add-on API once 2018.2.1 is out. For now, it is
still a good time to try to get the API as clean as possible.
This commit is contained in:
Florent Rougon 2018-02-10 19:18:49 +01:00
parent 5aae639a0d
commit da961b97f2
3 changed files with 14 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
src/Add-ons/AddonManager.cxx
View file

@ -161,7 +161,7 @@ AddonManager::registerAddon(const SGPath& addonPath)
// one of its components is a symlink.
const SGPath addonRealPath = addonPath.realpath();
const string addonId = registerAddonMetadata(addonRealPath);
loadConfigFileIfExists(addonRealPath / "config.xml");
loadConfigFileIfExists(addonRealPath / "addon-config.xml");
globals->append_aircraft_path(addonRealPath);
AddonRef addon{getAddon(addonId)};

8
src/Add-ons/AddonManager.hxx
View file

@ -62,7 +62,7 @@ public:
// This comprises the following steps, where $path = addonPath.realpath():
// - load add-on metadata from $path/addon-metadata.xml and register it
// inside _idToAddonMap (this step is done via registerAddonMetadata());
// - load $path/config.xml into the Property Tree;
// - load $path/addon-config.xml into the Property Tree;
// - append $path to the list of aircraft paths;
// - make part of the add-on metadata available in the Property Tree under
// the /addons node (/addons/by-id/<addonId>/{id,version,path,...});
@ -73,9 +73,9 @@ public:
std::vector<AddonRef> registeredAddons() const;
bool isAddonRegistered(const std::string& addonId) const;
// A loaded add-on is one whose main.nas file has been loaded. The returned
// vector is sorted by add-on id (cheap sorting based on UTF-8 code units,
// only guaranteed correct for ASCII chars).
// A loaded add-on is one whose addon-main.nas file has been loaded. The
// returned vector is sorted by add-on id (cheap sorting based on UTF-8 code
// units, only guaranteed correct for ASCII chars).
std::vector<AddonRef> loadedAddons() const;
bool isAddonLoaded(const std::string& addonId) const;

13
src/Main/options.cxx
View file

@ -696,12 +696,17 @@ clearLocation ()
}
/*
Using --addon=/foo/bar does:
- load /foo/bar/config.xml into the Global Property Tree;
Using --addon=/foo/bar does:
- register the add-on with the AddonManager (enabling, among other things,
add-on-specific resources for simgear::ResourceManager);
- load /foo/bar/addon-config.xml into the Global Property Tree;
- add /foo/bar to the list of aircraft paths to provide read access:
- set property /addons/addon[n]/path = "/foo/bar".
- set various properties related to the add-on under /addons;
- load /foo/bar/addon-main.nas into namespace __addon[ADDON_ID]__
(see $FG_ROOT/Nasal/addons.nas);
- call the main() function defined in that file.
Addons get initialized from addons.nas in FGData/Nasal.
For more details, see $FG_ROOT/Docs/README.add-ons.
*/
static int
fgOptAddon(const char *arg)