Handle back presses gracefully without finicky behavior when doing back
gestures.
I've spent far too much time trying to make this sensible. I'm going to
take a break.
The stock overlay is not sufficient for our needs, as:
1. It seemingly cannot be set up without missing certain touch areas or
disabling the touch area of the speed dial itself
2. The scrim can't be evenly applied everywhere in the app due to the
nested expore UI.
So, modify the speed dial to work without a scrim and reimplement the
overlay touch behavior manually.
When reimporting an M3U file into a playlist, if the name differs, then
initiate a rename dialog so the user has a choice on whether they want
to use the new name or not.
This does kinda desecrate the "Rename" decision a bit, but it's still
to the user the same.
When you import a playlist, Auxio will now always display the
"New Playlist" dialog so you can change whatever name Auxio has picked
for the imported playlist.
This also prevents the creation of two playlists with the same names.
The context of the "New Playlist" dialog can differ depending on the
action performed, such as adding to a playlist or importing a playlist.
We need to make sure we're still showing the right message once this
is done.
Add more types of playlist messages corresponding to other actions, so
they can be indicated in the UI only when the process is complete.
This is somewhat incomplete. It does not include indicating errors for
other playlist operations (Which I want to do), and neither does it
handle situations in which some playlist operations and up reducing
to others (i.e import -> create). I need to do that later.
Add a menu option that allows you to import a playlist file into an
existing playlist.
This is useful for keeping Auxio playlists up to date with a remote
source.
Add a dialog that shows the stack trace of a music loading error.
This is an MVP that is only available to music loading to resolve some
immediate issues.
Resolves#527.
Add play and shuffle options for all song menus.
These will override the shuffle state, unlike other song play
interactions.
This required a good bit of refactoring to menu, some of which
might be ported to other commands in future changes.
Rename MusicMode to MusicType.
The original naming was always a bit clunky given that it referred to
both settings and data configuration. I feel that "Type" is probably
better overall.
Use PlaySong modeling within settings too. This largely completes the
PlaySong refactor and fully adds the ability to play songs by
themselves as an option.
Resolves#424.
Add the scaffold for PlaySong, a new version of playback modes that
- Supports playback of a song by itself, requested by #424.
- Will make direct playback from the song menu feasible (given
additional reworks)
- Prevents the invalid state of playing a song by it's playlist,
as the sealed interface implementation of PlaySong requires a Playlist
to be provided to it's respective variant.
Unify the disjoint selection and menu viewmodels into a single
ListViewModel.
This is technically not fully done, as MenuViewModel remains as a
backing element of the menu dialogs, but otherwise that's it.
Standardize navigation command consumption to only occur when a
navigation route has *definitively* ended. If more commands could
come, observe them. Otherwise, consume immediately.
Bit of a megapatch that:
- Adds dedicated play, shuffle, and view items to all item menus
(songs haven't been fully implemented yet)
- Adds icons to all item menus
- Re-adds enabled/disabled items to menus
- Makes menu action naming conventions more consistent with the rest
of the app
Use the new menu system in all applicable places.
More consideration is needed right now on whether the toolbars should
also have menu items, so they remain unchanged right now.
Add a dialog that shows menu information as a bottom sheet instead of as
a PopupMenu.
This did not take as much finessing of BottomSheetBehavior as the main
playback UI framework did, just some style redefinitions.
