Similarly as done in Aug 2024 in Corrade. When these were a part of the
function signature, they ended up being encoded into the exported
symbol. There are still cases of StridedArrayView slice() having
enable_if in the signature, which amounts to about 18 kB symbols in all
libMagnum*-d.so libraries, but apart from that this is the state before:
$ strings libMagnum*-d.so | grep enable_if | grep -v slice | wc -c
29591
And this is after. All of those are coming from STL, thus from
old or deprecated APIs that still use std::vector, std::tuple and such,
and from the few std::sort() uses.
$ strings libMagnum*-d.so | grep enable_if | grep -v slice | wc -c
4103
In a non-deprecated build it's just this, which is a 10x reduction.
Can't really do much about these maybe exceút for implementing my own
swap() specializations (sigh?), but I think it's fine.
$ strings libMagnum*-d.so | grep enable_if | grep -v slice | wc -c
2904
I also made it consistently use
typename std::enable_if<..., int>::type = 0
instead of
class = typename std::enable_if<...>::type
because the former works correctly also in presence of overloads and
having it used consistently everywhere makes it easier to grep & change
later. All SFINAE is now also excluded from Doxygen output, because it
doesn't make much sense there. It's better to just explain the
restriction in words than with this nasty hack.
All the new pointer events have float positions, this one was the odd one
out. And I didn't like the name anymore, so I took that as an opportunity
to change the position() data type without introducing a breaking change
for everyone.
Another considered change was adding Z offset to it, since HTML5 APIs
have that. However, all my googling led to just a single SO question from
2015, where someone said it's for trackballs that can navigate in 3D
space. I'm not sure if *scroll* is actually the best way to report those,
and since SDL3 didn't bother adding that and neither Android nor WINAPI
have anything like that, I'm not bothering either.
Unlike the previous commits, this is done for all apps at once, because
it's a comparatively simpler change. The only odd one out is
AbstractXApplication, where I introduced MouseScrollEvent just a few
commits back, so I simply renamed it without leaving a deprecated copy.
Then, ScreenedApplication needed some extra logic to handle the case of
apps not implementing any scroll event at all.
Because this overrides the base pointer*Event() implementations, it
additionally has to call into the parent implementation in order to fall
back to the deprecated mouse event if the new pointer event isn't
handled.
Giving out a pointer implied excessive error checking in user code.
There's a new hasApplication() accessor that can be used to check for
application presence, moreover the ScreenedApplication is now
convertible to a pointer to provide backward compatiblity. This
conversion is marked as deprecated and will be removed in a future
release.
Because not all applications implement these, it's done via a "mixin". I
never did such a thing before, just got an idea that it could work and
I'm equally amazed and horrified that it actually DOES WORK. The Screen
will now expose the MouseScrollEvent, TextInputEvent and
TextEditingEvent typedefs only if the underlying application has them
too and provides the overrideable mouseScrollEvent(), textInputEvent()
and textEditingEvent() also only if the underlying application has them
-- that also means you can't `override` those if the app doesn't provide
such APIs, which acts as a nice check against accidental overgenericity.
Deprecated in windowless apps in
6feda42f13 (June 2016) and for windowed
apps in eeba2ac848 (March 2017). Use
constructors taking the NoCreate tag instead.
With HiDPI support it's no longer just about window size changing -- if
the framebuffer size is different than window size, on resize both are
changed to new (different) values. Other than that, for example, when
moving a window from one display to another with a different DPI,
all three of window size, framebuffer size and DPI scaling can change as
well. This should be all reflected in the event.
This change is done in all Application classes, but the full
implementation is only in the SDL2 implementation at the moment, as the
others don't have full HiDPI support implemented yet. The old
viewportEvent(const Vector2i&) is deprecated and for backwards
compatibility called with either framebufferSize() or windowSize()
(depending on level of HiDPI support) from the new event. Overriding the
old one will still work as expected (in case you build with
MAGNUM_BUILD_DEPRECATED enabled and use the `override` keyword -- which
you should); overriding the new one will cause the compat implementation
to not be called anymore.
In order to make it possible to preserve backwards compatibility, the
viewportEvent() is no longer pure virtual in Screen. That's also
consistent with all Application implementations.
The Platform::*Application::Configuration class was split into
Configuration and GLConfiguration, the latter containing only
GL-specific configuration. Moreover, createContext() and
tryCreateContext() were renamed to create() / tryCreate().
There's now a constructor and a create() / tryCreate() overload taking
GLConfiguration and this will be later extended with VkConfiguration,
for example. GL-specific getters/setters from Configuration are now
marked as deprecated and merged into GLConfiguration during context
creation.
Everything has still hard dependency on GL, that will be done in the
next commits.
The move away from `nullptr` to NoCreate for constructing an application
without creating OpenGL context was done quite some time ago for
windowless application, but for some weird reason it was never done for
windowed apps. Now made this consistent.
The old `nullptr`-based constructor is still present, but marked as
deprecated and due to be removed in some future release.
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.
Vladimír Vondruš