Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Playlist UI component #901

Closed
4 tasks done
defagos opened this issue May 30, 2024 · 2 comments · Fixed by #986
Closed
4 tasks done

Playlist UI component #901

defagos opened this issue May 30, 2024 · 2 comments · Fixed by #986
Assignees
Labels
enhancement New feature or request

Comments

@defagos
Copy link
Member

defagos commented May 30, 2024

As a developer integrating Pillarbox I need a simple UI component (without any view) to help me keep playlist model objects from my app with the player item playlist managed by a player.

Acceptance criteria

  • A UI component is provided to help manage playlist sync.
  • The UI component is used in the current playlist demo.

Tasks

  • Replace currentIndex API with currentItem API to be able to bind a Player to a List directly.
  • Update playlist demo implementation.
  • Get rid of Template demo stuff if possible.
  • Provide List convenience constructor with a player parameter?
@defagos defagos added the enhancement New feature or request label May 30, 2024
@defagos defagos self-assigned this Aug 19, 2024
@defagos
Copy link
Member Author

defagos commented Aug 20, 2024

There is likely no need for any playlist component. We can rather bind Player directly to a List. This requires:

  1. PlayerItem must be Hashable.
  2. currentItem should be bindable to a List.

The only remaining question is how we can make it easy for a list of model objects to be kept in sync with the list of PlayerItems. Probably making PlayerItem conform to Identifiable is the easiest way. When loading content into the player an app can storet the id - model object relationship to retrieve it later.

@defagos
Copy link
Member Author

defagos commented Aug 20, 2024

No need to conform to Identifiable, and in fact it would make the API more error-prone to use when connected to a List. List namely supports identifiable types and expects that the selection state stores associated identifiers. In our case we want to work with items, both for the list of items as well as for the selection. In such cases it suffices to use \.self as id when creating the List to get the desired behavior, and this is enforced by making PlayerItem not Identifiable. Otherwise the code would compile but no selection would be made, as the type of currentItem and of the identifier, naturally UUID for PlayerItem, would not match.

@defagos defagos linked a pull request Aug 22, 2024 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: ✅ Done
Development

Successfully merging a pull request may close this issue.

1 participant