Bug 406469

The single click like for the gird views allows to select the current item. That is to make it usable with touch screens.
The highlight effect is also necessary to make the application usable by keyboard (useful for everybody but especially people not able to make a good use of a mouse). Without the effect for the current item inside a view, you cannot know what is the current track when navigating with keyboard.

I just noticed that double-click was supposed to work, but was broken, which I just fixed with https://cgit.kde.org/elisa.git/commit/?id=8847e836f16841d42530ccef63d084fce28ac8c6 (hope you don't mind me pushing directly).

With double-click working, this is less urgent.

Re-titling now that double-click works (we can discuss single-click later). I would definitely prefer double-click-to-play, but I can see how others might prefer to have the double-clicked song enqueued instead. Maybe it should be configurable.

I agree.
Do you know if somebody could help me with the design part of a more capable KCM for Elisa ?

I would be happy to help with or create such a design.

*** Bug 420684 has been marked as a duplicate of this bug. ***

Hi is this issue still open

yes

*** Bug 428833 has been marked as a duplicate of this bug. ***

From duplicate bug report Bug 428833: when double-clicking on a song and the behavior is set to "Play", we should do the following:

1. Replace the playlist with the full set of music currently visible in the browse view
2. Begin playback from the double-clicked song

...And in fact that's already tracked with Bug 417610.

(In reply to Nate Graham from comment #11)
> ...And in fact that's already tracked with Bug 417610.

I'm sorry to hijack this, but why is development for this so slow? I understand there are not many staff, but these kind of issues sound rather simple to implement? Or am I wrong? But it's been almost year and a half since first reported.

> I understand there are not many staff
I think you answered your own question. :)

In fact there is no staff at all if you mean paid engineers. The primary developer is a volunteer, as are most of the drive-by contributors. I am paid to work on KDE stuff, but not on Elisa specifically, and I only have time for Elisa when I'm done with my other KDE work (so in essence I am also a volunteer for the Elisa project specifically).

If the feature in question seems simple to implement, please feel to take a crack at it. We would welcome additional engineering resources!

(In reply to Nate Graham from comment #13)
> > I understand there are not many staff
> I think you answered your own question. :)
> 
> In fact there is no staff at all if you mean paid engineers. The primary
> developer is a volunteer, as are most of the drive-by contributors. I am
> paid to work on KDE stuff, but not on Elisa specifically, and I only have
> time for Elisa when I'm done with my other KDE work (so in essence I am also
> a volunteer for the Elisa project specifically).
> 
> If the feature in question seems simple to implement, please feel to take a
> crack at it. We would welcome additional engineering resources!

I wish I could! Really, no joke. Currently I have some free time. I tried fixing the lyrics feature for JuK, trying to find the new API and all, but ultimately failed, as I'm no programmer.

The best thing I can do is to file bug reports and UI enhancements. Wish I could do more, esp. for Elisa and JuK as I think those two have a lot of potential, with Elisa being even more advanced and most polished KDE music player.

This particular bug looked like it was mostly maintained by you, so I was wondering what was going on. It just seemed overlooked by the dev.

What's going on is that there are only 24 hours in the day. :) Oh, what we could do with just a few more...

A possibly relevant merge request was started @ https://invent.kde.org/multimedia/elisa/-/merge_requests/362

*** Bug 465545 has been marked as a duplicate of this bug. ***

*** Bug 467347 has been marked as a duplicate of this bug. ***

Git commit bcc52c704cc929c35109f4bc80834e48607e2a6a by Nate Graham.
Committed on 28/04/2023 at 13:57.
Pushed by ngraham into branch 'master'.

Add feature to replace playlist with whole view contents on double-click

Some people are accustomed to double-clicking on a song in album list
views to replace the playlist with that album and start playing from the
double-clicked song. This commit makes that the new default behavior,
though it can be disabled.
Related: bug 417610, bug 417284
FIXED-IN: 22.08

M  +5    -0    src/elisa_core.kcfg
M  +7    -0    src/elisaapplication.cpp
M  +8    -0    src/elisaapplication.h
M  +12   -0    src/localFileConfiguration/elisaconfigurationdialog.cpp
M  +16   -0    src/localFileConfiguration/elisaconfigurationdialog.h
M  +11   -0    src/mediaplaylistproxymodel.cpp
M  +2    -0    src/mediaplaylistproxymodel.h
M  +15   -0    src/qml/DataListView.qml
M  +6    -1    src/qml/ListBrowserDelegate.qml
M  +36   -0    src/qml/SettingsForm.qml

https://invent.kde.org/multimedia/elisa/commit/bcc52c704cc929c35109f4bc80834e48607e2a6a

Unfortunately, the behavior introduced by this and the followup commit:
https://invent.kde.org/multimedia/elisa/-/commit/ebd0673ec741c4710c82a86cf1cd62c15bbfaf64
is really confusing:

In the track view, if I touch (on mobile) a song, I would expect it to play just that one song. (Whether it enqueues it or replaces the playlist with it is up for debate, and I agree it should be configurable. But said configurability is not actually implemented (hence me reopening this bug), because the option that was added by your commit was actually removed by the immediate followup commit, linked above.)

Unfortunately, what the touch does instead is that it replaces the playlist with the entire contents of the track view! If I have not done a search, this means it adds every single song in my collection to the playlist! Obviously, this is NOT what I want. (And it does not even jump to that song in the playlist, but just starts from the top, which is probably a bug, but it would not happen if it were not behaving that weirdly in the first place.) Even when I do a search, I am going to stop typing once I see the song I am looking for and do not want to enqueue any other songs that happen to match the substring I am searching for.

Enqueuing the whole album MIGHT make sense for the album view, but for the track view, the touch should really only add that one track.

The workaround is to use the … button and the enqueue option. But that popup is missing a replace / play now option, so if I want that, I have to first empty the playlist, then use "Add to queue", and then play. So I have to do 6 touches (open the playlist, empty it, close it, open the … menu, enqueue, play) instead of the 1 I am used to, or at least only 2 as I suggest (open the … menu, "Replace playlist and play now"). I hope you agree that this is a usability regression.

PS: Having accidentally wiped the playlist a few times (accidentally touching the song when I wanted to touch … and Add to queue), I actually think "Add to queue" should probably be the default action (as the safer, less destructive option) and my proposed "Replace playlist and play now" a menu action. But both of them should only operate on the individual song (at least in the Tracks view), not on the entire contents of the view.

Please don't re-open closed bug reports. If you think the change is disruptive, subimt a new bug report about that and mark it as related to this one using the "See also" field. Thanks.

Why should an issue not be reopened if it is not actually fixed? The issue says "The user should be able to define what double-clicking on a song does: play or enqueue?", but the user is not allowed to configure this now, it just changed from one hardcoded behavior to another.

Anyway, filed bug #479592 for my issue.