Shift + D doesn't clear the whole playlist if pressed without focusing the playlist section of the UI

[Porkepix]

Environment & Versions

• System: ArchLinux
• Termusic version: Latest master from AUR: v0.12.0-52-gd450a92f[g]
• Rust version: N/A

Description of the Problem

This might be reconsidered as feature request rather than bug depending on how it's seen, or even considered as intended behavior and as such closed.

Shortcut to delete a track from playlist is d and all tracks from the playlist is shift + d. While first certainly requires to go and select the track, switching side with <TAB>, the second could be done while staying on the library side: I got confused I had to actually move on the playlist side to use it, thinking it should work in every case where the playlist is visible, especially when we're in position of adding more tracks to this playlist, being into the library or database.

[hasezoey]

Personally, i wouldnt want playlist modifying behavior to be global and only run when the playlist is focused (except adding more tracks, which has context from a different component).

[Porkepix]

Personally, i wouldnt want playlist modifying behavior to be global and only run when the playlist is focused (except adding more tracks, which has context from a different component).

On one hand I agree, on the other, context here is: I go on a folder and I want to add it and only this to play to the playlist.
I need to switch to playlist, clear it and then go back to the library and add it, as opposed to: clear the playlist and add this, two keystroke in one case vs 4 because you need to switch twice in-between.
Probably no perfect solution/answer that would fit to everybody here.

[hasezoey]

I go on a folder and I want to add it and only this to play to the playlist.

Oh, you mean for this case. Yes i can totally understand.

I have already through about this and have a proposal to implement, though i would prefer to have context menus, optional keybinds and multi-playlist(multi-queue) implemented beforehand, because i would like to do it like my favorite android music player:

• have the possibility for multiple playlists / queues
• on "play all in X"(where could be "folder"), have a option to create a new queue or add all in current playlist at the end / add all in current playlist directly after the currently playing track

What do you think about that?

[Porkepix]

I don't really have a opinion here:
What's called playlist in Termusic sounds rather like the currently playing queue to me (and I was always surprised by that wording. Although a queue would need to have the sound removed once played).
Playlists as seen elsewhere, ie. a saved (in a file or software) and named list of titles to play together isn't really something I'm using.

My usage with players on Android is most of the time limited to play a shuffle all of all the songs I have on the card.
It's quite rare I target something specific to play.

So for your two options:

• Multiple playlists isn't something I'd use much (I think), multiple queues I'm not sure how this would materialize in Termusic;
• How would this choice materialize? Small popup like when we quit? Different shortcut for both options?

[hasezoey]

What's called playlist in Termusic sounds rather like the currently playing queue to me (and I was always surprised by that wording. Although a queue would need to have the sound removed once played).

I also think that and thought it should be renamed to queues (especially once multiple playlists (or then queues)) are implemented.

How would this choice materialize? Small popup like when we quit? Different shortcut for both options?

I imagine the flow being like this:

• the current keybindings will stay how they are
• there will be a new keybinding to open a context menu (this will be a global-ish keybind, like navigation)
  • with this new keybind you can select all options available (including delete, yank, and multiple play options)
• alternatively, i think about maybe introducing a optional keybind that can be bound to do a specific play action (of the new ones) (or open the context menu with the playoptions already open, if it is a submenu)
• maybe also add a new option to choose the default behavior for "add all" (the options include add to the end of the current playlist, add after the currently played track in the current playlist and add as new queue)

And maybe something else.

[Porkepix]

I also think that and thought it should be renamed to queues (especially once multiple playlists (or then queues)) are implemented.

I also think it'd be better, although if I'm not mistaken current playlist implementation only remove tracks and random isn't enabled, which is fine to me and I prefer it like that. But I also think the general expectation for a queue is to remove the entry once it's been played.

alternatively, i think about maybe introducing a optional keybind that can be bound to do a specific play action (of the new ones) (or open the context menu with the playoptions already open, if it is a submenu)

You're thinking, like the right click on a file/entry in a graphical file manager or, say VLC?
Or some textual/completion of commands, thinking rather palette/omnibar from different softwares?

[hasezoey]

I also think it'd be better, although if I'm not mistaken current playlist implementation only remove tracks and random isn't enabled, which is fine to me and I prefer it like that. But I also think the general expectation for a queue is to remove the entry once it's been played.

I guess i can understand that assumption if it would be named "Queue", though personally, i will still have it as a mode (also see #134 & #181) and would still rename it, to have a difference between playlists (as in on disk, like files) and queues (as in the currently added playing tracks).

You're thinking, like the right click on a file/entry in a graphical file manager or, say VLC?

Yes.

Just to get a reference point, this is how it looks in my android music player

This is what happens if the context menu is opened on a single file:

And this when opened on a playlist:

Also note that some of the options shown are configurable in the music player.

PS: the android music player i use is Musicolet.

[Porkepix]

I also think it'd be better, although if I'm not mistaken current playlist implementation only remove tracks and random isn't enabled, which is fine to me and I prefer it like that. But I also think the general expectation for a queue is to remove the entry once it's been played.

I guess i can understand that assumption if it would be named "Queue", though personally, i will still have it as a mode (also see #134 & #181) and would still rename it, to have a difference between playlists (as in on disk, like files) and queues (as in the currently added playing tracks).

Keeping tracks in the queue even after they've been played can be pretty handy too, though. Especially as for now it can request some efforts to readd everything in this list.

You're thinking, like the right click on a file/entry in a graphical file manager or, say VLC?

Yes.
Just to get a reference point, this is how it looks in my android music player

This is what happens if the context menu is opened on a single file:

And this when opened on a playlist:

Also note that some of the options shown are configurable in the music player.

PS: the android music player i use is Musicolet.

It's difficult for me to see how it would look like exactly with a terminal player though, but we'll see.

Out of curiosity, how are managed parallel playlists and what is "RG" in the options?

I don't know this player, but I pretty much only install Free Software, mainly what can be found on F-droid.
There are a couple of quite nice players, but not this one.

[hasezoey]

how are managed parallel playlists

Either what did you mean with that, or where did you see that?

and what is "RG" in the options?

ReplayGain, also see #284.
TL;DR: consistent gain/volume across tracks / albums (depending on setting)

[Porkepix]

how are managed parallel playlists

Either what did you mean with that, or where did you see that?

Sorry, the word maybe wasn't a good pick for English. I mean, your player offer to add to current queue or to another queue: how does it manage to have many queues at the same time? Can you switch between them?