Skip to content

fix: library content hidden behind soft navigation bar#623

Closed
jeremybernstein wants to merge 1 commit intoutkarshdalal:masterfrom
jeremybernstein:jb/navbar-insets
Closed

fix: library content hidden behind soft navigation bar#623
jeremybernstein wants to merge 1 commit intoutkarshdalal:masterfrom
jeremybernstein:jb/navbar-insets

Conversation

@jeremybernstein
Copy link
Copy Markdown
Contributor

@jeremybernstein jeremybernstein commented Feb 23, 2026

Summary

  • Add navigationBarsPadding() to the library screen container so content isn't hidden behind the soft navbar

Closes #621


Summary by cubic

Fixes Library content hidden behind the soft navigation bar by applying navigationBarsPadding only in Standard mode. Replaces the old status bar toggle with a 3‑mode setting (Immersive, Hidden, Standard) and migrates existing prefs automatically.

  • New Features
    • Added StatusBarMode enum and updated system UI handling to respect each mode.
    • Settings: new Status bar mode picker (SingleChoiceDialog) with restart prompt and current mode shown as the subtitle.

Written for commit a0312a3. Summary will update on new commits.

Summary by CodeRabbit

  • New Features

    • Added a "Status bar mode" setting with three options — Immersive, Hidden, Standard — selectable via a dialog; changing it prompts an app restart to apply.
    • Settings UI now shows the current mode as the subtitle and opens a choice dialog instead of a toggle.
  • Bug Fixes

    • Library screen now consistently accounts for status and navigation bar padding so content no longer overlaps system UI.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Feb 23, 2026

📝 Walkthrough

Walkthrough

Replaces the boolean "hide status bar" preference with a tri-state StatusBarMode (EDGE_TO_EDGE, HIDDEN, INSET), migrates stored preference, updates settings UI to choose a mode (with restart flow), and applies status bar + navigation bar padding changes across LibraryScreen, PluviaMain, and padding utilities.

Changes

Cohort / File(s) Summary
Preference & enum
app/src/main/java/app/gamenative/PrefManager.kt, app/src/main/java/app/gamenative/enums/StatusBarMode.kt
Add StatusBarMode enum and statusBarMode: StatusBarMode preference; migrate from old boolean key to new int key; persist via ordinal.
Settings UI
app/src/main/java/app/gamenative/ui/screen/settings/SettingsGroupInterface.kt
Replace boolean toggle with a single-choice dialog for StatusBarMode; introduce pending selection, open dialog state, and restart-confirmation flow that saves the new mode.
Layout & runtime behavior
app/src/main/java/app/gamenative/ui/screen/library/LibraryScreen.kt, app/src/main/java/app/gamenative/ui/PluviaMain.kt, app/src/main/java/app/gamenative/utils/PaddingUtils.kt
Compute status bar visibility from PrefManager.statusBarMode; apply status-bar-aware top padding and a navBarModifier that conditionally applies navigationBarsPadding() when mode is INSET; update system UI visibility check in PluviaMain.
Resources
app/src/main/res/values/strings.xml
Remove old hide-status-bar strings and add settings_interface_statusbar_mode_title and settings_interface_statusbar_mode_restart_message resources.
LibraryScreen specifics
app/src/main/java/app/gamenative/ui/screen/library/LibraryScreen.kt
Refactor top padding logic to a when(statusBarMode) mapping for list/detail views and apply nav bar modifier to the root Box to account for navigation bar height.

Sequence Diagram(s)

sequenceDiagram
    participant Settings as Settings UI
    participant Pref as PrefManager
    participant App as App (restart)
    participant Pluvia as PluviaMain
    participant Library as LibraryScreen

    Settings->>Pref: set statusBarMode(newMode)
    Pref-->>Settings: persist ack
    Settings->>App: request restart
    App->>Pluvia: initialize
    Pluvia->>Pref: read statusBarMode
    Pluvia->>Pluvia: set system UI visibility (compare to HIDDEN)
    Pluvia->>Library: render with top padding based on statusBarMode
    Library->>Library: apply navigationBarsPadding() when INSET
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

Poem

🐰
I hop through paddings, bits, and mode,
Tuck the bar away or leave its road,
Tiles no longer hide or trip,
Nav and status snugly fit,
A carrot-coded tweak — rejoice and code!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'fix: library content hidden behind soft navigation bar' directly addresses the main objective of issue #621 and accurately summarizes the primary change in the changeset.
Linked Issues check ✅ Passed The PR successfully addresses issue #621 by adding navigationBarsPadding to respect soft navigation insets and implementing a StatusBarMode selection system to control navigation bar padding behavior.
Out of Scope Changes check ✅ Passed All changes directly support the core objective of fixing library content hidden behind soft navigation bar and the secondary redesign of status bar handling into a three-mode system, with no extraneous modifications detected.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
  • 📝 Generate docstrings (stacked PR)
  • 📝 Generate docstrings (commit on current branch)
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@jeremybernstein jeremybernstein moved this to Todo in Open Source Feb 23, 2026
@jeremybernstein jeremybernstein moved this from Todo to PR Needs Review in Open Source Feb 23, 2026
Copy link
Copy Markdown
Contributor

@cubic-dev-ai cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 1 file

@jeremybernstein
Copy link
Copy Markdown
Contributor Author

The filters & custom game addition buttons constantly fight with the nav bar buttons on my Thor. I guess this could be optional if you disagree. In any case, I personally find this to be significantly better.


Box(
Modifier.background(MaterialTheme.colorScheme.background)
.navigationBarsPadding()
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a setting in the app settings for making the app "fullscreen". Probably should not add the padding in that circumstance? have you checked?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Somehow I missed that setting. So if we go with this new setting, I would change that setting to be a menu: show app behind status bar (current default), hide status bar (current "hide status bar" toggle behavior), hide app behind status bar (new thing).

I would probably use it, but it's arguably not necessary. What do you think?

@jeremybernstein jeremybernstein force-pushed the jb/navbar-insets branch 2 times, most recently from 6629550 to 24cfbd8 Compare February 24, 2026 08:10
@jeremybernstein
Copy link
Copy Markdown
Contributor Author

@utkarshdalal ok, this is now reimagined as an extension to the existing "hide status bar" option (there's a third option now for "standard" status bar mode).

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)
app/src/main/java/app/gamenative/ui/screen/settings/SettingsGroupInterface.kt (1)

670-693: ⚠️ Potential issue | 🟡 Minor

Wrong restart message string — user sees language-specific text for a status bar mode change.

R.string.settings_language_restart_message resolves to "Changing the language requires the app to restart. Do you want to continue?" — this is displayed in the status bar mode restart dialog, which is confusing. The settings_interface_statusbar_mode_subtitle string added in strings.xml is closer to correct, but a dedicated confirmation message string would be ideal.

🐛 Proposed fix

Add a dedicated string (e.g., in strings.xml):

<string name="settings_interface_statusbar_mode_restart_message">Changing the status bar mode requires the app to restart. Do you want to continue?</string>

Then update the dialog:

 MessageDialog(
     visible = showStatusBarRestartDialog,
     title = stringResource(R.string.settings_interface_restart_required_title),
-    message = stringResource(R.string.settings_language_restart_message),
+    message = stringResource(R.string.settings_interface_statusbar_mode_restart_message),
     confirmBtnText = stringResource(R.string.settings_language_restart_confirm),
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@app/src/main/java/app/gamenative/ui/screen/settings/SettingsGroupInterface.kt`
around lines 670 - 693, The status bar restart dialog is using the wrong string
resource (R.string.settings_language_restart_message); add a dedicated
confirmation string (e.g., settings_interface_statusbar_mode_restart_message
with text "Changing the status bar mode requires the app to restart. Do you want
to continue?") to strings.xml and update the MessageDialog call in
SettingsGroupInterface (the visible = showStatusBarRestartDialog block) to use
R.string.settings_interface_statusbar_mode_restart_message (or your new
settings_interface_statusbar_mode_restart_message) for the message instead of
the language string; leave the rest of the dialog handlers
(onConfirmClick/onDismissRequest/onDismissClick, pendingStatusBarMode,
showStatusBarLoadingDialog) unchanged.
app/src/main/java/app/gamenative/utils/PaddingUtils.kt (1)

10-13: ⚠️ Potential issue | 🟡 Minor

Stale docstring still references the old boolean semantics.

The KDoc still says "When hideStatusBar is true", which no longer matches the enum-based check.

📝 Suggested update
-     * Creates padding values with conditional top padding based on status bar visibility.
-     * When hideStatusBar is true, top padding is 0.dp, otherwise it uses defaultPadding.
-     * All other sides use defaultPadding.
+     * Creates padding values with conditional top padding based on the current [StatusBarMode].
+     * When the mode is [StatusBarMode.HIDDEN], top padding is 0.dp; otherwise uses defaultPadding.
+     * All other sides use defaultPadding.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/app/gamenative/utils/PaddingUtils.kt` around lines 10 - 13,
The KDoc in PaddingUtils still describes the old boolean behavior ("When
hideStatusBar is true") but the implementation now uses an enum; update the
comment to reference the enum-based parameter (e.g., StatusBarVisibility) and
explain the actual semantics: when the enum value is StatusBarVisibility.HIDDEN
the top padding is 0.dp, otherwise top uses defaultPadding and all other sides
use defaultPadding; ensure the KDoc mentions the parameter name (hideStatusBar
or the current parameter name) and the enum constants used so it matches the
code.
🧹 Nitpick comments (2)
app/src/main/java/app/gamenative/enums/StatusBarMode.kt (1)

3-7: Ordinal-based persistence is fragile — consider name-based storage.

PrefManager stores and reads StatusBarMode by ordinal (0/1/2). Inserting or reordering enum entries in the future silently decodes stored values to the wrong mode (e.g., inserting a new entry before HIDDEN shifts its ordinal and corrupts existing prefs). Storing by name instead of ordinal is immune to reordering.

♻️ Name-based alternative in PrefManager

Change the backing key to a stringPreferencesKey and use StatusBarMode.valueOf():

-private val STATUS_BAR_MODE = intPreferencesKey("status_bar_mode")
+private val STATUS_BAR_MODE = stringPreferencesKey("status_bar_mode")
 var statusBarMode: StatusBarMode
     get() {
-        val value = getPref(STATUS_BAR_MODE, StatusBarMode.EDGE_TO_EDGE.ordinal)
-        return StatusBarMode.entries.getOrNull(value) ?: StatusBarMode.EDGE_TO_EDGE
+        val value = getPref(STATUS_BAR_MODE, StatusBarMode.EDGE_TO_EDGE.name)
+        return runCatching { StatusBarMode.valueOf(value) }.getOrDefault(StatusBarMode.EDGE_TO_EDGE)
     }
     set(value) {
-        setPref(STATUS_BAR_MODE, value.ordinal)
+        setPref(STATUS_BAR_MODE, value.name)
     }

The migration block would similarly write migrated.name instead of migrated.ordinal.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/app/gamenative/enums/StatusBarMode.kt` around lines 3 - 7,
PrefManager currently persists StatusBarMode using ordinal which breaks if enum
entries are reordered; change PrefManager to store the enum by name using a
stringPreferencesKey and read/write via StatusBarMode.valueOf(storedString) (and
write using mode.name), and update any migration logic to write migrated.name
instead of migrated.ordinal so existing stored ordinals are converted to the
correct enum name before switching the preference key.
app/src/main/java/app/gamenative/PrefManager.kt (1)

720-733: Migration-in-getter adds permanent extra I/O overhead on every statusBarMode access.

Every call to statusBarMode always executes runBlocking { dataStore.data.first()[oldKey] } to check for the legacy key — even long after migration is complete (the old key is permanently gone after the first run). This means two blocking DataStore reads per access instead of one, which is particularly costly since statusBarAwarePadding in PaddingUtils.kt calls this getter during Compose recomposition.

Additionally, because removePref and setPref are fire-and-forget (scope.launch), the migration block can execute multiple times before the async remove completes — though the result is idempotent, it generates redundant writes.

The existing init() method is the right place for one-time migration, consistent with how accessToken and refreshToken are migrated:

♻️ Proposed refactor — move migration to init()

In init():

 fun init(context: Context) {
     dataStore = context.datastore
+
+    // Migrate old boolean status bar pref to StatusBarMode enum
+    val oldStatusBarKey = booleanPreferencesKey("hide_status_bar_when_not_in_game")
+    runBlocking { dataStore.data.first()[oldStatusBarKey] }?.let { oldValue ->
+        val migrated = if (oldValue) StatusBarMode.HIDDEN else StatusBarMode.EDGE_TO_EDGE
+        setPref(STATUS_BAR_MODE, migrated.ordinal)
+        removePref(oldStatusBarKey)
+    }
+
     // Note: Should remove after a few release versions...
     val oldPassword = stringPreferencesKey("password")
     removePref(oldPassword)

Then simplify the getter to a single read:

 var statusBarMode: StatusBarMode
     get() {
-        val oldKey = booleanPreferencesKey("hide_status_bar_when_not_in_game")
-        val oldValue = runBlocking { dataStore.data.first()[oldKey] }
-        if (oldValue != null) {
-            val migrated = if (oldValue) StatusBarMode.HIDDEN else StatusBarMode.EDGE_TO_EDGE
-            setPref(STATUS_BAR_MODE, migrated.ordinal)
-            removePref(oldKey)
-            return migrated
-        }
         val value = getPref(STATUS_BAR_MODE, StatusBarMode.EDGE_TO_EDGE.ordinal)
         return StatusBarMode.entries.getOrNull(value) ?: StatusBarMode.EDGE_TO_EDGE
     }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/app/gamenative/PrefManager.kt` around lines 720 - 733, The
getter for statusBarMode currently performs a runBlocking DataStore read to
migrate the old boolean key on every access; move that one-time migration into
init() by checking booleanPreferencesKey("hide_status_bar_when_not_in_game")
there (use runBlocking { dataStore.data.first()[oldKey] }) and if non-null call
setPref(STATUS_BAR_MODE, migrated.ordinal) and removePref(oldKey) once; then
simplify the statusBarMode getter to only call getPref(STATUS_BAR_MODE,
StatusBarMode.EDGE_TO_EDGE.ordinal) and map via
StatusBarMode.entries.getOrNull(value) ?: StatusBarMode.EDGE_TO_EDGE so
subsequent accesses avoid extra I/O and redundant migration attempts.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/res/values/strings.xml`:
- Line 668: The localized string resource
settings_interface_statusbar_mode_subtitle is unused and should be removed; open
the strings.xml entry for "settings_interface_statusbar_mode_subtitle" and
delete that <string> element, then run a project-wide search or Gradle
lint/assemble to confirm no references remain and commit the cleaned file.

---

Outside diff comments:
In
`@app/src/main/java/app/gamenative/ui/screen/settings/SettingsGroupInterface.kt`:
- Around line 670-693: The status bar restart dialog is using the wrong string
resource (R.string.settings_language_restart_message); add a dedicated
confirmation string (e.g., settings_interface_statusbar_mode_restart_message
with text "Changing the status bar mode requires the app to restart. Do you want
to continue?") to strings.xml and update the MessageDialog call in
SettingsGroupInterface (the visible = showStatusBarRestartDialog block) to use
R.string.settings_interface_statusbar_mode_restart_message (or your new
settings_interface_statusbar_mode_restart_message) for the message instead of
the language string; leave the rest of the dialog handlers
(onConfirmClick/onDismissRequest/onDismissClick, pendingStatusBarMode,
showStatusBarLoadingDialog) unchanged.

In `@app/src/main/java/app/gamenative/utils/PaddingUtils.kt`:
- Around line 10-13: The KDoc in PaddingUtils still describes the old boolean
behavior ("When hideStatusBar is true") but the implementation now uses an enum;
update the comment to reference the enum-based parameter (e.g.,
StatusBarVisibility) and explain the actual semantics: when the enum value is
StatusBarVisibility.HIDDEN the top padding is 0.dp, otherwise top uses
defaultPadding and all other sides use defaultPadding; ensure the KDoc mentions
the parameter name (hideStatusBar or the current parameter name) and the enum
constants used so it matches the code.

---

Nitpick comments:
In `@app/src/main/java/app/gamenative/enums/StatusBarMode.kt`:
- Around line 3-7: PrefManager currently persists StatusBarMode using ordinal
which breaks if enum entries are reordered; change PrefManager to store the enum
by name using a stringPreferencesKey and read/write via
StatusBarMode.valueOf(storedString) (and write using mode.name), and update any
migration logic to write migrated.name instead of migrated.ordinal so existing
stored ordinals are converted to the correct enum name before switching the
preference key.

In `@app/src/main/java/app/gamenative/PrefManager.kt`:
- Around line 720-733: The getter for statusBarMode currently performs a
runBlocking DataStore read to migrate the old boolean key on every access; move
that one-time migration into init() by checking
booleanPreferencesKey("hide_status_bar_when_not_in_game") there (use runBlocking
{ dataStore.data.first()[oldKey] }) and if non-null call
setPref(STATUS_BAR_MODE, migrated.ordinal) and removePref(oldKey) once; then
simplify the statusBarMode getter to only call getPref(STATUS_BAR_MODE,
StatusBarMode.EDGE_TO_EDGE.ordinal) and map via
StatusBarMode.entries.getOrNull(value) ?: StatusBarMode.EDGE_TO_EDGE so
subsequent accesses avoid extra I/O and redundant migration attempts.

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2df6b22 and 24cfbd8.

📒 Files selected for processing (7)
  • app/src/main/java/app/gamenative/PrefManager.kt
  • app/src/main/java/app/gamenative/enums/StatusBarMode.kt
  • app/src/main/java/app/gamenative/ui/PluviaMain.kt
  • app/src/main/java/app/gamenative/ui/screen/library/LibraryScreen.kt
  • app/src/main/java/app/gamenative/ui/screen/settings/SettingsGroupInterface.kt
  • app/src/main/java/app/gamenative/utils/PaddingUtils.kt
  • app/src/main/res/values/strings.xml
🚧 Files skipped from review as they are similar to previous changes (1)
  • app/src/main/java/app/gamenative/ui/screen/library/LibraryScreen.kt

Comment thread app/src/main/res/values/strings.xml Outdated
EDGE_TO_EDGE (Immersive), HIDDEN, INSET (Standard) with
SingleChoiceDialog in settings. Migrates old boolean pref
on first access. navigationBarsPadding only in INSET mode.
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
app/src/main/java/app/gamenative/enums/StatusBarMode.kt (1)

1-7: Consider localizing the mode labels if they’re user-facing.

If StatusBarMode.text is shown in UI, hard-coded English strings bypass localization. Consider switching to @StringRes ids.

♻️ Suggested refactor
+import androidx.annotation.StringRes
+import app.gamenative.R
+
-enum class StatusBarMode(val text: String) {
-    EDGE_TO_EDGE("Immersive"),
-    HIDDEN("Hidden"),
-    INSET("Standard"),
-}
+enum class StatusBarMode(`@StringRes` val labelRes: Int) {
+    EDGE_TO_EDGE(R.string.status_bar_mode_immersive),
+    HIDDEN(R.string.status_bar_mode_hidden),
+    INSET(R.string.status_bar_mode_standard),
+}
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/app/gamenative/enums/StatusBarMode.kt` around lines 1 - 7,
The enum StatusBarMode currently stores hard-coded English strings in the text
property; if these are shown in UI, change the enum to hold Android string
resource IDs instead (e.g., rename text to textRes: `@StringRes` Int) and update
all usages to call context.getString(statusBarMode.textRes) or use binding to
resolve the string resource; modify the enum entries (EDGE_TO_EDGE, HIDDEN,
INSET) to pass the appropriate R.string.* ids and update any call sites that
previously relied on StatusBarMode.text to use the resource-resolving approach.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/app/gamenative/PrefManager.kt`:
- Around line 719-733: The migration and default for status bar mode currently
map a false old boolean to StatusBarMode.EDGE_TO_EDGE and default new installs
to EDGE_TO_EDGE, which prevents INSET (which enables navigationBarsPadding())
from being applied; update the migration in the statusBarMode getter to map
oldValue == false to StatusBarMode.INSET (instead of EDGE_TO_EDGE) and change
the getPref default for STATUS_BAR_MODE to StatusBarMode.INSET.ordinal so both
migrated users and new installs get INSET by default; modify only the mapping
and default while keeping the existing setPref(STATUS_BAR_MODE, ...),
removePref(oldKey), and fallback to StatusBarMode.EDGE_TO_EDGE only as a final
null-safe fallback if needed.

---

Nitpick comments:
In `@app/src/main/java/app/gamenative/enums/StatusBarMode.kt`:
- Around line 1-7: The enum StatusBarMode currently stores hard-coded English
strings in the text property; if these are shown in UI, change the enum to hold
Android string resource IDs instead (e.g., rename text to textRes: `@StringRes`
Int) and update all usages to call context.getString(statusBarMode.textRes) or
use binding to resolve the string resource; modify the enum entries
(EDGE_TO_EDGE, HIDDEN, INSET) to pass the appropriate R.string.* ids and update
any call sites that previously relied on StatusBarMode.text to use the
resource-resolving approach.

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 24cfbd8 and a0312a3.

📒 Files selected for processing (7)
  • app/src/main/java/app/gamenative/PrefManager.kt
  • app/src/main/java/app/gamenative/enums/StatusBarMode.kt
  • app/src/main/java/app/gamenative/ui/PluviaMain.kt
  • app/src/main/java/app/gamenative/ui/screen/library/LibraryScreen.kt
  • app/src/main/java/app/gamenative/ui/screen/settings/SettingsGroupInterface.kt
  • app/src/main/java/app/gamenative/utils/PaddingUtils.kt
  • app/src/main/res/values/strings.xml
🚧 Files skipped from review as they are similar to previous changes (3)
  • app/src/main/java/app/gamenative/ui/PluviaMain.kt
  • app/src/main/java/app/gamenative/ui/screen/settings/SettingsGroupInterface.kt
  • app/src/main/java/app/gamenative/utils/PaddingUtils.kt

Comment thread app/src/main/java/app/gamenative/PrefManager.kt
@jeremybernstein
Copy link
Copy Markdown
Contributor Author

@utkarshdalal now stable, ready for review

@utkarshdalal
Copy link
Copy Markdown
Owner

utkarshdalal commented Feb 24, 2026

@jeremybernstein can you show me an example of what the soft navigation bar looks like? Is it the android bar at the bottom with the back, home and recent apps button?

If so, I think perhaps best to not add more options there. We have a UI overhaul coming soon, which I believe puts the app in fullscreen mode. I'm not sure how the bottom bar will be affected by that but might be good to wait for that first.

takeaway is let's not add a third option to the display in addition to show and hide status bars, we should update the existing toggle to hide all status bars (edge to edge mode) or keep it normal, and if the bottom navigation bar is showing, add padding there.

@jeremybernstein
Copy link
Copy Markdown
Contributor Author

Immersive (current default, toggle off):
Screenshot_20260225-004042

Status hidden (current toggle on):
Screenshot_20260225-004101

New mode:
Screenshot_20260225-004118

@jeremybernstein
Copy link
Copy Markdown
Contributor Author

Fine with waiting for UI overhaul.

@jeremybernstein
Copy link
Copy Markdown
Contributor Author

irrelevant with new UI, closing

@github-project-automation github-project-automation Bot moved this from PR Needs Review to Done in Open Source Feb 28, 2026
@jeremybernstein jeremybernstein deleted the jb/navbar-insets branch March 17, 2026 08:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

Library content hidden behind soft navigation bar

2 participants