Use a constant page limit of 5 instead of a dynamic page limit.
This was not being properly updated prior, and since the ViewPager
already clamps it, the limit does not really need to be based on the
tab size anyway.
Handle two edge cases identified with the playing indicator behavior:
1. When enqueing songs from another parent, the prior parent is still
indicates as "playing" when it kind-of isn't.
2. When playback is stopped, the parent is not reset, and thus will
still be indicated as "playing" after the song has disappeared. This
is rarer and should be resolved in other ways, but the solution to
1 also fixes this.
Resolves#380.
Group albums implicitly linked to an artist via the "artist" tag into
their own section called "Appears on".
This makes Auxio's artist model a bit more apparent to users.
Resolves#411.
Fix a few issues with the tab migration:
1. It wasn't even being ran
2. It incorrectly updated the tabs by adding a playlist tab when it was
actually already present.
Move the music editing state to the toolbar.
This should be signifigantly clearer than prior, at the cost of it's
"universality" implying that renaming should be available when it
actually won't be.
Add a real playlist naming dialog and UX flow.
This is a bit rough at the moment since theres a good amount of nuance
here. Should improve as the playlist implementation continues to grow
more fleshed out.
Refactor the music name implementation to do the following:
1. Unify normal and sort names under a single datatype
2. Handle arbitrary-length digit strings
3. Ignore puncutation regardless of the intelligent sort
configuration, as it is trivially localizable.
Resolves#423.
Co-authored by: ChatGPT-3.5
Refactor the weird picker god module into specific sub-impls in
playback and a new navigation package.
I cannot keep this unified. The needs are too different among each
picker. Better to keep it separate, especially in preparation for
the playlist dialogs.
Refactor the disjoint Library and Playlist setup into two new
DeviceLibrary and UserLibrary implementations.
This makes the API surface a bit less disjoint than prior.
Unify Indexer and MusicRepository into a single class.
This is meant to create a single dependency on PlaylistDatabase and
reduce the amount of orchestration.
Re-add the fine-grained updates that were removed prior due to state
concerns.
This time they should be safe enough to use, as the differ has been
fully vendored. The change is not complete enough however, as the queue
view has not been properly ported to use these updates just yet.
Fix visual clipping on the shuffle FAB's shadow.
Turns out padding, while slower, is actually the better inset handling
method, as it allows me to avoid visual clipping in some cases.
Use @Binds more heavily with dependency injection, whee currently
reasonable.
Reduces the amount of boilerplate "fun from" functions that need to be
used.
Make sorting direction (ascending/descending) explicit in the UI and in
the code.
Instead of a boolean flag, two distinct "ascending" and "descending"
options are used instead. This should be much clearer.
Start injecting shared object instances.
This is not a 100% conversion, as certain portions of the code are not
really ready for 100% DI constructors just yet.
Hide the MusicStore implementation behind an interface, transforming it
into a new MusicRepository class.
This is in preparation for dependency injection.
Disable the new instructions-based system for now.
The way I was doing reflection was likely far too unsafe and prone to
bugs. I'll want to do it some other way.
Completely rework the detail list implementations so that resorting the
song list causes a replace operation instead of a diff operation.
This finally makes the list experience consistent across the app.
Redesign the header component to be more aligned with M3 guidelines.
This includes moving the divider to the top when reasonable, using a
smaller font size, and using a tinted coloration to separate itself
from the list contents.
Make list instructions generic in preparation for the detail list
update.
Detail views need their own instructions datatype, so this is meant to
allow that to be implemented without issue.
