Should make new things more discoverable, avoid confusion when a
documented API isn't there and reduce the need for maintaining multiple
separate versions of the docs.
Apart from different include (<Magnum/Math/Color.h> instead of
<Magnum/Color.h>) there shouldn't be any visible change to the user. The
BasicColor3 and BasicColor4 classes are now Math::Color3 and
Math::Color4. The Color3, Color4, Color3ub and Color4ub typedefs in
Magnum namespace stayed the same.
BasicColor3 and BasicColor4 is now an alias to Math::Color3 and
Math::Color4, is marked as deprecated and will be removed in future
release. The same goes for the <Magnum/Color.h> include, which now just
includes the <Magnum/Math/Color.h> header.
The only places where they aren't absolute are:
- when header is included from corresponding source file
- when including headers which are not part of final installation (e.g.
test-specific configuration, headers from Implementation/)
Everything what was in src/ is now in src/Corrade, everything from
src/Plugins is now in src/MagnumPlugins, everything from external/ is in
src/MagnumExternal. Added new CMakeLists.txt file and updated the other
ones for the moves, no other change was made. If MAGNUM_BUILD_DEPRECATED
is set, everything compiles and installs like previously except for the
plugins, which are now in MagnumPlugins and not in Magnum/Plugins.
All the functionality is moved to Math::swizzle() and the result is
casted to given type only if its header is included. Thus it is possible
to remove include dependency on Color. The original swizzle() is now
just an alias marked as deprecated and will be removed in future
release.
Also fixed unary RectangularMatrix::operator-() and Vector::operator-()
documentation (was stating that the operation is done in-place, which is
impossible.
They aren't much useful in Math namespace and here it allows to handle
also Color3/Color4 types. Moreover all RGBA component names were removed
from Math namespace, so it would be inconsistent to have them there only
in swizzle() functions.
On the other hand everything of this is done at runtime, so it's less
performant than the previous version, mainly when used in loops. When
the result is declared as constexpr, it is done at compile time, just
like the previous version.
I don't know which version to keep, so there will be both until a good
decision.