Instead of them being deleted. This was not possible in the times where
GCC 4.7 compatibility was a thing, but now that's long gone.
And of course I forgot the l/r-value overloads on CompressedImage :/
It's potentially dangerous because the user is responsible for choosing
a correct type, on the other hand forcing them to do it verbosely
through arrayCast() is both too annoying and too hard to explain.
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.
This is in line with how the other APIs are named (for example
ObjectDataXD have instance type and instance). This would be very hard
to change later without breaking backwards compatibility, so I'm doing
it now, until the animation APIs get widely used.
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.
This reduces the templated code a bit, as I moved the index assertion to
the *.cpp file. Also the function now returns a reference to avoid
needless copies -- it's a view, but still quite a heavy view.
The data are immutable by design, so it's a special "move constructor".
Usable when a plugin in proxying image import to external importers
(such as AnyImageImporter) and wants to attach its own state to the
result.
Doesn't make any backwards-incompatible change -- plugins can still
export the transformation as matrix and users can still access the
combined one even if separate transformations are used. Yay!
It was returning either pixel size or compressed block size, which is
now available directly via other means.
This is a breaking change, but I don't expect these functions to be
used widely beyond Magnum internals.
With the previous commits the original tests passed (which is
desired), but these were using deprecated functionality and not
covering the new stuff. These tests are not using the deprecated
functionality, which means I don't need to build them as part of
the GL library anymore.
The GL::BufferImage test is still using the deprecated
functionality though, in order to check I didn't break anything
by accident.