We can make the enum class type compatible with fmt by providing an
overload of operator<<.
While we're at it, perform proper bounds checking. If something exceeds
the array, it should be a hard fail, because it's, without a doubt, a
programmer error in this case.
Instead, we make a proper registry class and house it within the main
window, then pass it to whatever needs access to the loaded hotkeys.
This way, we avoid a global variable, and don't need to initialize a
std::map instance before the program can do anything.
The codec used by Qt for const char* and std::string don't necessarily
have to be the same depending on locale. Therefore, we should be using
the correct functions to do the conversions.
In OnMenuRecentFile() we don't need to construct a QFileInfo instance
just to check if a file exists, we can just use the static member
function to do that (which Qt's documentation also notes as quicker than
constructing an instance).
In UpdateUITheme(), we just want to try and open the file and check the
success of that operation. Technically speaking, between the existence
check and the open call, the file can be deleted or moved, but still
appear to succeed in code. i.e.
1. Existence check -> Returns true
2. File is moved/deleted
3. Open is called, the return value of which isn't checked
4. Nonsense behavior
This way we combine the existence check and the open into one.
Previously, when canceling out of the Load Folder dialog, a user would
get an error dialog about the selected folder not containing a main
file, however, by canceling out of the dialog, no selection was actually
made.
We move the initialization of the renderer to the core class, while
keeping the creation of it and any other specifics in video_core. This
way we can ensure that the renderer is initialized and doesn't give
unfettered access to the renderer. This also makes dependencies on types
more explicit.
For example, the GPU class doesn't need to depend on the
existence of a renderer, it only needs to care about whether or not it
has a rasterizer, but since it was accessing the global variable, it was
also making the renderer a part of its dependency chain. By adjusting
the interface, we can get rid of this dependency.
General moving to keep kernel object types separate from the direct
kernel code. Also essentially a preliminary cleanup before eliminating
global kernel state in the kernel code.
Makes the global a member of the RendererBase class. We also change this
to be a reference. Passing any form of null pointer to these functions
is incorrect entirely, especially given the code itself assumes that the
pointer would always be in a valid state.
This also makes it easier to follow the lifecycle of instances being
used, as we explicitly interact the renderer with the rasterizer, rather
than it just operating on a global pointer.
