Playlist improvements

[Arkadiusz Guzinski]

Hi!

My original intention was to just to make the playlist fully controllable by keyboard, but I noticed a few other things that could be improved there. It might make sense to do all (or at least most) in one go, but before submitting this as a Draft MR and start coding I'd like some feedback on the plan and whether it even makes sense to put this much into one MR.


## Draft: Improve Playlist - mostly for keyboard control / desktop

### general features to add:
* Multi-Selection support
* Highlight selection
* Click album header to select whole album(separate MR?)
* Optional (maybe better as separate MR): set a threshold for grouping by album header. E.g. only group when at least 4 songs or whole album would be in group.

---

### non-keyboard related improvements:
Apps on mobile devices do selection and movement of list items in a different way than desktop applications. This is because different input paradigms are more suited some input devices than others.
Elisa's playlist currently works reasonably well with pen and touch input - but is not ideal when using a mouse.

I propose 2 modes that can be switched between depending on currently used input device (or user setting).

**Touch mode** 

As is now, with the following addition (not sure I'm even going to implement all of this):
* Long press on item will start selection mode, meaning:
  * Selection can be turned on/off for each song with a single tap. Possible signify by checkbox?
  * A designated area (perhaps where the songs length is displayed) will be highlighted. Any drag starting in this area will select multiple songs.
  * Open question: where to put the action icons (e.g. Delete) for the selection?

Note on the ButtonRow: I tried Elisa on a Surface laptop and noticed the following: when swiping to scroll with the Pen, the active item is updated to be whatever is under the last registered pen position. The ButtonRow is updated accordingly.. many times.. it might look better if it is hidden until the list stops scrolling.
When using fingers, the ButtonRow is rather useless, as there is no hover to tell which Item is intended to be the current one.
I probably won't do anything about this in this MR though.

**Mouse mode**

* RMB opens context menu. 
  * Maybe hide menu button?
* Remove drag handler icon und use any part of the item without a different function to start drag.
* There should be some area where starting a drag will start multi-selection. (song length? space where drag handler icon was?).
* Optional: pressing LMB on the above area and waiting for some time before dragging will start multi-selection without removing previous selection.

---

### keyboard related improvements

**Implement (configurable!) shortcuts for:**
* Move up/down (already there, but not configurable and current song not clearly visible)
* Move up / down by page
* Move to currently playing
* Multi-select shortcuts. Dolphin is a good example on how to do it (QTreeView default behaviour?).
* Select current album
* Move selection (maybe defaults to alt + up/down keys)
  * Optional: if more than X songs are moved, collapse them until move modifier is released. Reason: songs above and below selection should always be visible while moving
* Remove from playlist
* Undo last action (which might need its own MR to implement undo of move/remove)

---

Some questions: 
* An Item can be both active and selected, which makes 4 individual visual state combinations (more if we don't ignore mouse hover). The way dolphin does it (color for selection; underline for active) would be one possibility. Is there a better way?
* As KF6 is coming up...
  * are there any upcoming changes to Kirigami that I should be aware of?
  * is there a guide on how to set up my dev environment for KF6 while I keep using KF5 (using KDE neon)?
* The current MediaPlayListView uses a ListView to display the songs. I would have expected that ListView already provides functionality to make multi-selection easy to implement (well.. at least QListView does, if I remember correctly). Why has it not been already done? Was it just a lack of time or were there some special difficulties I should be aware of?

Best regards,
Arek