We can perform the lookup and then do the contains check by checking the
end iterator. The benefit of this is that if we *do* find an entry, then
we aren't hashing into the map again to find it.
We can also get rid of an unused std::vector temporary while we're at
it.
The generation of the copy assignment operators are deprecated on being
generated when a user-provided destructor is present.
We can explicitly specify that we desire this behavior to keep the class
forward compatible with future standards.
Building SDL2 from externals is incompatible with Conan's version of
libiconv, a requirement of Conan's Boost package. Solution is to use the
same Boost package in use by the linux-fresh container. This tells CMake
to download boost_1_75_0.tar.xz from yuzu-emu/ext-linux-bin at CMake's
configuration step, much the same way Qt and FFmpeg are downloaded for
Windows.
Also makes DownloadExternals.cmake cross-platform. Although the CMake
code is not entirely specific to Linux, only Linux has Boost libraries
available at ext-linux-bin, whereas there is no equivalent Boost package
for Windows at ext-windows-bin. caveat emptor
If SDL2 is not found, the error is handled by falling back to externals.
No need spill the full warning at the find_package if it's going to be
handled later, so add QUIET to it.
Sets find_package(FFmpeg) to QUIET instead of REQUIRED. This allows
using the FFmpeg external in cases where there is no suitable installed
version of FFmpeg.
Also fixes a bug where multiple CMake configures causes FFmpeg_LIBRARIES
to concatenate on itself, producing cyclical dependencies. Unsets the
variable before building it in the foreach loop.
Fixes FFmpeg_INCLUDE_DIR not including the headers generated at run
time.
This line can only ever be reached if src is null, so dereferencing it
here is a logic bug that slipped through.
Instead, we dereference dst instead which is guaranteed to be valid.
If anything happened to call arp functions in the wrong order and called
IRegistrar's Issue function before SetApplicationLaunchProperty, we'd
read from an uninitialized ApplicationLaunchProperty instance.
Instead, we can always initialize it so if this does happen, then the
outcome of doing such a thing is at least consistently reproducible.
ControllerBase already has a System reference that can be accessed from
this class, so we can get rid of this to make the class layout a little
more straightforward.
SDL 2.0.14 introduces an incompatibility with Clang, causing it to
trigger -Wimplicit-fallthrough even though it is marked. Ignore it for
now, with a comment mentioning why this is needed.
Forces using SDL 2.0.14. Upgrades the SDL external to that version. Adds
a message when switching to the external.
Fixes an error where input_common only links to SDL when SDL2_FOUND is
set, but externals/CMakeLists cannot set that variable to the required
scope. Switch to using ENABLE_SDL2, which we can use since we now
include the SDL source.
Since Bintray is (soon to be) no more, there needs to be a way to
acquire SDL2. Since 20.04's version is older than our minimum required
version (2.0.12), add it as an external.
- Bintray will be deprecated on May 1st 2021 (https://bintray.com/)
- We were previously using this for Qt (non-Windows) and SDL.
- I've moved to bundled SDL on Windows.
The Qt Software Keyboard frontend attempts to mimic the software keyboard rendered by the Nintendo Switch.
This frontend implements multiple keyboard types, such as the normal software keyboard, the numeric pad software keyboard and the inline software keyboard.
Keyboard and controller input is also supported in this frontend.
Keyboard input is handled as native keyboard input, and so the on-screen keyboard cannot be navigated with the keyboard arrow keys as the arrow keys are used to move the text cursor.
Controller input is translated into mouse hover movements on the onscreen keyboard or their respective button actions (B for backspace, A for entering the selected button, L/R for moving the text cursor, etc).
The text check dialogs can also be confirmed with controller input through the use of the OverlayDialog
Massive thanks to Rei for creating all the UI for the various keyboards and OverlayDialog. This would not have been possible without his excellent work.
Co-authored-by: Its-Rei <kupfel@gmail.com>
An OverlayDialog is an interactive dialog that accepts controller input (while a game is running)
This dialog attempts to replicate the look and feel of the Nintendo Switch's overlay dialogs and
provide some extra features such as embedding HTML/Rich Text content in a QTextBrowser.
The OverlayDialog provides 2 modes: one to embed regular text into a QLabel and another to embed
HTML/Rich Text content into a QTextBrowser.
Co-authored-by: Its-Rei <kupfel@gmail.com>
Lioncash