Plugin now inherits from PluginInterface, and Plugin objects are now
immutable and cached in shared_ptr objects. The Plugin class no longer
inherits from PluginMetadata, so file data and metadata are kept
separate and only brought together temporarily when sorting.
Sorting no longer evaluates conditions and checks install validity, so
such actions need to be performed before sorting (the validity checking
isn't, as the data gets reloaded just before sorting) or after it.
It should now be possible to reimplement the GUI using the API, though
there are probably still a few holes in the API.
DatabaseInterface is now accessed through it, and IdentifyMainMasterFile
and SortPlugins have moved to it. GameInterface also deals with load
order access.
This is obviously a breaking change, but it's a cleaner structure than
just continuing to stuff everything in DatabaseInterface, and there
needs to be some relation between GameInterface and it.
So that the API doesn't expose any references to the Game class.
Evaluation is now done in the ConditionEvaluator class. This complicates
evaluating conditions for Plugin objects, these have been checked to
ensure that metadata is only merged into them after evaluation.
GameSettings is only needed by the LOOT GUI, and many functions in Game
could also be GUI-specific, so they were moved to a new loot::gui::Game
class (the namespace is temporary, to prevent conflicts until the
loot::Game class is hidden inside the API).
This also involved minor modifications to LoadOrderHandler, the removal
of Masterlist::Update(Game& game), and the (re)addition of a new API
function for specifying the game's main master file.
This is unfinished, as there are a couple of classes that have
methods that take Game objects to eval metadata, and these will
probably not end up exposed in the API. None of the classes are
documented either.
YAML encode/decode code is now stored in separate headers that
depend on yaml-cpp and boost, and which will not be part of the
API proper.
Since they're not translated, they don't need to be logged when
they're thrown, either. For most previously-translated exception
messages, display a generic "something went wrong" message
instead as they're generally pretty unusal and severe errors.
There are a few exceptions to this (pun intended):
- The masterlist revision / date "N/A" and "Unknown" messages are
displayed in the General Information tab, so they've been
reimplemented without using the exception message content.
- The cyclic interaction error message is now created on catching
the CyclicInteractionError exception.
- The metadata syntax errors are still displayed in general and
plugin messages, so they'll just be displayed in English. This
is for consistency with third-party e.what() handling, as they
contain technical detail that should be logged but which is
(unusually) also useful to display in the UI, because the user
can fix the issue there too.
Closes#658.
Oliver Hamlet