[PR #293] [MERGED] Add support for 'Remove from playlist' #471

Closed
opened 2026-02-28 14:33:08 +03:00 by kerem · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/jpochyla/psst/pull/293
Author: @itsjunetime
Created: 4/13/2022
Status: Merged
Merged: 8/15/2022
Merged by: @jpochyla

Base: masterHead: remove_from_playlist


📝 Commits (5)

  • 2120b73 Add support for 'Remove from playlist'
  • 84755b8 Fix formatting for CI
  • eba4418 gui: Remove playlist backlink from Track
  • fe03126 Conditionally show 'Remove from playlist' depending on whether you can edit the playlist or not
  • 2aa4be7 Fix formatting for CI

📊 Changes

8 files changed (+128 additions, -11 deletions)

View changed files

📝 psst-gui/src/data/mod.rs (+14 -1)
📝 psst-gui/src/data/playlist.rs (+6 -0)
📝 psst-gui/src/ui/playable.rs (+6 -0)
📝 psst-gui/src/ui/playback.rs (+3 -1)
📝 psst-gui/src/ui/playlist.rs (+26 -1)
📝 psst-gui/src/ui/search.rs (+2 -3)
📝 psst-gui/src/ui/track.rs (+53 -3)
📝 psst-gui/src/webapi/client.rs (+18 -2)

📄 Description

This adds support for the 'Remove from playlist' option when right-clicking on a track within a playlist. Clicking this button will remove the track from the playlist, show a banner at the bottom of the window stating if it succeeded or failed, and reload the list of tracks so that it is fully updated (ideally it would just remove that specific track from the list currently displayed, but I wasn't able to figure out how to do that :).

I like nearly everything about how I set this up, besides how I decided to implement storing the data about the current playlist. I added another parameter to Track called current_playlist, which stores the PlaylistLink of the currently displayed playlist (if it is being displayed in a playlist, otherwise None). This is not ideal for two reasons:

  1. The PlaylistLink is stored once for every track in the playlist, which is just unnecessary data duplication since it is the same for every track.
  2. The currently displayed playlist is UI data, not intrinsic data about the track itself.

Ideally, I would've liked to store the data about the current playlist in track::Display, but I couldn't find any way to pass that data in - it seems that track::Display is constructed without knowledge of any external context. Since the only other way to pass in data to the track's context menu is through the Track or Library, I thought that storing the data on Track would make the most sense. If it was stored on Library, there's a higher chance of it getting out-of-sync with what playlist is actually being displayed, and Track is destroyed when the view moves away, so we don't have to worry as much about the data not being tracked correctly.

If someone has better ideas about how to pass the data through, I welcome all suggestions :)


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/jpochyla/psst/pull/293 **Author:** [@itsjunetime](https://github.com/itsjunetime) **Created:** 4/13/2022 **Status:** ✅ Merged **Merged:** 8/15/2022 **Merged by:** [@jpochyla](https://github.com/jpochyla) **Base:** `master` ← **Head:** `remove_from_playlist` --- ### 📝 Commits (5) - [`2120b73`](https://github.com/jpochyla/psst/commit/2120b738b849ddf93243f53639d7761bbcb46cad) Add support for 'Remove from playlist' - [`84755b8`](https://github.com/jpochyla/psst/commit/84755b83c99044be0c960eb573df84b32036f417) Fix formatting for CI - [`eba4418`](https://github.com/jpochyla/psst/commit/eba44189c7539d57587a50a4f5589dcbf109b721) gui: Remove playlist backlink from Track - [`fe03126`](https://github.com/jpochyla/psst/commit/fe03126b174f6fbd1a265ae05508590483dcac27) Conditionally show 'Remove from playlist' depending on whether you can edit the playlist or not - [`2aa4be7`](https://github.com/jpochyla/psst/commit/2aa4be7cb5f1b08c62a15062f067d847ea477757) Fix formatting for CI ### 📊 Changes **8 files changed** (+128 additions, -11 deletions) <details> <summary>View changed files</summary> 📝 `psst-gui/src/data/mod.rs` (+14 -1) 📝 `psst-gui/src/data/playlist.rs` (+6 -0) 📝 `psst-gui/src/ui/playable.rs` (+6 -0) 📝 `psst-gui/src/ui/playback.rs` (+3 -1) 📝 `psst-gui/src/ui/playlist.rs` (+26 -1) 📝 `psst-gui/src/ui/search.rs` (+2 -3) 📝 `psst-gui/src/ui/track.rs` (+53 -3) 📝 `psst-gui/src/webapi/client.rs` (+18 -2) </details> ### 📄 Description This adds support for the 'Remove from playlist' option when right-clicking on a track within a playlist. Clicking this button will remove the track from the playlist, show a banner at the bottom of the window stating if it succeeded or failed, and reload the list of tracks so that it is fully updated (ideally it would just remove that specific track from the list currently displayed, but I wasn't able to figure out how to do that :). I like nearly everything about how I set this up, besides how I decided to implement storing the data about the current playlist. I added another parameter to `Track` called `current_playlist`, which stores the `PlaylistLink` of the currently displayed playlist (if it is being displayed in a playlist, otherwise `None`). This is not ideal for two reasons: 1. The `PlaylistLink` is stored once for every track in the playlist, which is just unnecessary data duplication since it is the same for every track. 2. The currently displayed playlist is UI data, not intrinsic data about the track itself. Ideally, I would've liked to store the data about the current playlist in `track::Display`, but I couldn't find any way to pass that data in - it seems that `track::Display` is constructed without knowledge of any external context. Since the only other way to pass in data to the track's context menu is through the `Track` or `Library`, I thought that storing the data on `Track` would make the most sense. If it was stored on `Library`, there's a higher chance of it getting out-of-sync with what playlist is actually being displayed, and `Track` is destroyed when the view moves away, so we don't have to worry as much about the data not being tracked correctly. If someone has better ideas about how to pass the data through, I welcome all suggestions :) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
kerem 2026-02-28 14:33:08 +03:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/psst#471
No description provided.