[amarok] /: Make playlist-related actions consistent throughout Amarok code (behaviour change)

[Matěj Laitl]

On 15. 6. 2013 Myriam Schweingruber wrote:
> On Sat, May 25, 2013 at 1:15 PM, Matěj Laitl <matej at laitl.cz> wrote:
> > Git commit a43e7e6f5a14307f543e7807a8d2351af027635a by Matěj Laitl.
> > Committed on 23/05/2013 at 18:54.
> > Pushed by laitl into branch 'master'.
> > 
> > Make playlist-related actions consistent throughout Amarok code (behaviour
> > change)
> 
> Sorry, but I can't agree with that, this behavior change is
> counterproductive as it totally disrupts how Amarok has always worked,
> and causes some serious usability issues:
> 
> * When using a double click I want a track to be added to the
> playlists, but it should not start automatically, as this causes every
> track I add to start automatically. This makes "creating" playlists a
> real problem.
> 
> * The track is not added at the bottom of the playlist but after the
> last played one, which is not desired.
> 
> * Middle click to add to playlist might work on some mouses, but I
> just can't use that on my mouse which has a scroll pad, and our future
> Mac users will get in even worse trouble than I am.
> 
> * We can't just throw over board the workflow, and an established way
> to use Amarok since the 1.x times, this will make us loose users,
> something we really don't want to.
> 
> So please, let's discuss what makes sense in that commit and what is
> "too much" and return Amarok to a normal behavior. Right now I just
> can't use Amarok anymore and asking the users to totally modify a
> behavior is a NO-GO for me.

That's fine, let's discuss what action should a double click (or, perhaps even 
a single click if user hasn't explicitly configured KDE to use double-clicks) 
cause. Fortunately the patch makes it easy to change this, just edit the 
OnDoubleClickOnSelectedItems value in PlaylistController.h if you want to test 
different behaviour locally.

Options for the "activate" (double or single click, per configuration, if we so 
choose) action; feel free to suggest more:

a) append track to playlist and start playing perhaps a different (depends on 
other factors) track in the playlist, if not already playing. The old 
behaviour.

b) just append to playlist.

c) insert after currently playing, play the track(s) immediately. The new and 
controversial behaviour.


My personal preference:
+1 for c). rationale: double-click then behaves the same in playlist and in 
collection, some may fine it more consistent with other KDE apps like Dolphin. 
At the same time I ack this may be too disruptive change and the queue usage 
is weird.

+0,75 for b).

-1 for a). Rationale: the "start playing something arbitrary when not already 
playing" aspect is something that really bugs me. We've had at least 3 bug 
reports (mentioned in commit above) thinking this was a bug, not something 
intentional, which means I'm not alone. I think that an action shouldn't 
depend on current state (whether playing, queue state, playback mode) that 
much.


Perhaps we could ditch all the special double-click handling (i.e. revert to 
"activate" in Qt's sense, which is single or double click depending on user 
configuration), ditch all the special "click even on text, not just arrow, also 
expands" handling and go for b) then? If we agree on this, I'm volunteering to 
implement this (requires more than just changes to the enum above), 
unfortunately not during the next week [wait for my next mail].

	Matěj