Partially needed to avoid build breakages because Corrade itself
switched as well, partially because a cleanup is always good. Done
except for (STL-heavy) code that's deprecated or SceneGraph-related APIs
that are still quite full of STL as well.
Such a hopeful test coverage, almost there, and yet it doesn't test
everything. It now uses 1D, 2D and 3D KTX2 files with levels taken
directly from KtxImporter tests, the original 1d.ktx2 and 3d.ktx2 are
moved to AnyImageConverter test where they are used to verify metadata
presence.
Somehow. Heh. This causes a non-deprecated build on MSVC to break due to
a similar reason as in 54394e2c2f. And,
similarly to 3717043ae2, *again*
discovered while building bindings.
Since the plugin implementations rely on the base plugin interfaces for
file handling, this affected only the tests. Also took this as an
opportunity to use the new TestSuite::Compare::StringHasPrefix etc. in
various places.
It doesn't make the test any simpler, easier to understand or less
error prone, on the contrary. And it would stop testing the intended
code path once file callbacks are implemented inside the importer.
These checks covered the case when the magnum-plugins repository wasn't
installed, but didn't cover the case when it was installed but the
plugins were built against an outdated interface, had ABI issues, or
didn't load at all for various other reasons.
And prefere to use it onver OpenEXR in most AnyImage{Converter,Importer}
tests, unless the test really needs something that only OpenEXR has
(such as the verbose output for threads or configuration that needs to
be set on both export and import to make the import succeed).
Minor but very important convenience feature, especially useful when
dealing with command-line apps. This now works:
magnum-imageconverter a.png a.jpg -c jpegQuality=0.75
The AnyImageConverter gets the jpegQuality option and then
automatically propagates it to the concrete plugin (which is either
JpegImageConverter or StbImageConverter), possibly warning in case the
target plugin doesn't recognize given option (i.e., doesn't list it in
its default configuration). Previously the user had to always specify a
concrete converter implementation using -C, which was rather annoying
and nonintuitive.
And also test various potential false positives, which shouldn't be
detected as given format.
*Damn*, I need some utility class for printing this, this is
unsustainable.
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.
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.