On this day, MSVC linker started complaining about missing symbols like
WavImporter::doOpenData() in the WavHeaderTest. Mind you, there's
NOTHING the WavHeader.h would use from there. Neither the test. The only
thing that connects those two together is that WavHeader.h includes
WavImporter.h (probably just a leftover from the time where those two
actually depended on each other). My suspicion is that this got
triggered due to recent changes in AbstractPlugin (it's movable now) and
MSVC attempts to instantiate the destructor or whatnot, needing
references to the privately defined virtual functions. Or something. All
that while nothing from there is EVER used.
Removing the header dependency, hopefully this fixes it. Ugh.
Basically mirroring the API of Trade::AbstractImporter, as that proved
to be useful. The old crazy openSingleData() and openData(horribleStuff)
are deprecated and will be removed in a future release.
No backwards compatibility is provided for font plugins, these need to
be adapted.
It'll get used outside of the root namespace and since the callbacks tend
to be quite complex, it would be silly to require users to implement one
callback for Trade, one for Text and one for Audio, for example.
Allows the Font and FontConverter plugins be built without TARGET_GL
enabled. That was the last piece missing for making the magnum-plugins
repo completely GL-free.
The original implementation had a few problems:
- If a file callback was set, openFile() was unconditionally calling
right into doOpenData(), making it impossible for the importer to
know the original path for correctly supplying paths to additional
files. Now, if the importer supports Feature::FileCallback,
doOpenFile() is always called. It's also possible for the importer to
save the path and then just delegate to the base doOpenFile()
implementation -- it will handle the file callbacks correctly too.
- If the importer supported neither FileCallback nor OpenData and
callbacks were set, the original doOpenFile() implementation was
called without any warning or anything, doing silently a bad thing.
Now in this case setFileCallbacks() asserts -- programmer has to
check for feature support first.
- It was not possible for the file callback to indicate file opening
failure -- in general, empty files are valid, so a nullptr ArrayView
is also a valid file. Now the callback return an Optional instead.