| Age | Commit message (Collapse) | Author |
|---|
|
|
|
controllers values
If InputConfig::LoadConfig() was called once with a non empty/customized config,
then called again after manually deleting the config (dolphin calls LoadConfig() every time it opens the mapping widget),
the second load would fail to clear the values on any non first EmulatedController and would instead keep the
previous config values despite it being deleted (while it would instead correctly default the first EmulatedController).
This is not a big bug though the code is better now.
|
|
|
|
SPDX standardizes how source code conveys its copyright and licensing
information. See https://spdx.github.io/spdx-spec/1-rationale/ . SPDX
tags are adopted in many large projects, including things like the Linux
kernel.
|
|
|
|
|
|
fix some related grammar errors
only the ButtonManager required code changes
|
|
Loop index int i was being compared against GetControllerCount() which
returned a size_t. This was the only place GetControllerCount() was
called from so the change of return type doesn't disturb anything else.
Changing the loop index to size_t wouldn't work as well since it's
passed into GetController(), which takes an int and is called from many
places, so it would need a cast anyway on an already busy line.
|
|
only running dynamic input textures once for all controllers
|
|
We want to use positional arguments in translatable strings
that have more than one argument so that translators can change
the order of them, but the question is: Should we also use
positional arguments in translatable strings with only one
argument? I think it makes most sense that way, partially
so that translators don't even have to be aware of the
non-positional syntax and partially because "translatable
strings use positional arguments" is an easier rule for us
to remember than "transitional strings which have more than
one argument use positional arguments". But let me know if
you have a different opinion.
|
|
Continues the migration over to fmt.
|
|
an emulated input action to an image based on what host key is defined for that emulated input. Specific regions are called out in configuration that mark where to replace an input button with a host key image.
|
|
A very early call to Config::Save is now creating empty
controller INI files.
https://bugs.dolphin-emu.org/issues/12283
|
|
NOTE: The explicit std::string() conversions later are needed. Otherwise,
gcc-9.2.0 throws all sorts of errors because it can't find a matching
operator+() function.
|
|
to UI. Eliminate hidden magic values of the IR cursor.
|
|
This is mostly for android so that a user can use the touchscreen to
accurately emulate pointer movements
|
|
reload the entire config from the ini file on hotplug, just update the control references. This should fix a crash on shutdown on Android.
|
|
|
|
input-profiles. If specified, the directories are searched recursively for inis
|
|
|
|
loaded; matching how cycling works
|
|
|
|
Co-authored-by: Barath Kannan <barathsotd@gmail.com>
|
|
|
|
|
|
|
|
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.
|
|
ControllerEmu is a massive class with a lot of nested public classes.
The only reason these are nested is because the outer class acts as a
namespace. There's no reason to keep these classes nested just for that.
Keeping these classes nested makes it impossible to forward declare them, which leads to quite a few includes in other headers, making compilation take
longer.
This moves the source files to their own directory so classes can be
separated as necessary to their own source files, and be namespaced under the
ControllerEmu namespace.
|
|
We call this "game ID" everywhere else, and it's not
actually completely unique.
|
|
Aren't indirect includes great?
|
|
|
|
|
|
The name field can contain personal information, particularly in the
case of bluetooth devices on OSX which get configured with the user's
full name.
|
|
|
|
|
|
|
|
|
|
controllers config.
- Simplified the locking mechanism when controllers were updated
- Reloaded the config of the controls instead of re-initialising the control plugins
- Fixed controls being unresponsive after the Refresh button was pressed
- Disables the hotkeys while the controller config is open
|
|
|
|
|
|
|
|
|
|
|
|
Also removes .c_str() usages where found.
|
|
that litter this section of the codebase.
Also clean up a little bit of the comments that describe the interface classes.
|
|
|
