Skip to content

Take the empty toolbar off the screen #542

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
andiwand merged 1 commit into from
Jul 28, 2026
Merged

Take the empty toolbar off the screen #542

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 7 additions & 5 deletions app/src/main/java/app/opendocument/droid/ui/activity/MainActivity.kt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -177,7 +177,13 @@ class MainActivity : AppCompatActivity(), MenuProvider {
WindowInsetsCompat.CONSUMED
}

title = ""
// nothing lives in the toolbar any more - the landing screen has its own header and the
// document its buttons - so the bar would just be an empty strip of colour. Hiding it
// rather than moving to a .NoActionBar theme keeps it as the host the action modes are
// raised in: appcompat shows the container again for as long as one is up, and takes it
// back down afterwards, so find, tts and edit still get their bar without the app
// having to put one on screen itself.
supportActionBar?.hide()
Comment thread
andiwand marked this conversation as resolved.

onBackPressedDispatcher.addCallback(this, backCallback)

Expand Down Expand Up @@ -480,8 +486,6 @@ class MainActivity : AppCompatActivity(), MenuProvider {
WindowInsetsControllerCompat.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE
insetsController.hide(WindowInsetsCompat.Type.statusBars())

supportActionBar?.hide()

// delay offer to wait for fullscreen animation to finish
handler.postDelayed(
{
Expand Down Expand Up @@ -591,8 +595,6 @@ class MainActivity : AppCompatActivity(), MenuProvider {
return
}

supportActionBar?.show()

WindowCompat.getInsetsController(window, window.decorView)
.show(WindowInsetsCompat.Type.statusBars())

Expand Down
9 changes: 7 additions & 2 deletions app/src/main/res/values/themes.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,13 @@
have to add what is specific to them. Copying the whole theme per qualifier is what let
the colours drift apart before.

Not a .NoActionBar variant: there is no Toolbar view anywhere, the app relies on the
default ActionBar and drives it through supportActionBar / startSupportActionMode.
Not a .NoActionBar variant, even though no screen puts anything in the bar any more:
the ActionBar's container is what startSupportActionMode() raises find, tts and edit
in, and appcompat only shows it for as long as one of them is up. MainActivity hides
the bar itself on start, so the container is off screen the rest of the time and the
window inset math stays the one ActionBarOverlayLayout does - which a NoActionBar
theme would swap for a decor that pads itself, on top of the padding MainActivity
applies.
-->
<style name="Base.MainTheme" parent="Theme.Material3.DayNight">
<item name="colorPrimary">@color/md_primary</item>
Expand Down
Loading