The AbstractFont::openFile() and openData() now get an additional
argument specifying a font index to allow picking a concrete font index
for example in a TTC collection.
This index has to be specified upfront with no possibility to change it
afterwards, because that's how both FreeType and stb_truetype work. Thus
there are also new fileFontCount() and dataFontCount() APIs taking a
filename / data argument, instead of this being a fontCount() query on
an opened file. The implication from this is that -- unlike basically
all other APIs in Trade and elsewhere -- specifying an out-of-bounds
font index isn't an assertion (i.e., a programmer error) but rather a
graceful failure, because requireing the user to first call
fileFontCount() and then openFile() would mean having to open and
parse the same file twice, which is undesirable overhead.
While this isn't breaking for end users, as it's just a new optional
argument to openFile() and openData(), it's a breaking change for plugin
interfaces. The old doOpenFile() and doOpenData() interfaces are still
there to help transitioning existing plugins, but are marked as
deprecated. Delegating to those turned out to be quite involved, so
there are many new tests verifying this compatibility code path.
The plugin interface string version is bumped but in the next commits
I'm making use of the doOpenData() / doOpenFile() API breakage to do
more changes. Those won't result in further plugin interface changes, so
this set of commits should be treated as a single indivisible change to
the plugin interface. For this reason, uses of AbstractFont outside of
AbstractFontTest (including the MagnumFont plugin) aren't adapted yet
-- they pass tests as before, but compile only with deprecated APIs
enabled.
Co-authored-by: Andrew Snyder <asnyder@minitab.com>
They're now uncovered, which only makes it harder to spot missing
coverage in non-deprecated code. And testing is simply a matter of
copypasting the existing tests.
It's done like this in all other code, not sure why not here. Likely
because debug output wasn't tested at all before and only got added
later, thus at the end? So make it consistent.
In some cases the plugin manager constructor was not tested at all,
leading to an uncovered line. For importers also verify that calling
close() on a non-opened instance doesn't call into doClose().
Again, the Audio importer isn't touched at all, as that interface is
scheduled for mergin into Trade.
So far, even though code coverage says it's all fine, things like data
conversion failures were not tested at all, or only by checking the
return value, but without verifying that the implementation got actually
called, and without checking that no superfluous message was printed by
accident.
The AbstractFontConverter interface is tested for failures as well even
though most of it is scheduled for rework (STL removal, etc.), as
otherwise it'd be likely that I forget to test the failure cases when
simply porting the old test code to the new APIs. On the other hand, the
Audio importer interface is not touched as it's scheduled for merging
into Trade.
Code from 2012 still wants to fight back. Turns out the user
implementation of doOpenFile() was never tested, only the fallback paths
to doOpenData(). Heh.
Nope, that was a very stupid change. The *vector* min() / max() is used
in intersect(), and this change broke the bindings build (likely along
with random other code).
This reverts commit 8c228c69c9. Partially,
keeping the extra added includes and also documenting why the
Functions.h are included.
Disabling SDL_AUDIO seems to work with 2.32.10, so if there was a bug it
no longer seems to be. On the other hand, SDL_EVENTS is something the
application implementation does need, so I'm not sure why I even
attempted disabling those.
For some reason it had the full set of elements on ES2 as well, i.e.
something that definitely shouldn't be the case. Unfortunately C doesn't
warn if the array isn't initialized for all elements, setting the
remaining to 0, so this was uncaught until now. Now if I accidentally
make the array too small somewhere, it'll blow up inside
BufferState.cpp.
Because I had a stupid bug in the test and wasn't testing all of them.
And then the function itself had a bug that made it no-op exactly when
it shouldn't be a no-op.
Somehow I overlooked this extension back when implementing multidraw, or
maybe it was intentional because ANGLE supported multidraw but not this
extension.
The macro, which is enabled when preprocessing the headers for
single-header libs, excluded the TypeForSize specializations, making
these two not work with Math::gather() and Math::scatter(). It's done
correctly in Vector2 and Color, not sure why not here.
Causes the following warning on GCC on a static build if user code isn't
compiled with -fvisibility=hidden:
warning: ‘Magnum::GL::Mesh’ declared with greater visibility than
the type of its field ‘Magnum::GL::Mesh::_attributes’ [-Wattributes]
According to quick testing, given that the struct definition isn't
public, presence of the MAGNUM_GL_LOCAL has no effect on the symbol
being exported. On the contrary, inner classes that are meant to be
exported (such as the ones in GL::Framebuffer) have to contain
MAGNUM_GL_EXPORT, otherwise it leads to linker errors. Furthermore, all
other inner structs with local definitions holding PIMPL state and such
don't have a MAGNUM_*_LOCAL macro applied anywhere
Thus the macro was likely redundant, and is removed.
Vladimír Vondruš