Search from the volume list, and type into the field without a second tap
Two papercuts in the search added in the previous commits, both found by using it. BrowserContent decided between the volume list and a folder listing on path == null alone, so on the "Storage" screen the roots were drawn over the answer: a search everywhere from there was computed and never shown. The switch now also asks whether a search is running - its results are full paths, so nothing has to be open first - and the volume list is drawn only when there is neither a folder nor a search. Opening the field on that screen also switches the scope to everywhere, since "this folder" has no meaning with no folder open and the field's hint would otherwise invite a query that could never match. The view model makes the same fallback on its own, so a query typed from the volume list is answered everywhere whether or not the scope was switched. Tapping the search action now focuses the field and brings the keyboard with it, waiting for the frame the field appears in, because focusing a node that is not attached yet does nothing. Asking the user to tap the box they just opened was a tap of pure ceremony. The wide layout no longer focuses the first root while a search is running, which would have moved the detail pane under the results. 289 JVM tests, lint clean, release APK builds. No device pass: /dev/kvm is still absent from this environment, so the emulator cannot start - the focus change in particular is verified by compile and by reading the API contract, not by watching a keyboard appear.
This commit is contained in:
@@ -12,6 +12,20 @@ upload needs a **higher `versionCode`** than every previous upload.
|
||||
|
||||
### Fixed
|
||||
|
||||
- **Searching needed a volume to be open first, and needed a second tap to be typed into.** Two
|
||||
papercuts in the feature added above, both found by using it. `BrowserContent` decided between
|
||||
the volume list and a folder listing on `path == null` alone, so on the "Storage" screen the
|
||||
roots were drawn *over* the answer: a search everywhere from there was computed and never
|
||||
shown. The switch now also asks whether a search is running — its results are full paths, so
|
||||
nothing has to be open first — and the volume list is drawn only when there is neither a folder
|
||||
nor a search. Opening the field there also switches the scope to everywhere, because "this
|
||||
folder" has no meaning with no folder open and the field's own hint would otherwise invite a
|
||||
query that could never match; the view model makes the same fallback on its own, so a query
|
||||
typed from the volume list is answered everywhere whether or not the scope was switched. And
|
||||
tapping the search action now focuses the field and brings the keyboard up with it: it waited
|
||||
for the frame the field appears in, because focusing a node that is not attached yet does
|
||||
nothing, and asking the user to tap the box they just opened was one tap of pure ceremony.
|
||||
|
||||
- **The progress notification never appeared on Android 13 or newer, and five permissions were
|
||||
declared that the app never used.** `StorageAccessPolicy.missingPermissions` returned an empty
|
||||
list from API 33 on the reasoning that "all files access" is a special permission rather than
|
||||
|
||||
Reference in New Issue
Block a user