On Wed, Jun 26, 2013 at 9:34 PM, Matěj Laitl <ma...@laitl.cz> wrote: > On 16. 6. 2013 Myriam Schweingruber wrote: >> > 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.
That was not the "old" behavior, the old behavior was double-click appends to playlist. There never was an immediate start of a track playing on double-click. So -1 on that, as it was never working like that. >> > b) just append to playlist. +1 >> > c) insert after currently playing, play the track(s) immediately. The new >> > and controversial behaviour. -2, it really is annoying on more than one point, not only does it add the track, but it adds it after the current track and starts playing, and it even adds queue markers, very disturbing. This makes an easy append to playlist action impossible, I have been swearing a hundred times abut this behavior since the change. >> > 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]. >> >> How about not modifying the double-click, which people are used to to >> add tracks at the bottom without starting to play, and use the middle >> click for the new feature? > > So what is your preference what should happen on double-click? a), b) or c), > or do you suggest some d)? How/if ever should we take KDE's settings (single > vs. double click) into account? Leave the double-click as it was, at least it doesn't disturb the way hundreds of users are used to. A change like you did is not a small change, but a complete change of the way Amarok works. Such a drastic chance is certain to bring us a shitstorm from the users. Since the modification of the layout in Amarok 2.0 hundreds of users have been getting used to the middle-click to append to the playlist, changing this now will certainly not go without heavy criticism. If you absolutely want a "queue and play" action, use a new one, and AFAIK the middle click was not sued before, so use that, but don't change the established actions. And just for the record and to show you how disruptive your change is: Double click in the collection (browser since 2.x) appends to playlist since version 1.0 beta, read the ChangeLog. Regards, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) _______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel