In a few places in Dolphin, we're using BottomSheetDialogFragments.
These unhelpfully tend to start out in a "collapsed" state when in
landscape mode (presumably depending on factors like screen size). The
user then has to manually expand them before they can meaningfully
interact with them.
We've been automatically setting BottomSheetDialogFragments to the
expanded state if the device Dolphin is running on doesn't support
touch, since with d-pad navigation it's impossible to expand these
sheets. But I think we should set them to expanded on devices that
support touch too. I haven't encountered a single case where you can do
anything useful with any of Dolphin's BottomSheetDialogFragments while
they're collapsed, so the user always has to expand sheets manually if
they start out collapsed. And just because a device supports touch
doesn't necessarily mean you're interacting with it through the touch
screen right now - you could be using a gamepad, for instance.
Remove "env, " from "return env, GetControlPointer..." since the left
side of a comma operator has no effect.
This was presumably a copy/paste error from the function above it.
This is a hassle-free BBA option intended for local play with multiple
Dolphin instances running *in the same system*. After selecting
**Broadband Adapter (IPC)** in the **SP1** slot in the GameCube section
in the settings, games that support LAN play will be able to discover
each other, without requiring third-party software or relatively complex
TAP setups.
The implementation is based on cpp-ipc, a high-performance inter-process
communication library that uses shared memory as transport layer.
Supported platforms are:
- [x] Linux
- [x] Windows
- [ ] macOS (cpp-ipc does not support this platform)
- [ ] FreeBSD (cpp-ipc does not support this platform)
- [ ] Android (cpp-ipc needs some adjustments; while it could work,
launching two Dolphin instances within the same Android system may be
both challenging and impractical)
PauseAndLock is now only called with do_lock=true, and unpause_on_unlock
only ever was used when do_lock is false (which is now handled in
RestoreStateAndUnlock instead), so both parameters are unnecessary.
Replace calls of PauseAndLock(do_lock=false) with new function
RestoreStateAndUnlock for clarity.
Callers of PauseAndLock ignored the return value when do_lock is
false, so RestoreStateAndUnlock doesn't need to return anything.
RestoreStateAndUnlock was only called with control_adjacent=true. Remove
the parameter and unconditionally call the function that was gated
behind it being true.
CPUManager::PauseAndLock is now only called with do_lock=true, and
unpause_on_unlock only ever was used when do_lock is false (which is now
handled in RestoreStateAndUnlock instead), so both parameters are
unnecessary.
