This took me a while -- the old behavior for all emscripten_*()
functions was to take a DOM element ID as an argument, with nullptr
acting as a "the element that makes most sense for given operation". The
new behavior when -s DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1 is
enabled is to take a CSS selector instead. Presence of this option is
not detectable at compile time, so there was no easy way of knowing
what's the expected value, whether `"module"` or `"#module"`.
After a few failed attempts, I discoverd that using `"#canvas"` would
work for both the old and the new version -- in the new version it would
be selecting an element with id="canvas", while in the old version it
was a special value denoting Module['canvas']. Problem was, however,
that the markup was historically using id="module" and not id="canvas",
so this had to be changed.
This is a breaking change affecting everyone who targets Emscripten. You
need to update the HTML markup and, in case you maintain copies or forks
of the CSS and JS files, these as well. Details in the changelog.
What's new:
* The style is consistent with the dark m.css theme that's used on the
website and so provides a bit better "brand identity".
* The canvas is responsive, looking properly on mobile and scaling down
with aspect ratio preservation if the screen is too narrow.
* It's now possible to override canvas size and aspect ratio or make it
"fullscreen", i.e. occupying the whole browser window.
* If the app crashes, a helpful message is printed instead of
everything just being stuck.
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.
Emscripten supports some hybrid between SDL1 and SDL2. I don't want to
add Sdl1Application just for that and create more portability issues, so
I just changed some things in Sdl2Application to be compatible with what
Emscripten wants. Full SDL2 support is awaited in Emscripten, thus this
is future-proof (rather than having SDL1 support, which would be
deprecated later).
Added documentation about Emscripten usage and template HTML markup to
Sdl2Application docs, will move it somewhere else in the future when
more than one Application will be supported (e.g. GLUT).
Vladimír Vondruš