So it's clear the error comes from Magnum and not something else. Also
unify these and make GLFW not report the error on two lines if the init
fails.
Ugh, except that glfwGetError() is only there since 3.3, so I have to
keep the old code as well.
Text only, SDL3 has support for arbitrary mime types so the API is named
clipboardText() and not just clipboar(). Wanted to add this for
Emscripten as well, but after looking around a bit, I don't think I want
to deal with that until someone actually wants clipboard support
somewhere.
And also immediately document it's not recommended to be used if it's
important to not miss any events, so basically next to useless. Yet some
projects implement their own key state caching on top of
Platform::Application, so it's better to give them the builtin thing
than suffer needless wheel reinvention.
The more I looked at it, the more useless it felt. Also, since it's so
broken, I'm also completely removing it from the test because there's no
point in even testing it.
Unlike the Key enum, which shows what a user would perceive as given key
in a particular layout, the scancode is a layout-independent identifier
for e.g. WASD movement in games.
Unfortunately the API availability is wildly different among the
toolkits -- SDL's is the most complete, GLFW is second, and then there's
Emscripten / HTML5 which provides just string identifiers. I tried to
add these for X11 as well, but quick googling led to a SO question where
it was left unanswered. Not worth my time.
There's the obvious advantage of them now being shorter to type, as one
no longer needs to prefix them with KeyEvent::. But the main reason I
did this was to allow various direct keyboard state queries to be
implemented, such as isKeyPressed(). With them being hidden in the event
class the only way would be to put the query directly there as well,
which isn't nice and is also not very discoverable.
A similar case was with mouse buttons, but that was already fixed with
the PointerEvent rework that happened in earlier commits. There the
additional complication was that MouseEvent::Button and
MouseMoveEvent::Button were incompatible enums. Application::Pointer
fixes that now as well.
As usual, the most trash fire platform of them all. Ugh. I chose to
ignore certain aspects and suggestions and made it behave more like
Emscripten and SDL2, because that makes more sense to me.
Co-authored-by: nodoteve <nodoteve@yandex.com>
The impossible-to-reliably-disable behavior with compatibility mouse
events is quite a headache. I wish Emscripten implemented pointer events
already so I could ditch this mess -- especially the array of 32 touches
where all of them but one will be unchanged is stupid.
For the internals unfortunately, EmscriptenMouseEvent and
EmscriptenTouchEvent have no common base, so I had to give up on the
current way of querying the event struct directly from event getters, as
that'd be too nasty with the branching and casts. Instead the relevant
fields are put directly into the events themselves.
HTML5 also doesn't provide any relative pointer position. For the mouse
it was rather straightforward, but for the up-to-32 touches I have to
maintain an array of per-finger positions and match them by ID.
Hopefully the linear lookup is fine. I'll probably use the same approach
for the AndroidApplication.
This makes 2.0.6 as the oldest supported because in older versions it's
not possible to disable touch to mouse event translation, and it'd be
too annoying to have it special-cased there. The version bump should be
fine as Ubuntu 18.04 has 2.0.8.
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.
Pointer events are an unified abstraction over mouse, touch, pen and
potential other yet-to-be-invented pointer-like input methods. Their goal
is to expose all such input methods under a single interface so the
application side doesn't need to explicitly make sure that it's
touch-aware or pen-aware. This abstraction is already present in HTML5,
in Qt6 and in WINAPI as well, and is also what I adopted for the new UI
library because it *just makes sense*.
Unfortunately not even SDL3 took the opportunity to introduce that and
instead added a *third* separate event type for pen input in SDL3. At
first I thought that I wouldn't introduce any extra abstractions in the
Application classes (because that's what they are designed to be, as
lightweight as possible), but midway through introducing TouchEvent
classes and fighting SDL's touch->mouse and mouse->touch compatibility
translation (yes, it's both ways, depending on the platform) I realized
that a much simpler solution that doesn't require any event translation
or the users duplicating their event handling logic for several possible
input types is to introduce a single new event type that covers all.
Which is what this commit does -- it doesn't introduce anything
touch-related so far, just creates a new PointerEvent and
PointerMoveEvent class and corresponding virtual functions. Additionally,
I took this as an opportunity to make the position floating-point, since
that's what SDL3 does now as well, and GLFW did so since ever.
Plus, the Pointer and Pointers enums are directly on the Sdl2Application
class, to allow me to *finally* introduce pointer state queries. Which
weren't possible until now, because there were mutually incompatible
MouseEvent::Button and MouseMoveEvent::Button enums and putting them on
the base class would mean one would have to be translated and the other
not. With Pointer it's translated always, because there isn't any similar
enumeration in SDL that would cover mouse, touch and pen at the same
time.
I wanted to add this for GlfwApplication, only to realize the timer there
is a double, in seconds, so accepting *integral* milliseconds there felt
very weird. Let's use the fancy new time types instead.
Also updated the docs to (hopefully) clarify that setSwapInterval() has
to be called in order for the interaction between the two to work
properly.
As usual, the old variant taking untyped milliseconds is a deprecated
alias to this one.
Originally (2012? 2013?) I expected that there would eventually be
OpenGL ES 4.0, thus it made sense to differentiate between ES2, ES3 and
something else ES yet unknown. But as ES4 was increasingly unlikely to
happen, the internal code treated MAGNUM_TARGET_GLES3 as a simple
inverse of MAGNUM_TARGET_GLES2, and only in a very few places,
only adding confusion.
Thus it's now deprecated and defined as a simple inverse of
MAGNUM_TARGET_GLES2 on MAGNUM_TARGET_GLES builds, and none of the
internal code uses it anymore.
This one was spectacular -- ALL uses of it had also #include <tuple> in
order to std::tie() the result into separate major & minor variables. So
much compile time overhead for so little.
This makes them consistent with window and framebuffer size queries,
that are also not cached but queried every time. It fixes a case where a
global UI scaling change in the OS triggered a viewport event but the
event didn't actually have the DPI scaling value updated.
It doesn't however handle actual explicit DPI change events yet, that's
another nightmare altogether.
There is one already, and I'm not going to use because it's bloated.
Plus there's EmscriptenApplication that doesn't have to pay for the
extra overhead of wrapping HTML5 APIs in SDL APIs.
Same as the corresponding change in Corrade, this allows each function
to explicitly specify its dependencies, making it no longer depending on
what a particular Emscripten version decides to include by default, or
forcing users to painstakingly fill the EXPORTED_FUNCTIONS array when
linking the final executable.
It also allows the code to eventually get conditionally included or not
with preprocessor branches, for example to not include environment
queries for code that won't ever access Node.js console.
This makes the minimal supported Emscripten version 1.39.5. With some
more effort this could be changed to 1.38.27, but I don't think anybody
needs that.
AsciiToString is not included by default on 3.1.21+ and including it is
basically impossible on the library side because I don't think they
fixed the case of supplying multiple DEFAULT_LIBRARY_FUNCS_TO_INCLUDE
options on the command line in order to concatenate those lists yet.
Also, given that UTF8ToString is probably already used in other places
since it's included by default, using AsciiToString would only mean
inflating the JS code.
I was abusing the API and passing a negative pitch there to not have to
invert the image by hand. It stopped working in 2.23 when they hardened
the argument checking and, while working correctly, this feature was
accidental and undocumented.
Unfortunately it broke silently, because the API returned nullptr and
SDL_SetWindowIcon(..., nullptr) is then resetting an icon to nothing. So
I'm adding an internal assertion there now. Hopefully it doesn't start
blowing up for some reason again, heh.
The code right below is querying the `log` option, which wasn't added.
Becomes a problem when Magnum is compiled w/o GL support, e.g. for a
custom WebGPU renderer.
I'm getting kinda pissed at the strange defaults. Should I be using a
different toolkit altogether because SDL IS FOR GAMES ONLY? Given how
many bugreports and complaints there is about "Dosbox blocking
screensaver" I'm beginning to think it's SDL's fault, not mine.
Let the users control what they want, ffs, don't enable problematic
features like blocking powersave or disabling compositor by default.
Those should be a runtime option anyway, similarly to how video players
block powersaving only when *an actual video is playing*.
A large portion of the needed changes was in the previous commit
already, this does just the remaining part, in particular ensuring EGL
is linked and SDL is told to use EGL as well -- GLFW was told so in the
previous cleanup commit already.
These two options were mutually exclusive, and both were doing the same
thing -- switching to EGL on desktop GL, or switching away from EGL on
GLES. That made all logic vastly more complicated than it should be, and
unfortunately it took me half a decade to realize that. The new logic is
significantly simpler everywhere.
As usual, the old options are still recognized by CMake on a deprecated
build (with a warning), and are still exposed both as CMake variables
and a preprocessor define. But the logic for them was quite complicated,
so I don't guarantee all cases are covered.
I also tried to clean up the dependent CMake options to allow building
GLX and WGL apps on GLES independently of whether EGL is used, but it's
quite a mess due to the limitations of CMake < 3.22. Build directories
that have the options switched randomly over a long time might start
misbehaving, but the initial build should work well.
For quite a while, setSwapInterval() was reporting that "swap interval
was ignored by the driver". Since I used to have that behavior ages ago
on a NVidia Optimus machine (where it was just *impossible* to have
VSync, imagine that!!), I assumed it was a similar wart in Mesa and
didn't bother looking into it.
It turns out, however, that calling setSwapInterval(1) may result in
SDL_GL_GetSwapInterval() returning -1 instead of 1, thus helpfully
enabling late-swap behavior for me. Since -1 != -1, the code treated
that the same as if SDL_GL_GetSwapInterval() returned 0 (which was the
case with NV Optimus having broken VSync), but it's not an error in
fact.
Which allows to get rid of a now-unneeded ArrayView include in the
header. Also, now that we're returning a StringView, it's useful to
have the view always null-terminated. In SDL2 and Emscripten it was
already like that, GLFW needed a minor change.
Except CGL, iOS, AndroidApplication and AbstractXApplication which are
either too crappy or don't have the needed scaffolding for specifying
context flags yet.
We no longer have to use sizeof("...") to avoid useless strlen calls or
check for nulls because the StringView APIs are ACTUALLY SANE and not a
full of nasty surprises and performance / security pitfalls like with
both the C and C++ standard library functions. Good riddance.
This removes one unnecessary allocation from each application startup.
In some cases of the windowless apps the Platform::GLContext could be
put directly into the class, in other cases it had to be wrapped in an
Optional because we need delayed construction and/or earlier
destruction.
Vladimír Vondruš