You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
private static final String SDL_HINT_ANDROID_HIDE_SYSTEM_BARS = "SDL_ANDROID_HIDE_SYSTEM_BARS";
// Keep track of the paused state
public static boolean mIsPaused, mIsSurfaceReady, mHasFocus;
public static boolean mExitCalledFromJava;
@@ -166,6 +169,13 @@
// Set up the surface
mSurface = new SDLSurface(getApplication());
nativeAddHintCallback(SDL_HINT_ANDROID_HIDE_SYSTEM_BARS, new SDLHintCallback() {
@Override
public void callback(String name, String oldValue, String newValue) {
updateSystemBarsStatus(newValue);
}
});
if(Build.VERSION.SDK_INT >= 12) {
mJoystickHandler = new SDLJoystickHandler_API12();
}
// Messages from the SDLMain thread
static final int COMMAND_CHANGE_TITLE = 1;
@@ -437,6 +473,10 @@
int is_accelerometer, int nbuttons,
int naxes, int nhats, int nballs);
public static native int nativeRemoveJoystick(int device_id);
/*******************************************************************************
Functions called by SDL into Java
*******************************************************************************/
On 2016-10-04 23:39:28 +0000, Alex Szpakowski wrote:
Should immersive mode automatically activate when the SDL window is fullscreen and/or borderless? That's effectively what happens on iOS.
On 2016-10-05 07:16:40 +0000, Daniel Sobe wrote:
I'm not sure everybody would like the navigation bar at the bottom to disappear by default, because unlike iOS there's a "back" button which the app might want to make use of.
However, the back button is typically used to cycle between activities, thus the main usage should be to leave the SDL app. So maybe most of the developers would want it to be hidden by default in their app.
Maybe the hint should be "the other way 'round", making immersive mode default, unless the developer explicitly requests the bar to be permanently visible?
I cannot say anything about the impact of Android 7's new features where windows are not always fullscreen. Maybe somebody else already has experience with this?
This is a great idea (and the hint listener is fantastic!)
I'm going to make this dynamic based on the application state of the window and play with this a bit.
Thanks!
On 2017-11-05 08:56:38 +0000, Daniel Sobe wrote:
I'm wondering whether the commit mentioned in comment # 3 already does the same like this patch. If this is the case, the patch here can be disregarded.
The difference I see is that the patch here checks for the API versions (14 and 19) before taking appropriate actions. The committed version does this without any checks, but in case the additional flags are simply being ignored on older devices with older APIs, this would work as well.
Last thing is the hint, which is used in this patch. The committed version doesn't use any, e.g. makes the behaviour default. This can be seen as reasonable choice for a gaming library.
I guess both patches require a target API >= 19, so this is not a difference. Minimum API of 10 probably still works, although the number of devices will be relatively small nowadays.
On 2017-11-09 00:59:42 +0000, Diego wrote:
With this new fullscreen mode the app goes into fullscreen when started but after leaving the app, such as with the home or overview button, and then returning to the app causes the navigation bar to be show and not return to fullscreen.
On 2017-11-13 09:47:25 +0000, Daniel Sobe wrote:
Yes, the patch here restores the "sticky immersive mode" (resp low profile mode on lower API versions) on every restore of the app, not just on initial launch.
No matter whether this patch is used or the currently merged approach - both require target API 19 to compile. This patch needs it on the Java side, the merged patch on the native side.
The text was updated successfully, but these errors were encountered:
This bug report was migrated from our old Bugzilla tracker.
Reported in version: HG 2.1
Reported for operating system, platform: Windows 10, x86_64
Comments on the original bug report:
On 2016-10-04 18:55:41 +0000, Daniel Sobe wrote:
On 2016-10-04 23:39:28 +0000, Alex Szpakowski wrote:
On 2016-10-05 07:16:40 +0000, Daniel Sobe wrote:
On 2017-11-03 08:47:18 +0000, Sylvain wrote:
On 2017-11-05 05:18:35 +0000, Sam Lantinga wrote:
On 2017-11-05 08:56:38 +0000, Daniel Sobe wrote:
On 2017-11-09 00:59:42 +0000, Diego wrote:
On 2017-11-13 09:47:25 +0000, Daniel Sobe wrote:
The text was updated successfully, but these errors were encountered: