Take the empty toolbar off the screen - #542
Merged
Merged
Conversation
andiwand
force-pushed
the
landing/09-document-action-buttons
branch
from
July 27, 2026 22:01
bc5ef20 to
7f293d8
Compare
andiwand
force-pushed
the
landing/10-drop-empty-action-bar
branch
from
July 27, 2026 22:01
95c2c3d to
e5a5631
Compare
andiwand
force-pushed
the
landing/09-document-action-buttons
branch
from
July 28, 2026 07:44
7f293d8 to
7ad72b3
Compare
andiwand
force-pushed
the
landing/10-drop-empty-action-bar
branch
from
July 28, 2026 07:44
e5a5631 to
6d0423a
Compare
andiwand
force-pushed
the
landing/09-document-action-buttons
branch
from
July 28, 2026 19:00
7ad72b3 to
4b8e9d0
Compare
Nothing has been left in the options menu: the landing screen carries its own headers, the open action went away with the direct picker, the ad removal moved into the settings section and the document's actions moved down to the buttons by the thumb. What stayed behind is an empty strip of colour at the top of every screen. The bar cannot simply be dropped though - it is where the action modes appear. find, tts and edit are all raised with startSupportActionMode(), and appcompat puts them in the ActionBar's own container, in place of the toolbar. So rather than moving to a .NoActionBar theme, MainActivity hides the bar on start and lets appcompat bring the container back for as long as a mode is up: checkShowingFlags() shows it whenever an action mode is showing, whatever the app asked for, and takes it away again when the mode finishes. That also leaves the window insets alone. ActionBarOverlayLayout keeps the system bar insets off the content and reports the toolbar's height on to the app as an inset of its own, which is what MainActivity's listener pads main_root with - so the find bar pushes the page down by exactly its own height, and nothing pads anything while no mode is up. A NoActionBar theme would swap that decor for a FitWindowsLinearLayout, which pads itself by the system bars on top of the padding MainActivity already applies. The fullscreen hide()/show() pair goes with it: with the bar hidden for good there is nothing left for it to toggle, and show() would have put the empty bar back on leaving fullscreen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LrDgmtcnqm8xEUtt42cTDd
andiwand
force-pushed
the
landing/10-drop-empty-action-bar
branch
from
July 28, 2026 19:06
6d0423a to
df5948a
Compare
andiwand
marked this pull request as ready for review
July 28, 2026 19:07
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: df5948ac5b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
andiwand
added a commit
that referenced
this pull request
Jul 28, 2026
Nothing has been left in the options menu: the landing screen carries its own headers, the open action went away with the direct picker, the ad removal moved into the settings section and the document's actions moved down to the buttons by the thumb. What stayed behind is an empty strip of colour at the top of every screen. The bar cannot simply be dropped though - it is where the action modes appear. find, tts and edit are all raised with startSupportActionMode(), and appcompat puts them in the ActionBar's own container, in place of the toolbar. So rather than moving to a .NoActionBar theme, MainActivity hides the bar on start and lets appcompat bring the container back for as long as a mode is up: checkShowingFlags() shows it whenever an action mode is showing, whatever the app asked for, and takes it away again when the mode finishes. That also leaves the window insets alone. ActionBarOverlayLayout keeps the system bar insets off the content and reports the toolbar's height on to the app as an inset of its own, which is what MainActivity's listener pads main_root with - so the find bar pushes the page down by exactly its own height, and nothing pads anything while no mode is up. A NoActionBar theme would swap that decor for a FitWindowsLinearLayout, which pads itself by the system bars on top of the padding MainActivity already applies. The fullscreen hide()/show() pair goes with it: with the bar hidden for good there is nothing left for it to toggle, and show() would have put the empty bar back on leaving fullscreen. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Last one in the stack, and the one that makes the rest of it look finished: after the open action, the ad removal and the document buttons all moved out of the options menu, the toolbar is an empty strip of colour at the top of every screen.
It cannot just be deleted, because it is also where the action modes live.
find,ttsandeditare raised withstartSupportActionMode(), and appcompat puts those in the ActionBar's own container in place of the toolbar. So instead of a.NoActionBartheme,MainActivityhides the bar on start, and appcompat brings the container back on its own for as long as a mode is up -checkShowingFlags()shows it whenever an action mode is showing, whatever the app asked for.That also keeps the window insets as they are.
ActionBarOverlayLayoutholds the system bar insets off the content and reports the toolbar's height onwards as an inset of its own, which is whatMainActivity's listener padsmain_rootwith: the find bar pushes the page down by exactly its own height, and nothing is padded while no mode is up. ANoActionBartheme swaps that decor for aFitWindowsLinearLayout, which pads itself by the system bars on top of the paddingMainActivityalready applies.The fullscreen
hide()/show()pair goes with it - with the bar hidden for good there is nothing to toggle, andshow()would have put the empty bar back on leaving fullscreen.Checked on a Pixel 6 Pro (API 36)
./gradlew spotlessCheck lintProDebug testProDebugUnitTestclean, and all 20 instrumented tests pass on the emulator.🤖 Generated with Claude Code