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.
Neither of these functions alter the ownership of the provided pointer,
so we can simply make the parameters a reference rather than a direct
shared pointer alias. This way we also disallow passing incorrect memory values like
nullptr.
We can utilize QStringList's join() function to perform all of the
appending in a single function call.
While we're at it, make the extension list a single translatable string
and add a disambiguation comment to explain to translators what %1
actually is.
Depending on whether or not USE_DISCORD_PRESENCE is defined, the "state"
parameter can be used or unused. If USE_DISCORD_PRESENCE is not defined,
the parameter will be considered unused, which can lead to compiler
warnings. So, we can explicitly mark it with [[maybe_unused]] to inform
the compiler that this is intentional.
Neither of these functions require the use of shared ownership of the
returned pointer. This makes it more difficult to create reference
cycles with, and makes the interface more generic, as std::shared_ptr
instances can be created from a std::unique_ptr, but the vice-versa
isn't possible. This also alters relevant functions to take NCA
arguments by const reference rather than a const reference to a
std::shared_ptr. These functions don't alter the ownership of the memory
used by the NCA instance, so we can make the interface more generic by
not assuming anything about the type of smart pointer the NCA is
contained within and make it the caller's responsibility to ensure the
supplied NCA is valid.
change TouchToPixelPos to return std::pair<int, int>
static_cast (SDL)
various minor style and code improvements
style - PascalCase for function names
made touch events private
const pointer arg in touch events
make TouchToPixelPos a const member function
did I do this right?
braces on barely-multiline if
remove question comment (confirmed in Discord)
fixed consts
remove unused parameter from TouchEndEvent
DRY - High-DPI scaled touch put in separate function
also fixes a bug where if you start touching (with either mouse or touchscreen) and drag the mouse to the LEFT of the emulator window, the touch point jumps to the RIGHT side of the touchscreen; draggin to above the window would make it jump to the bottom.
implicit conversion from QPoint to QPointF, apparently
I have no idea what const even means but I'll put it here anyway
remove unused or used-once variables
make touch scaling functions const, and put their implementations together
removed unused FingerID parameters
QTouchEvent forward declaration; add comment to TouchBegin that was lost in an edit
better DRY in SDL
To do -> TODO(NeatNit)
remove unused include
* Added a context menu on the buttons including Clear & Restore Default
* Allow clearing (unsetting) inputs. Added a Clear All button
* Allow restoring a single input to default (instead of all)
Placing the array wholesale into the header places a copy of the whole
array into every translation unit that uses the data, which is wasteful.
Particularly given that this array is referenced from three different
translation units.
This also changes the array to contain pairs of const char*, rather than
QString instances. This way, the string data is able to be fixed into
the read-only segment of the program, as well as eliminate static
constructors/heap allocation immediately on program start.
Many of the member variables of the thread class aren't even used
outside of the class itself, so there's no need to make those variables
public. This change follows in the steps of the previous changes that
made other kernel types' members private.
The main motivation behind this is that the Thread class will likely
change in the future as emulation becomes more accurate, and letting
random bits of the emulator access data members of the Thread class
directly makes it a pain to shuffle around and/or modify internals.
Having all data members public like this also makes it difficult to
reason about certain bits of behavior without first verifying what parts
of the core actually use them.
Everything being public also generally follows the tendency for changes
to be introduced in completely different translation units that would
otherwise be better introduced as an addition to the Thread class'
public interface.
Keeps the individual behaviors in their own functions, and cleanly
separate. We can also do a little better by converting the relevant IDs
within the core to a QString only once, instead of converting every
string into a std::string.
Disambiguates what the string represents to help translators more easily
understand what it is that they're translating. While we're at it, we
can move the code to its own function, so that we don't need to specify
the same string twice.
Makes the public interface consistent in terms of how accesses are done
on a process object. It also makes it slightly nicer to reason about the
logic of the process class, as we don't want to expose everything to
external code.
Ternary operators have a lower precedence than arithmetic operators, so
what was actually occurring here is "return (out + full) ? x : y" which most
definitely isn't intended, given we calculate out recursively above. We
were essentially doing a lot of work for nothing.
This can cause warnings about static constructors, and is also not ideal
performance-wise due to the indirection through std::function. This also
keeps the behavior itself separate from the surrounding code, which can
make it nicer to read, due to the size of the code.
Qt provides an overload of tr() that operates on quantities in relation
to pluralization. This also allows the translation to adapt based on the
target language rules better.
For example, the previous code would result in an incorrect translation
for the French language (which doesn't use the pluralized version of
"result" in the case of a total of zero. While in English it's
correct to use the pluralized version of "result", that is, "results"
---
For example:
English: "0 results"
French: "0 résultat" (uses the singular form)
In French, the noun being counted is singular if the quantity is 0 or 1.
In English, on the other hand, if the noun being counted has a quantity
of 0 or N > 1, then the noun is pluralized.
---
For another example in a language that has different counting methods
than the above, consider English and Irish. Irish has a special form of
of a grammatical number called a dual. Which alters how a word is
written when N of something is 2. This won't appear in this case with a
direct number "2", but it would change if we ever used "Two" to refer to
two of something. For example:
English: "Zero results"
Irish: "Toradh ar bith"
English: "One result"
Irish: "Toradh amháin"
English: "Two results"
Irish: "Dhá thorthaí" <- Dual case
Which is an important distinction to make between singular and plural,
because in other situations, "two" on its own would be written as "dó"
in Irish. There's also a few other cases where the order the words are
placed *and* whether or not the plural or singular variant of the word
is used *and* whether or not the word is placed after or between a set
of numbers can vary. Counting in Irish also differs depending on whether or not
you're counting things (like above) or counting people, in which case an
entirely different set of numbers are used.
It's not important for this case, but it's provided as an example as to why one
should never assume the placement of values in text will be like that of
English or other languages. Some languages have very different ways to
represent counting, and breaking up the translated string like this
isn't advisable because it makes it extremely difficult to get right
depending on what language a translator is translating text into due to
the ambiguity of the strings being presented for translation.
In this case a translator would see three fragmented strings on
Transifex (and not necessarily grouped beside one another, but even
then, it would still be annoying to decipher):
- "of"
- "result"
- "results"
There is no way a translator is going to know what those sets of words
are actually used for unless they look at the code to see what is being
done with them (which they shouldn't have to do).
We pass a hint to the QPainter instance that we want anti-aliasing on
the compatibility icons, which prevents the circles from looking fairly
jagged, and actually makes them look circular.
Previously, these were sitting outside of the Kernel namespace, which
doesn't really make sense, given they're related to the Thread class
which is within the Kernel namespace.
Given these are shown to the user, they should be translatable.
While we're at it, also set up the dialog to automatically retranslate
the dialog along with the combo boxes if it receives a LanguageChange
event.
Keeps the individual initialization of the combo boxes logically separate.
We also shouldn't be dumping this sort of thing in the constructor
directly.
