ayushya/noo
1
0
Fork 0
Code Pull Requests Actions Packages Projects Releases 14 Activity

Make the shell top bar hide/reveal with scroll, per tab

Browse Source 
Each regular tab (Files/Photos/Favorites/Shares/Recent/Activity/Trash)
now plants its own AppTopBar as the first sliver in its own
CustomScrollView, via a new topBarSliver() helper (tab_state_slivers.dart)
wrapping the framework's SliverFloatingHeader, instead of one shared
instance living in Scaffold.appBar.

This gives each tab's top bar Material's native floating-app-bar
behavior - tied to that tab's own ScrollController - scrolling away as
the list scrolls down and reappearing the moment the drag reverses,
not only once scrolled all the way back to the top, which a single
fixed Scaffold.appBar (or the "put it in a SliverToBoxAdapter" escape
hatch NooTopBar's doc comment already mentioned) can't do. It sits
above each tab's own pinned in-content sticky header (the sort/filter
row, or the selection bar that replaces it), which keeps working
unchanged underneath it.

main.dart builds a separate, correctly-labelled AppTopBar per tab
(rather than one for "whichever tab is selected") and passes it through
buildAppTabView's new optional topBar parameter; it's null on desktop
(which keeps its own NooToolbar) and while picking, matching the old
Scaffold.appBar: pickRequest == null guard.

SliverFloatingHeader sizes itself from the bar's own natural layout
(like SliverToBoxAdapter) rather than a fixed extent declared up front,
so NooTopBar's own internal SafeArea keeps handling the status-bar inset
correctly with no extra height math needed on this side.

Adds a widget test (test/widgets/tabs/tab_state_slivers_test.dart)
driving a raw gesture mid-drag to verify the reveal-follows-finger
behavior, since a single tester.drag() only pumps after the gesture -
including release - has already finished, which doesn't exercise the
live per-frame reveal this change depends on.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
ayushya
2026-09-30 16:28:36 -04:00
co-authored by Claude Sonnet 5
parent 5f4caa2a3b
commit 5dea9038f7
13 changed files with 296 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/context/architecture.md
+15 -1
View File
@@ -284,7 +284,21 @@ bare system prompt gives no context on its own.
other tab has a create/upload flow), and the account avatar; Android
gets a compact title row with `search`/avatar actions, relying on an
extended `NooFab` ("Upload", Files/Photos only) instead of a top-bar
icon for upload. `BottomNavBar` (`widgets/bottom_nav_bar.dart`) adapts
icon for upload. Rather than one shared instance in `Scaffold.appBar`,
`MainShellView` builds a separate `AppTopBar` per tab (labelled for that
tab) and each tab plants its own as the first sliver in its own
`CustomScrollView` (`topBarSliver` in `widgets/tabs/tab_state_slivers.dart`,
wrapping it in the framework's `SliverFloatingHeader`) instead of passing
it to `Scaffold.appBar` - see that file's doc comment for why (Material's
native "floating" app bar behavior, tied to that tab's own
`ScrollController`: scrolls away as the list scrolls down and reappears
the moment the drag reverses, not only once scrolled back to the top).
`topBar` is null (no top bar rendered) on desktop and while picking,
matching `Scaffold.appBar`'s old `pickRequest == null` guard - see
`buildAppTabView`'s doc comment. It sits above each tab's own pinned
in-content header (the sort/filter controls row, or Files/Photos'
selection bar - see below); the two float/scroll independently.
`BottomNavBar` (`widgets/bottom_nav_bar.dart`) adapts
the pinned `AppTab`s onto `NooBottomBar`. `AppDrawer`
(`widgets/app_drawer.dart`) builds a `NooDrawer`: account block, storage
meter, a "More" list of the hidden tabs, Settings, and an "Edit tabs"