Avoids the need to put the scaling parameters all over the place for the
common case. The only other time scaling is done is to generate the
smaller 48x48 image, so this is fine.
We can just make the function accept an arbitrary ProfileManager
reference and operate on that instead of tying the function to the class
itself. This allows us to keep the function internal to the cpp file and
removes the need to forward declare the UUID struct.
These should be initialized to deterministic values so it's easier to
catch improper behavior, as it'll always be reproducable, instead of
performing uninitialized reads.
These are only used within this class, so we can make them private to
keep their use contained. This also gets rid of the pre-Qt5 'slot'
identifier, since Qt 5's connection syntax doesn't require a function to
be declared a slot anymore.
Using fmt here requires unnecessary string conversions back into
QString. Instead, we can just use QString's formatting and get the end
result of the formatting operation in the proper type.
tr() will not function properly on static/global data like this, as the
object is only ever constructed once, so the strings won't translate if
the language is changed without restarting the program, which is
undesirable. Instead we can just turn the map into a plain old function
that maps the values to their equivalent strings. This is also lessens
the memory allocated, since it's only allocating memory for the strings
themselves, and not an encompassing map as well.
We can just use the facilities that Qt provides instead of pulling in
stuff from common. While we're at it, we can also simplify the nearby
logging statement's argument by just calling .toStdString()
This gets rid of an unnecessary type conversion. We can just use the
regular QStringLiteral to already format the string as the type
setWindowTitle accepts instead of converting from a std::string
instance.
* Fixed conflict with nfp
* Few fixups for nfc
* Conflict 2
* Fixed AttachAvailabilityChangeEvent
* Conflict 3
* Fixed byte padding
* Refactored amiibo to not reside in "System"
* Removed remaining references of nfc from system
* used enum for Nfc GetStateOld
* Added missing newline
* Moved file operations to front end
* Conflict 4
* Amiibos now use structs and added mutexes
* Removed amiibo_path
This is more localized to what we want to enforce directory-wise with
the project. CMAKE_SOURCE_DIR indicates the root of the source tree, but
this would cause the wrong behavior if someone included yuzu as part of
a larger buildsystem (for whatever reason). Instead, we want to use the
directory where the "project(yuzu)" command was declared as the root
path reference.
Keeps the definition constrained to the yuzu target and prevents
polluting anything else in the same directory (should that ever happen).
It also keeps it consistent with how the USE_DISCORD_PRESENCE definition
is introduced below it.
In the kernel, there isn't a singular handle table that everything gets
tossed into or used, rather, each process gets its own handle table that
it uses. This currently isn't an issue for us, since we only execute one
process at the moment, but we may as well get this out of the way so
it's not a headache later on.
The data retrieved in these cases are ultimately chiefly owned by either
the RegisteredCache instance itself, or the filesystem factories. Both
these should live throughout the use of their contained data. If they
don't, it should be considered an interface/design issue, and using
shared_ptr instances here would mask that, as the data would always be
prolonged after the main owner's lifetime ended.
This makes the lifetime of the data explicit and makes it harder to
accidentally create cyclic references. It also makes the interface
slightly more flexible than the previous API, as a shared_ptr can be
created from a unique_ptr, but not the other way around, so this allows
for that use-case if it ever becomes necessary in some form.