[Android] Rewrite settings UI. #3547
Conversation
| @@ -0,0 +1,25 @@ | |||
| package org.dolphinemu.dolphinemu.model.settings; | |||
|
|
|||
| public abstract class Setting | |||
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
sigmabeta
force-pushed
the
android-config-rewrite
branch
2 times, most recently
from
5781ed7
to
fb29d31
Compare
|
Reviewed 56 of 71 files at r1, 12 of 12 files at r2, 3 of 3 files at r3. Source/Android/app/src/main/java/org/dolphinemu/dolphinemu/utils/SettingsFile.java, line 212 [r3] (raw file): Comments from the review on Reviewable.io |
sigmabeta
force-pushed
the
android-config-rewrite
branch
4 times, most recently
from
9afefaf
to
79dbd2b
Compare
|
Reviewed 7 of 7 files at r4. Comments from the review on Reviewable.io |
sigmabeta
force-pushed
the
android-config-rewrite
branch
from
79dbd2b
to
2190496
Compare
[Android] Rewrite settings UI.
|
I respect your work but I have some doubts @sigmabeta It has been a long time since this change. dolphin 5.0 stable is done. there is no point to keep this change if it will never be completed. any update on input configuration, please? |
The old settings UI uses Android's SharedPreferences & PreferenceFragment components. While this had the nice benefit of giving us easy, canned UI, it had some drawbacks:
-The canned UI isn't very flexible (so for example, there couldn't really be a different version for Android TV)
-We had to duplicate every setting we modified in android's SharedPreference database, which caused problems for users who frequently switched between older builds and newer ones.
-The writing / reading of the ini files used by the emulation backend was done in native code, which doesn't work on emulators, complicating testing / iteration of any UI.
So this PR reimplements the writing/reading in Java, and implements a UI system for displaying these settings.
There's more or less feature parity with the previous settings UI (I haven't tested all the settings yet, many of them have special cases that need to be handled, hopefully I got them all) with the major exception of input configuration, which is actually completely disabled as of this PR. However, I plan to write a better UI for that - one that doesn't require a scrolling list, and more closely resembles the user friendliness of the desktop configuration interface.