Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
// -*- coding: utf-8 -*-
|
|
|
|
//
|
|
|
|
// Addon.cxx --- FlightGear class holding add-on metadata
|
2018-01-01 20:03:44 +01:00
|
|
|
// Copyright (C) 2017, 2018 Florent Rougon
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
//
|
|
|
|
// This program is free software; you can redistribute it and/or modify
|
|
|
|
// it under the terms of the GNU General Public License as published by
|
|
|
|
// the Free Software Foundation; either version 2 of the License, or
|
|
|
|
// (at your option) any later version.
|
|
|
|
//
|
|
|
|
// This program is distributed in the hope that it will be useful,
|
|
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
// GNU General Public License for more details.
|
|
|
|
//
|
|
|
|
// You should have received a copy of the GNU General Public License along
|
|
|
|
// with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
// 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
|
|
|
|
2018-02-27 11:58:41 +01:00
|
|
|
#include <map>
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
#include <ostream>
|
|
|
|
#include <sstream>
|
|
|
|
#include <string>
|
|
|
|
#include <utility>
|
2017-12-12 07:51:05 +01:00
|
|
|
#include <vector>
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
|
2018-03-11 08:25:38 +01:00
|
|
|
#include <simgear/misc/sg_dir.hxx>
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
#include <simgear/misc/sg_path.hxx>
|
2018-01-10 01:00:34 +01:00
|
|
|
#include <simgear/misc/strutils.hxx>
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
#include <simgear/nasal/cppbind/Ghost.hxx>
|
|
|
|
#include <simgear/nasal/cppbind/NasalHash.hxx>
|
|
|
|
#include <simgear/nasal/naref.h>
|
2017-12-12 07:51:05 +01:00
|
|
|
#include <simgear/props/props.hxx>
|
2018-02-27 01:17:30 +01:00
|
|
|
#include <simgear/props/props_io.hxx>
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
|
2018-02-27 01:17:30 +01:00
|
|
|
#include <Main/fg_props.hxx>
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
#include <Main/globals.hxx>
|
2018-03-11 08:25:38 +01:00
|
|
|
#include <Main/util.hxx>
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
#include <Scripting/NasalSys.hxx>
|
|
|
|
|
|
|
|
#include "addon_fwd.hxx"
|
|
|
|
#include "Addon.hxx"
|
2018-01-05 16:40:11 +01:00
|
|
|
#include "AddonMetadataParser.hxx"
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
#include "AddonVersion.hxx"
|
2018-01-10 01:00:34 +01:00
|
|
|
#include "exceptions.hxx"
|
Add-ons: detailed, machine-parseable metadata for authors and maintainers
(everything described here lives in the namespace flightgear::addons)
New classes: Author, Maintainer, and Contact. Author and Maintainer
derive from Contact. For each contact, the following can be defined in
addon-metadata.xml: name, email, and url. See [1] for details about the
syntax and usage policy. Nasal bindings have been updated accordingly,
there are three new ghosts: addons.Contact, addons.Author and
addons.Maintainer.
The enum class UrlType has two new members: author and maintainer. The
Addon::getUrls() method has a new signature:
std::multimap<UrlType, QualifiedUrl> getUrls() const;
because non-empty 'url' fields for authors and maintainers contribute to
the result, and there can be an arbitrary number of authors and an
arbitrary number of maintainers defined for a given add-on---therefore,
std::map can't be used anymore.
Finally, QualifiedUrl has a new field (detail) which stores the author
name (resp. maintainer name) when the QualifiedUrl type is
UrlType::author (resp. UrlType::maintainer). Currently, this 'detail'
field is not used for other URL types, but this could be changed if
desired.
[1] https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.add-ons
2018-01-02 10:07:49 +01:00
|
|
|
#include "pointer_traits.hxx"
|
2017-12-12 07:51:05 +01:00
|
|
|
|
2018-01-10 01:00:34 +01:00
|
|
|
namespace strutils = simgear::strutils;
|
|
|
|
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
using std::string;
|
2017-12-12 07:51:05 +01:00
|
|
|
using std::vector;
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
|
|
|
|
namespace flightgear
|
|
|
|
{
|
|
|
|
|
2017-12-15 23:53:46 +01:00
|
|
|
namespace addons
|
|
|
|
{
|
|
|
|
|
2017-12-16 08:33:36 +01:00
|
|
|
// ***************************************************************************
|
|
|
|
// * QualifiedUrl *
|
|
|
|
// ***************************************************************************
|
|
|
|
|
Add-ons: detailed, machine-parseable metadata for authors and maintainers
(everything described here lives in the namespace flightgear::addons)
New classes: Author, Maintainer, and Contact. Author and Maintainer
derive from Contact. For each contact, the following can be defined in
addon-metadata.xml: name, email, and url. See [1] for details about the
syntax and usage policy. Nasal bindings have been updated accordingly,
there are three new ghosts: addons.Contact, addons.Author and
addons.Maintainer.
The enum class UrlType has two new members: author and maintainer. The
Addon::getUrls() method has a new signature:
std::multimap<UrlType, QualifiedUrl> getUrls() const;
because non-empty 'url' fields for authors and maintainers contribute to
the result, and there can be an arbitrary number of authors and an
arbitrary number of maintainers defined for a given add-on---therefore,
std::map can't be used anymore.
Finally, QualifiedUrl has a new field (detail) which stores the author
name (resp. maintainer name) when the QualifiedUrl type is
UrlType::author (resp. UrlType::maintainer). Currently, this 'detail'
field is not used for other URL types, but this could be changed if
desired.
[1] https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.add-ons
2018-01-02 10:07:49 +01:00
|
|
|
QualifiedUrl::QualifiedUrl(UrlType type, string url, string detail)
|
2017-12-16 08:33:36 +01:00
|
|
|
: _type(type),
|
Add-ons: detailed, machine-parseable metadata for authors and maintainers
(everything described here lives in the namespace flightgear::addons)
New classes: Author, Maintainer, and Contact. Author and Maintainer
derive from Contact. For each contact, the following can be defined in
addon-metadata.xml: name, email, and url. See [1] for details about the
syntax and usage policy. Nasal bindings have been updated accordingly,
there are three new ghosts: addons.Contact, addons.Author and
addons.Maintainer.
The enum class UrlType has two new members: author and maintainer. The
Addon::getUrls() method has a new signature:
std::multimap<UrlType, QualifiedUrl> getUrls() const;
because non-empty 'url' fields for authors and maintainers contribute to
the result, and there can be an arbitrary number of authors and an
arbitrary number of maintainers defined for a given add-on---therefore,
std::map can't be used anymore.
Finally, QualifiedUrl has a new field (detail) which stores the author
name (resp. maintainer name) when the QualifiedUrl type is
UrlType::author (resp. UrlType::maintainer). Currently, this 'detail'
field is not used for other URL types, but this could be changed if
desired.
[1] https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.add-ons
2018-01-02 10:07:49 +01:00
|
|
|
_url(std::move(url)),
|
|
|
|
_detail(std::move(detail))
|
2017-12-16 08:33:36 +01:00
|
|
|
{ }
|
|
|
|
|
|
|
|
UrlType QualifiedUrl::getType() const
|
|
|
|
{ return _type; }
|
|
|
|
|
|
|
|
void QualifiedUrl::setType(UrlType type)
|
|
|
|
{ _type = type; }
|
|
|
|
|
|
|
|
std::string QualifiedUrl::getUrl() const
|
|
|
|
{ return _url; }
|
|
|
|
|
|
|
|
void QualifiedUrl::setUrl(const std::string& url)
|
|
|
|
{ _url = url; }
|
|
|
|
|
Add-ons: detailed, machine-parseable metadata for authors and maintainers
(everything described here lives in the namespace flightgear::addons)
New classes: Author, Maintainer, and Contact. Author and Maintainer
derive from Contact. For each contact, the following can be defined in
addon-metadata.xml: name, email, and url. See [1] for details about the
syntax and usage policy. Nasal bindings have been updated accordingly,
there are three new ghosts: addons.Contact, addons.Author and
addons.Maintainer.
The enum class UrlType has two new members: author and maintainer. The
Addon::getUrls() method has a new signature:
std::multimap<UrlType, QualifiedUrl> getUrls() const;
because non-empty 'url' fields for authors and maintainers contribute to
the result, and there can be an arbitrary number of authors and an
arbitrary number of maintainers defined for a given add-on---therefore,
std::map can't be used anymore.
Finally, QualifiedUrl has a new field (detail) which stores the author
name (resp. maintainer name) when the QualifiedUrl type is
UrlType::author (resp. UrlType::maintainer). Currently, this 'detail'
field is not used for other URL types, but this could be changed if
desired.
[1] https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.add-ons
2018-01-02 10:07:49 +01:00
|
|
|
std::string QualifiedUrl::getDetail() const
|
|
|
|
{ return _detail; }
|
|
|
|
|
|
|
|
void QualifiedUrl::setDetail(const std::string& detail)
|
|
|
|
{ _detail = detail; }
|
|
|
|
|
2017-12-16 08:33:36 +01:00
|
|
|
// ***************************************************************************
|
|
|
|
// * Addon *
|
|
|
|
// ***************************************************************************
|
|
|
|
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
Addon::Addon(std::string id, AddonVersion version, SGPath basePath,
|
|
|
|
std::string minFGVersionRequired, std::string maxFGVersionRequired,
|
|
|
|
SGPropertyNode* addonNode)
|
|
|
|
: _id(std::move(id)),
|
2018-01-04 18:46:46 +01:00
|
|
|
_version(
|
|
|
|
shared_ptr_traits<AddonVersionRef>::makeStrongRef(std::move(version))),
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
_basePath(std::move(basePath)),
|
2018-03-11 08:25:38 +01:00
|
|
|
_storagePath(globals->get_fg_home() / ("Export/Addons/" + _id)),
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
_minFGVersionRequired(std::move(minFGVersionRequired)),
|
|
|
|
_maxFGVersionRequired(std::move(maxFGVersionRequired)),
|
|
|
|
_addonNode(addonNode)
|
|
|
|
{
|
|
|
|
if (_minFGVersionRequired.empty()) {
|
|
|
|
// This add-on metadata class appeared in FlightGear 2017.4.0
|
|
|
|
_minFGVersionRequired = "2017.4.0";
|
|
|
|
}
|
|
|
|
|
|
|
|
if (_maxFGVersionRequired.empty()) {
|
|
|
|
_maxFGVersionRequired = "none"; // special value
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string Addon::getId() const
|
|
|
|
{ return _id; }
|
|
|
|
|
|
|
|
std::string Addon::getName() const
|
|
|
|
{ return _name; }
|
|
|
|
|
|
|
|
void Addon::setName(const std::string& addonName)
|
|
|
|
{ _name = addonName; }
|
|
|
|
|
|
|
|
AddonVersionRef Addon::getVersion() const
|
|
|
|
{ return _version; }
|
|
|
|
|
|
|
|
void Addon::setVersion(const AddonVersion& addonVersion)
|
2018-01-04 18:46:46 +01:00
|
|
|
{
|
|
|
|
using ptr_traits = shared_ptr_traits<AddonVersionRef>;
|
|
|
|
_version.reset(ptr_traits::makeStrongRef(addonVersion));
|
|
|
|
}
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
|
Add-ons: detailed, machine-parseable metadata for authors and maintainers
(everything described here lives in the namespace flightgear::addons)
New classes: Author, Maintainer, and Contact. Author and Maintainer
derive from Contact. For each contact, the following can be defined in
addon-metadata.xml: name, email, and url. See [1] for details about the
syntax and usage policy. Nasal bindings have been updated accordingly,
there are three new ghosts: addons.Contact, addons.Author and
addons.Maintainer.
The enum class UrlType has two new members: author and maintainer. The
Addon::getUrls() method has a new signature:
std::multimap<UrlType, QualifiedUrl> getUrls() const;
because non-empty 'url' fields for authors and maintainers contribute to
the result, and there can be an arbitrary number of authors and an
arbitrary number of maintainers defined for a given add-on---therefore,
std::map can't be used anymore.
Finally, QualifiedUrl has a new field (detail) which stores the author
name (resp. maintainer name) when the QualifiedUrl type is
UrlType::author (resp. UrlType::maintainer). Currently, this 'detail'
field is not used for other URL types, but this could be changed if
desired.
[1] https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.add-ons
2018-01-02 10:07:49 +01:00
|
|
|
std::vector<AuthorRef> Addon::getAuthors() const
|
2017-12-12 07:51:05 +01:00
|
|
|
{ return _authors; }
|
|
|
|
|
Add-ons: detailed, machine-parseable metadata for authors and maintainers
(everything described here lives in the namespace flightgear::addons)
New classes: Author, Maintainer, and Contact. Author and Maintainer
derive from Contact. For each contact, the following can be defined in
addon-metadata.xml: name, email, and url. See [1] for details about the
syntax and usage policy. Nasal bindings have been updated accordingly,
there are three new ghosts: addons.Contact, addons.Author and
addons.Maintainer.
The enum class UrlType has two new members: author and maintainer. The
Addon::getUrls() method has a new signature:
std::multimap<UrlType, QualifiedUrl> getUrls() const;
because non-empty 'url' fields for authors and maintainers contribute to
the result, and there can be an arbitrary number of authors and an
arbitrary number of maintainers defined for a given add-on---therefore,
std::map can't be used anymore.
Finally, QualifiedUrl has a new field (detail) which stores the author
name (resp. maintainer name) when the QualifiedUrl type is
UrlType::author (resp. UrlType::maintainer). Currently, this 'detail'
field is not used for other URL types, but this could be changed if
desired.
[1] https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.add-ons
2018-01-02 10:07:49 +01:00
|
|
|
void Addon::setAuthors(const std::vector<AuthorRef>& addonAuthors)
|
2017-12-12 07:51:05 +01:00
|
|
|
{ _authors = addonAuthors; }
|
|
|
|
|
Add-ons: detailed, machine-parseable metadata for authors and maintainers
(everything described here lives in the namespace flightgear::addons)
New classes: Author, Maintainer, and Contact. Author and Maintainer
derive from Contact. For each contact, the following can be defined in
addon-metadata.xml: name, email, and url. See [1] for details about the
syntax and usage policy. Nasal bindings have been updated accordingly,
there are three new ghosts: addons.Contact, addons.Author and
addons.Maintainer.
The enum class UrlType has two new members: author and maintainer. The
Addon::getUrls() method has a new signature:
std::multimap<UrlType, QualifiedUrl> getUrls() const;
because non-empty 'url' fields for authors and maintainers contribute to
the result, and there can be an arbitrary number of authors and an
arbitrary number of maintainers defined for a given add-on---therefore,
std::map can't be used anymore.
Finally, QualifiedUrl has a new field (detail) which stores the author
name (resp. maintainer name) when the QualifiedUrl type is
UrlType::author (resp. UrlType::maintainer). Currently, this 'detail'
field is not used for other URL types, but this could be changed if
desired.
[1] https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.add-ons
2018-01-02 10:07:49 +01:00
|
|
|
std::vector<MaintainerRef> Addon::getMaintainers() const
|
2017-12-12 07:51:05 +01:00
|
|
|
{ return _maintainers; }
|
|
|
|
|
Add-ons: detailed, machine-parseable metadata for authors and maintainers
(everything described here lives in the namespace flightgear::addons)
New classes: Author, Maintainer, and Contact. Author and Maintainer
derive from Contact. For each contact, the following can be defined in
addon-metadata.xml: name, email, and url. See [1] for details about the
syntax and usage policy. Nasal bindings have been updated accordingly,
there are three new ghosts: addons.Contact, addons.Author and
addons.Maintainer.
The enum class UrlType has two new members: author and maintainer. The
Addon::getUrls() method has a new signature:
std::multimap<UrlType, QualifiedUrl> getUrls() const;
because non-empty 'url' fields for authors and maintainers contribute to
the result, and there can be an arbitrary number of authors and an
arbitrary number of maintainers defined for a given add-on---therefore,
std::map can't be used anymore.
Finally, QualifiedUrl has a new field (detail) which stores the author
name (resp. maintainer name) when the QualifiedUrl type is
UrlType::author (resp. UrlType::maintainer). Currently, this 'detail'
field is not used for other URL types, but this could be changed if
desired.
[1] https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.add-ons
2018-01-02 10:07:49 +01:00
|
|
|
void Addon::setMaintainers(const std::vector<MaintainerRef>& addonMaintainers)
|
2017-12-12 07:51:05 +01:00
|
|
|
{ _maintainers = addonMaintainers; }
|
|
|
|
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
std::string Addon::getShortDescription() const
|
|
|
|
{ return _shortDescription; }
|
|
|
|
|
|
|
|
void Addon::setShortDescription(const std::string& addonShortDescription)
|
|
|
|
{ _shortDescription = addonShortDescription; }
|
|
|
|
|
|
|
|
std::string Addon::getLongDescription() const
|
|
|
|
{ return _longDescription; }
|
|
|
|
|
|
|
|
void Addon::setLongDescription(const std::string& addonLongDescription)
|
|
|
|
{ _longDescription = addonLongDescription; }
|
|
|
|
|
2017-12-12 07:51:05 +01:00
|
|
|
std::string Addon::getLicenseDesignation() const
|
|
|
|
{ return _licenseDesignation; }
|
|
|
|
|
|
|
|
void Addon::setLicenseDesignation(const std::string& addonLicenseDesignation)
|
|
|
|
{ _licenseDesignation = addonLicenseDesignation; }
|
|
|
|
|
|
|
|
SGPath Addon::getLicenseFile() const
|
|
|
|
{ return _licenseFile; }
|
|
|
|
|
|
|
|
void Addon::setLicenseFile(const SGPath& addonLicenseFile)
|
|
|
|
{ _licenseFile = addonLicenseFile; }
|
|
|
|
|
|
|
|
std::string Addon::getLicenseUrl() const
|
|
|
|
{ return _licenseUrl; }
|
|
|
|
|
|
|
|
void Addon::setLicenseUrl(const std::string& addonLicenseUrl)
|
|
|
|
{ _licenseUrl = addonLicenseUrl; }
|
|
|
|
|
|
|
|
std::vector<std::string> Addon::getTags() const
|
|
|
|
{ return _tags; }
|
|
|
|
|
|
|
|
void Addon::setTags(const std::vector<std::string>& addonTags)
|
|
|
|
{ _tags = addonTags; }
|
|
|
|
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
SGPath Addon::getBasePath() const
|
|
|
|
{ return _basePath; }
|
|
|
|
|
|
|
|
void Addon::setBasePath(const SGPath& addonBasePath)
|
|
|
|
{ _basePath = addonBasePath; }
|
|
|
|
|
2018-03-11 08:25:38 +01:00
|
|
|
SGPath Addon::getStoragePath() const
|
|
|
|
{ return _storagePath; }
|
|
|
|
|
|
|
|
SGPath Addon::createStorageDir() const
|
|
|
|
{
|
|
|
|
if (_storagePath.exists()) {
|
|
|
|
if (!_storagePath.isDir()) {
|
|
|
|
string msg =
|
|
|
|
"Unable to create add-on storage directory because the entry already "
|
|
|
|
"exists, but is not a directory: '" + _storagePath.utf8Str() + "'";
|
|
|
|
// Log + throw, because if called from Nasal, only throwing would cause
|
|
|
|
// the exception message to 1) be truncated and 2) only appear in the
|
|
|
|
// log, not stopping the sim. Then users would have to figure out why
|
|
|
|
// their add-on doesn't work...
|
|
|
|
SG_LOG(SG_GENERAL, SG_POPUP, msg);
|
|
|
|
throw errors::unable_to_create_addon_storage_dir(msg);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
SGPath authorizedPath = fgValidatePath(_storagePath, true /* write */);
|
|
|
|
|
|
|
|
if (authorizedPath.isNull()) {
|
|
|
|
string msg =
|
|
|
|
"Unable to create add-on storage directory because of the FlightGear "
|
|
|
|
"security policy (refused by fgValidatePath()): '" +
|
|
|
|
_storagePath.utf8Str() + "'";
|
|
|
|
SG_LOG(SG_GENERAL, SG_POPUP, msg);
|
|
|
|
throw errors::unable_to_create_addon_storage_dir(msg);
|
|
|
|
} else {
|
|
|
|
simgear::Dir(authorizedPath).create(0777);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// The sensitive operation (creating the directory) is behind us; return
|
|
|
|
// _storagePath instead of authorizedPath for consistency with the
|
|
|
|
// getStoragePath() method (_storagePath and authorizedPath could be
|
|
|
|
// different in case the former contains symlink components). Further
|
|
|
|
// sensitive operations beneath _storagePath must use fgValidatePath() again
|
|
|
|
// every time, of course (otherwise attackers could use symlinks in
|
|
|
|
// _storagePath to bypass the security policy).
|
|
|
|
return _storagePath;
|
|
|
|
}
|
|
|
|
|
2018-01-10 01:00:34 +01:00
|
|
|
std::string Addon::resourcePath(const std::string& relativePath) const
|
|
|
|
{
|
|
|
|
if (strutils::starts_with(relativePath, "/")) {
|
|
|
|
throw errors::invalid_resource_path(
|
|
|
|
"addon-specific resource path '" + relativePath + "' shouldn't start "
|
|
|
|
"with a '/'");
|
|
|
|
}
|
|
|
|
|
|
|
|
return "[addon=" + getId() + "]" + relativePath;
|
|
|
|
}
|
|
|
|
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
std::string Addon::getMinFGVersionRequired() const
|
|
|
|
{ return _minFGVersionRequired; }
|
|
|
|
|
|
|
|
void Addon::setMinFGVersionRequired(const string& minFGVersionRequired)
|
|
|
|
{ _minFGVersionRequired = minFGVersionRequired; }
|
|
|
|
|
|
|
|
std::string Addon::getMaxFGVersionRequired() const
|
|
|
|
{ return _maxFGVersionRequired; }
|
|
|
|
|
|
|
|
void Addon::setMaxFGVersionRequired(const string& maxFGVersionRequired)
|
|
|
|
{
|
|
|
|
if (maxFGVersionRequired.empty()) {
|
|
|
|
_maxFGVersionRequired = "none"; // special value
|
|
|
|
} else {
|
|
|
|
_maxFGVersionRequired = maxFGVersionRequired;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string Addon::getHomePage() const
|
|
|
|
{ return _homePage; }
|
|
|
|
|
|
|
|
void Addon::setHomePage(const std::string& addonHomePage)
|
|
|
|
{ _homePage = addonHomePage; }
|
|
|
|
|
|
|
|
std::string Addon::getDownloadUrl() const
|
|
|
|
{ return _downloadUrl; }
|
|
|
|
|
|
|
|
void Addon::setDownloadUrl(const std::string& addonDownloadUrl)
|
|
|
|
{ _downloadUrl = addonDownloadUrl; }
|
|
|
|
|
|
|
|
std::string Addon::getSupportUrl() const
|
|
|
|
{ return _supportUrl; }
|
|
|
|
|
|
|
|
void Addon::setSupportUrl(const std::string& addonSupportUrl)
|
|
|
|
{ _supportUrl = addonSupportUrl; }
|
|
|
|
|
2017-12-12 07:51:05 +01:00
|
|
|
std::string Addon::getCodeRepositoryUrl() const
|
|
|
|
{ return _codeRepositoryUrl; }
|
|
|
|
|
|
|
|
void Addon::setCodeRepositoryUrl(const std::string& addonCodeRepositoryUrl)
|
|
|
|
{ _codeRepositoryUrl = addonCodeRepositoryUrl; }
|
|
|
|
|
2018-01-05 16:40:11 +01:00
|
|
|
std::string Addon::getTriggerProperty() const
|
|
|
|
{ return _triggerProperty; }
|
|
|
|
|
|
|
|
void Addon::setTriggerProperty(const std::string& addonTriggerProperty)
|
|
|
|
{ _triggerProperty = addonTriggerProperty; }
|
|
|
|
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
SGPropertyNode_ptr Addon::getAddonNode() const
|
|
|
|
{ return _addonNode; }
|
|
|
|
|
|
|
|
void Addon::setAddonNode(SGPropertyNode* addonNode)
|
|
|
|
{ _addonNode = SGPropertyNode_ptr(addonNode); }
|
|
|
|
|
|
|
|
naRef Addon::getAddonPropsNode() const
|
|
|
|
{
|
|
|
|
FGNasalSys* nas = globals->get_subsystem<FGNasalSys>();
|
|
|
|
return nas->wrappedPropsNode(_addonNode.get());
|
|
|
|
}
|
|
|
|
|
|
|
|
SGPropertyNode_ptr Addon::getLoadedFlagNode() const
|
|
|
|
{
|
|
|
|
return { _addonNode->getChild("loaded", 0, 1) };
|
|
|
|
}
|
|
|
|
|
|
|
|
int Addon::getLoadSequenceNumber() const
|
|
|
|
{ return _loadSequenceNumber; }
|
|
|
|
|
|
|
|
void Addon::setLoadSequenceNumber(int num)
|
|
|
|
{ _loadSequenceNumber = num; }
|
|
|
|
|
2018-02-27 11:58:41 +01:00
|
|
|
std::multimap<UrlType, QualifiedUrl> Addon::getUrls() const
|
|
|
|
{
|
|
|
|
std::multimap<UrlType, QualifiedUrl> res;
|
|
|
|
|
|
|
|
auto appendIfNonEmpty = [&res](UrlType type, string url, string detail = "") {
|
|
|
|
if (!url.empty()) {
|
|
|
|
res.emplace(type, QualifiedUrl(type, std::move(url), std::move(detail)));
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
for (const auto& author: _authors) {
|
|
|
|
appendIfNonEmpty(UrlType::author, author->getUrl(), author->getName());
|
|
|
|
}
|
|
|
|
|
|
|
|
for (const auto& maint: _maintainers) {
|
|
|
|
appendIfNonEmpty(UrlType::maintainer, maint->getUrl(), maint->getName());
|
|
|
|
}
|
|
|
|
|
|
|
|
appendIfNonEmpty(UrlType::homePage, getHomePage());
|
|
|
|
appendIfNonEmpty(UrlType::download, getDownloadUrl());
|
|
|
|
appendIfNonEmpty(UrlType::support, getSupportUrl());
|
|
|
|
appendIfNonEmpty(UrlType::codeRepository, getCodeRepositoryUrl());
|
|
|
|
appendIfNonEmpty(UrlType::license, getLicenseUrl());
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2018-02-27 01:17:30 +01:00
|
|
|
std::vector<SGPropertyNode_ptr> Addon::getMenubarNodes() const
|
|
|
|
{ return _menubarNodes; }
|
|
|
|
|
|
|
|
void Addon::setMenubarNodes(const std::vector<SGPropertyNode_ptr>& menubarNodes)
|
|
|
|
{ _menubarNodes = menubarNodes; }
|
|
|
|
|
|
|
|
void Addon::addToFGMenubar() const
|
|
|
|
{
|
|
|
|
SGPropertyNode* menuRootNode = fgGetNode("/sim/menubar/default", true);
|
|
|
|
|
|
|
|
for (const auto& node: getMenubarNodes()) {
|
|
|
|
SGPropertyNode* childNode = menuRootNode->addChild("menu");
|
|
|
|
::copyProperties(node.ptr(), childNode);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
std::string Addon::str() const
|
|
|
|
{
|
|
|
|
std::ostringstream oss;
|
|
|
|
oss << "addon '" << _id << "' (version = " << *_version
|
|
|
|
<< ", base path = '" << _basePath.utf8Str()
|
|
|
|
<< "', minFGVersionRequired = '" << _minFGVersionRequired
|
|
|
|
<< "', maxFGVersionRequired = '" << _maxFGVersionRequired << "')";
|
|
|
|
|
|
|
|
return oss.str();
|
|
|
|
}
|
|
|
|
|
2017-12-12 07:51:05 +01:00
|
|
|
// Static method
|
|
|
|
SGPath Addon::getMetadataFile(const SGPath& addonPath)
|
|
|
|
{
|
2018-01-05 16:40:11 +01:00
|
|
|
return MetadataParser::getMetadataFile(addonPath);
|
2017-12-12 07:51:05 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
SGPath Addon::getMetadataFile() const
|
|
|
|
{
|
|
|
|
return getMetadataFile(getBasePath());
|
|
|
|
}
|
|
|
|
|
|
|
|
// Static method
|
|
|
|
Addon Addon::fromAddonDir(const SGPath& addonPath)
|
|
|
|
{
|
2018-01-05 16:40:11 +01:00
|
|
|
Addon::Metadata metadata = MetadataParser::parseMetadataFile(addonPath);
|
2017-12-12 07:51:05 +01:00
|
|
|
|
|
|
|
// Object holding all the add-on metadata
|
2018-01-05 16:40:11 +01:00
|
|
|
Addon addon{std::move(metadata.id), std::move(metadata.version), addonPath,
|
|
|
|
std::move(metadata.minFGVersionRequired),
|
|
|
|
std::move(metadata.maxFGVersionRequired)};
|
|
|
|
addon.setName(std::move(metadata.name));
|
|
|
|
addon.setAuthors(std::move(metadata.authors));
|
|
|
|
addon.setMaintainers(std::move(metadata.maintainers));
|
|
|
|
addon.setShortDescription(std::move(metadata.shortDescription));
|
|
|
|
addon.setLongDescription(std::move(metadata.longDescription));
|
|
|
|
addon.setLicenseDesignation(std::move(metadata.licenseDesignation));
|
|
|
|
addon.setLicenseFile(std::move(metadata.licenseFile));
|
|
|
|
addon.setLicenseUrl(std::move(metadata.licenseUrl));
|
|
|
|
addon.setTags(std::move(metadata.tags));
|
|
|
|
addon.setHomePage(std::move(metadata.homePage));
|
|
|
|
addon.setDownloadUrl(std::move(metadata.downloadUrl));
|
|
|
|
addon.setSupportUrl(std::move(metadata.supportUrl));
|
|
|
|
addon.setCodeRepositoryUrl(std::move(metadata.codeRepositoryUrl));
|
2018-01-09 12:42:47 +01:00
|
|
|
|
2018-02-27 01:17:30 +01:00
|
|
|
SGPath menuFile = addonPath / "addon-menubar-items.xml";
|
|
|
|
|
|
|
|
if (menuFile.exists()) {
|
|
|
|
addon.setMenubarNodes(readMenubarItems(menuFile));
|
|
|
|
}
|
|
|
|
|
2017-12-12 07:51:05 +01:00
|
|
|
return addon;
|
|
|
|
}
|
|
|
|
|
2018-02-27 01:17:30 +01:00
|
|
|
// Static method
|
|
|
|
std::vector<SGPropertyNode_ptr>
|
|
|
|
Addon::readMenubarItems(const SGPath& menuFile)
|
|
|
|
{
|
|
|
|
SGPropertyNode rootNode;
|
|
|
|
|
|
|
|
try {
|
|
|
|
readProperties(menuFile, &rootNode);
|
|
|
|
} catch (const sg_exception &e) {
|
|
|
|
throw errors::error_loading_menubar_items_file(
|
|
|
|
"unable to load add-on menu bar items from file '" +
|
|
|
|
menuFile.utf8Str() + "': " + e.getFormattedMessage());
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check the 'meta' section
|
|
|
|
SGPropertyNode *metaNode = rootNode.getChild("meta");
|
|
|
|
if (metaNode == nullptr) {
|
|
|
|
throw errors::error_loading_menubar_items_file(
|
|
|
|
"no /meta node found in add-on menu bar items file '" +
|
|
|
|
menuFile.utf8Str() + "'");
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check the file type
|
|
|
|
SGPropertyNode *fileTypeNode = metaNode->getChild("file-type");
|
|
|
|
if (fileTypeNode == nullptr) {
|
|
|
|
throw errors::error_loading_menubar_items_file(
|
|
|
|
"no /meta/file-type node found in add-on menu bar items file '" +
|
|
|
|
menuFile.utf8Str() + "'");
|
|
|
|
}
|
|
|
|
|
|
|
|
string fileType = fileTypeNode->getStringValue();
|
|
|
|
if (fileType != "FlightGear add-on menu bar items") {
|
|
|
|
throw errors::error_loading_menubar_items_file(
|
|
|
|
"Invalid /meta/file-type value for add-on menu bar items file '" +
|
|
|
|
menuFile.utf8Str() + "': '" + fileType + "' "
|
|
|
|
"(expected 'FlightGear add-on menu bar items')");
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check the format version
|
|
|
|
SGPropertyNode *fmtVersionNode = metaNode->getChild("format-version");
|
|
|
|
if (fmtVersionNode == nullptr) {
|
|
|
|
throw errors::error_loading_menubar_items_file(
|
|
|
|
"no /meta/format-version node found in add-on menu bar items file '" +
|
|
|
|
menuFile.utf8Str() + "'");
|
|
|
|
}
|
|
|
|
|
|
|
|
int formatVersion = fmtVersionNode->getIntValue();
|
|
|
|
if (formatVersion != 1) {
|
|
|
|
throw errors::error_loading_menubar_items_file(
|
|
|
|
"unknown format version in add-on menu bar items file '" +
|
|
|
|
menuFile.utf8Str() + "': " + std::to_string(formatVersion));
|
|
|
|
}
|
|
|
|
|
|
|
|
SG_LOG(SG_GENERAL, SG_DEBUG,
|
|
|
|
"Loaded add-on menu bar items from '" << menuFile.utf8Str() + "'");
|
|
|
|
|
|
|
|
SGPropertyNode *menubarItemsNode = rootNode.getChild("menubar-items");
|
|
|
|
std::vector<SGPropertyNode_ptr> res;
|
|
|
|
|
|
|
|
if (menubarItemsNode != nullptr) {
|
|
|
|
res = menubarItemsNode->getChildren("menu");
|
|
|
|
}
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
// Static method
|
|
|
|
void Addon::setupGhost(nasal::Hash& addonsModule)
|
|
|
|
{
|
|
|
|
nasal::Ghost<AddonRef>::init("addons.Addon")
|
|
|
|
.member("id", &Addon::getId)
|
|
|
|
.member("name", &Addon::getName)
|
|
|
|
.member("version", &Addon::getVersion)
|
2017-12-12 07:51:05 +01:00
|
|
|
.member("authors", &Addon::getAuthors)
|
|
|
|
.member("maintainers", &Addon::getMaintainers)
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
.member("shortDescription", &Addon::getShortDescription)
|
|
|
|
.member("longDescription", &Addon::getLongDescription)
|
2017-12-12 07:51:05 +01:00
|
|
|
.member("licenseDesignation", &Addon::getLicenseDesignation)
|
|
|
|
.member("licenseFile", &Addon::getLicenseFile)
|
|
|
|
.member("licenseUrl", &Addon::getLicenseUrl)
|
|
|
|
.member("tags", &Addon::getTags)
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
.member("basePath", &Addon::getBasePath)
|
2018-03-11 08:25:38 +01:00
|
|
|
.member("storagePath", &Addon::getStoragePath)
|
|
|
|
.method("createStorageDir", &Addon::createStorageDir)
|
2018-01-10 01:00:34 +01:00
|
|
|
.method("resourcePath", &Addon::resourcePath)
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
.member("minFGVersionRequired", &Addon::getMinFGVersionRequired)
|
|
|
|
.member("maxFGVersionRequired", &Addon::getMaxFGVersionRequired)
|
|
|
|
.member("homePage", &Addon::getHomePage)
|
|
|
|
.member("downloadUrl", &Addon::getDownloadUrl)
|
|
|
|
.member("supportUrl", &Addon::getSupportUrl)
|
2017-12-12 07:51:05 +01:00
|
|
|
.member("codeRepositoryUrl", &Addon::getCodeRepositoryUrl)
|
2018-01-05 16:40:11 +01:00
|
|
|
.member("triggerProperty", &Addon::getTriggerProperty)
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
.member("node", &Addon::getAddonPropsNode)
|
|
|
|
.member("loadSequenceNumber", &Addon::getLoadSequenceNumber);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::ostream& operator<<(std::ostream& os, const Addon& addon)
|
|
|
|
{
|
|
|
|
return os << addon.str();
|
|
|
|
}
|
|
|
|
|
2017-12-15 23:53:46 +01:00
|
|
|
} // of namespace addons
|
|
|
|
|
Improved infrastructure for add-ons: C++ classes, metadata file, Nasal interface
This commit adds C++ classes for add-on management, most notably
AddonManager, Addon and AddonVersion. The AddonManager is used to
register add-ons. It relies on an std::map<std::string, AddonRef> to
hold the metadata of each registered add-on (keys of the std::map are
add-on identifiers, and AddonRef is currently SGSharedPtr<Addon>).
Accessor methods are available for:
- retrieving the list of registered or loaded add-ons (terminology
explained in $FG_ROOT/Docs/README.add-ons);
- checking if a particular add-on has already been registered or
loaded;
- for each add-on, obtaining an Addon instance which can be queried
for its name, id, version, base path, the minimum and maximum
FlightGear versions it requires, its base node in the Property Tree,
its order in the load sequence, short and long description strings,
home page, etc.
The most important metadata is made accessible in the Property Tree
under /addons/by-id/<addon-id> and the property
/addons/by-id/<addon-id>/loaded can be checked or listened to, in
order to determine when a particular add-on is loaded. There is also a
Nasal interface to access add-on metadata in a convenient way.
In order to provide this metadata, each add-on must from now on have in
its base directory a file called 'addon-metadata.xml'.
All this is documented in much more detail in
$FG_ROOT/Docs/README.add-ons.
Mailing-list discussion:
https://sourceforge.net/p/flightgear/mailman/message/36146017/
2017-11-06 13:58:14 +01:00
|
|
|
} // of namespace flightgear
|