Eliminates the need to rebuild some source files if the file_util header
ever changes. This also uncovered some indirect inclusions, which have
also been fixed.
The follow-up to e2457418da, which
replaces most of the includes in the core header with forward declarations.
This makes it so that if any of the headers the core header was
previously including change, then no one will need to rebuild the bulk
of the core, due to core.h being quite a prevalent inclusion.
This should make turnaround for changes much faster for developers.
Avoids the need to rebuild multiple source files if the filesystem code
headers change.
This also gets rid of a few instances of indirect inclusions being
relied upon
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.
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.
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.
