Commit Graph

2 Commits

Author SHA1 Message Date
JosJuice 0146456af0 Don't translate button names
Since these button names are printed on all real controllers,
we should show them in the same way as they are printed on
the controllers, regardless of the user's language. It seems
like this was intended all along (except for "Start"), but the
_ markers in TASInputDlg.cpp (accidentally?) led to the button
names in the controller configs also becoming translatable.

I'm making exceptions for "L" and "R" because translators
may want to mark them in some way (for instance "L-Digital")
to clarify the difference from "L-Analog" and "R-Analog".

I'm also making an exception for START/PAUSE because it's
referred to as スタート in Japanese games.

I'm changing "Home" and "Start" to uppercase for consistency
with how Nintendo refers to those buttons, and because someone
who isn't familiar with the Latin script might not know the
connection between the lowercase and uppercase letters (most
users likely do know the connection, but we shouldn't assume it),
and because leaving "Start" as "Start" makes it "collide" with
unrelated strings, such as the string for the button that starts
a netplay session.

To rename "Start" and "Home" without breaking INI
compatibility, I added a ui_name variable like in f5c82ad.
2017-05-06 16:29:10 +02:00
Lioncash 6a75ea5653 ControllerEmu: Separate ControlGroup from ControllerEmu
ControllerEmu, the class, is essentially acting like a namespace for
ControlGroup. This makes it impossible to forward declare any of the
internals. It also globs a bunch of classes together which is kind of a
pain to manage.

This splits ControlGroup and the classes it contains into their own source
files and situates them all within a namespace, which gets them out of
global scope.

Since this allows forward declarations for the once-internal classes, it
now requires significantly less files to be rebuilt if anything is changed
in the ControllerEmu portion of code.

It does not split out the settings classes yet, however, as it
would be preferable to make a settings base class that all settings derive
from, but this would be a functional change -- this commit only intends to
move around existing code. Extracting the settings class will be done in
another commit.
2017-02-09 18:18:52 -05:00