Separate Custom Layout options for Portrait and Landscape modes #192
Conversation
|
Okay, I updated having run clang-format and I removed the |
DavidRGriswold
changed the title
|
Okay I got xcode all set up and the mac version builds fine for me after the latest commits. My qt-config.ini has all of the portrait mode layout stuff even though those aren't in the default config file code for the qt build, but I think that may be because this was a debug build by default or something? There were LOTS of options in there that are not normally there. In the current iteration, all of the new settings (starting with custom_portrait_layout and custom_portrait_top_top) should only appear in the default config.ini for the android version, but the settings exist in all versions. I was getting c++ errors otherwise. But since the other versions should never be in portrait mode, they should be ignored. Is it possible to make it so that those settings always get written (blank if unchanged) to the config.ini on android so that if a user installs the update it adds the documentation I included in the default ini file? |
|
@DavidRGriswold FYI, if you enable Github Actions on your fork (click on the Actions tab and turn it on), it'll automatically build things for all the OSes whenever you push a commit. That way, you can test things using Citra's build scripts without having to set up a local dev environment. |
DavidRGriswold
force-pushed
the
portrait_custom
branch
from
0d4f504 to
4e5ba66
Compare
DavidRGriswold
force-pushed
the
portrait_custom
branch
from
e3237de to
2483702
Compare
|
This finally satisfies clang-format. Not sure why just running the clang-format extension on VS Code didn't do it. @PabloMK7 I hope you will consider merging this - it's a niche feature, but a useful one. |
|
I'm not sure how VS Code does things, but Citra code uses clang-format-15 (different projects may use a different format, for example Lime3DS switched to clang-format-18 so you need to double-check your code if you're porting between the two); if VS Code is applying a different version of clang-format, then that could be why. |
any idea how to install two versions of clang-format? It does seem like I have version 18 installed. |
|
I'm not familiar with the VS Code environment, but perhaps you could download a set of Clang Tools binaries from here: https://github.com/muttleyxd/clang-tools-static-binaries And then use this extension: https://github.com/xaverh/vscode-clang-format to point to the location of clang-format-15.exe. There might be some other (easier?) solutions as well; I only spent about 20 seconds on Google. |
| @@ -189,6 +189,18 @@ void Config::ReadValues() { | |||
| ReadSetting("Layout", Settings::values.cardboard_x_shift); | |||
| ReadSetting("Layout", Settings::values.cardboard_y_shift); | |||
|
|
|||
| #ifdef ANDROID | |||
There was a problem hiding this comment.
You can just remove this, the JNI code is only compiled on Android anyways
| @@ -175,7 +175,17 @@ void Config::ReadValues() { | |||
| ReadSetting("Layout", Settings::values.custom_bottom_right); | |||
| ReadSetting("Layout", Settings::values.custom_bottom_bottom); | |||
| ReadSetting("Layout", Settings::values.custom_second_layer_opacity); | |||
|
|
|||
| #ifdef ANDROID | |||
There was a problem hiding this comment.
This code is only used in the desktop citra.exe (non-qt). There's no need for it and should be removed
This implements some additional config.ini settings to enable separated Custom Layouts for portrait and landscape mode on android. This is the only reason I still use Citra MMJ.
I have tested it on my phone and it works perfectly, but I have not successfully been able to build a desktop version to see if this somehow breaks that, so let me know what else I might need to change to get this in!
The biggest worry I have: I used an#ifdefto declare these settings as existing for Android only insettings.h, but I'm not sure if that will have knock-on effects when those settings don't exist in other builds. Most clearly, I couldn't figure out how to only do theReadBasicSettingandWriteBasicSettingcalls for those settings on android only, so I'm concerned that will cause an issue on non-android devices when it tries to do those calls on non-declared settings. If somebody with a better understanding of the whole project could look at this before merging it, I'd appreciated it.