Bug 145468 - double click on playlist -- should load it (regression)
Summary: double click on playlist -- should load it (regression)
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Amarok Developers
Depends on:
Reported: 2007-05-15 18:45 UTC by Maciej Pilichowski
Modified: 2013-06-27 18:35 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 2.8


Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Pilichowski 2007-05-15 18:45:46 UTC
Version:            (using KDE KDE 3.5.6)
Installed from:    SuSE RPMs

I am not sure, but I think it worked before correctly.

Currently amarok is not intuitive, because it uses different behaviour than other KDE applications.
Start amarok, start playing playlist, double click on any other playlist. It is appended to currently chosen, instead of being loaded. 
It would be acceptable if user would choose some kind of creating (composer) mode in Amarok. Append in normal mode should be done via drag&drop, double click is "activate" (open/execute/etc).

Please do not introduce amarok own standards, KDE experience should be consistent no matter what app is executed.
Comment 1 Mark Kretschmann 2007-05-15 18:58:33 UTC
It's not a bug, it's a feature. This change was intentional.
Comment 2 Maciej Pilichowski 2007-05-15 19:10:33 UTC
Mark, KDE usability hurts -- just think how KDE will look if every developer would introduce its own (better of course) standards. Krusader could introduce double click to copy files (because it is better) -- it leads to messy desktop and in practice downgrade the system (user has to learn every time what double LMB means).
Comment 3 Maciej Pilichowski 2007-05-15 19:12:43 UTC
PS. It is not even consistent in Amarok (as isolated island) -- on right pane double LMB means execute, on left pane double LMB means add. 
Comment 4 Matěj Laitl 2013-05-25 11:15:49 UTC
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)

This commits boasts a couple of changes, starting with the
uncontroversial ones:

 1. The Playlist::AddOptions enum is extended with extended with
"convenience consistency" aliases:

...and all callers of PlaylistController::insertOptioned() are modified
to use one of these values instead of the "low-level" flags like
DirectPlay that are actually tested for in the insertOptioned()
implementation. This serves that we remain consistent across Amarok
from now on.

 2. The actual "low-level" enum values have been changed and
insertOptioned() was updated accordingly:
    a) PrependToQueue, which implies Queue, was added.
    b) StartPlay (start playing unless something is already playing)
       was removed. No caller uses it anymore (see below) and this was
       convoluted anyway, IMO.
    c) DirectPlay now implies PrependToQueue. This may seem strange,
       but the rationale is following: when you directplay just one
       track (which is the case 90% of the time), it is played
       immediately, and this should apply even when you add more
       tracks. PrependToQueue makes this possible without hacks and is
       invisible in case of just one track, because it is immediately
       popped from the queue. Plus it has a positive side-effect of
       inserting the track at a meaningful place (affects what track is
       played next).
    d) LoadAndPlay and LoadAndPlayImmediatelly were removed, because
       they were replaces with consistency aliases.

 3. Thanks to 2b), 2c) and implementation changes, the actual action
    performed upon a certain trigger no longer depends on any state.
    The state of playlist search no longer affects whether a track will
    be played in case of DirectPlay.

 4. insertOptioned() was cleaned up and changed, for example it tries
    to choose the best place to insert tracks according to
    PrependToQueue or Queue.

 5. The convenience aliases were assigned as follows:

    OnDoubleClickOnSelectedItems = OnReturnPressedOnSelectedItems =
    = OnPlayMediaAction = DirectPlay.
    OnMiddleClickOnSelectedItems = OnAppendToPlaylistAction = Append (0).
    OnReplacePlaylistAction = Replace (no-brainer).
    OnQueueToPlaylistAction = Queue (no-brainer).

    These aren't of course set in stone, they were however chosen to be
    as much consistent with other KDE apps as possible.

Especially the "DirectPlay implies PrependToQueue" change is a bit
controversial, my opinion in that matter is anything but strong and I'm
open to any discussion. But perhaps try to use it for a couple of days
to get over the barrier of change.

 * Playlist-related actions were harmonized: double-clicking, pressing
   enter or using any "play media" action will prepend tracks to queue
   and immediately start playing; middle-clicking appends to playlist;
   append or replace actions will no longer start playback.

CCMAIL: amarok-promo@kde.org
CCMAIL: amarok-devel@kde.org
Related: bug 145490, bug 194549
GUI: Behavioural change in some places, to increase consistency. Please
check that the docs don't mention the old behaviour, see CHANGES.
DIGEST: Amarok harmonizes playlist-related actions (double-clicking,
pressing Enter, middle clicking...)

M  +4    -0    ChangeLog
M  +4    -5    playground/src/context/applets/coverbling/CoverBlingApplet.cpp
M  +1    -1    playground/src/context/applets/coverbling/CoverBlingApplet.h
M  +1    -1    playground/src/context/applets/covergrid/AlbumItem.cpp
M  +5    -8    src/App.cpp
M  +5    -5    src/MainWindow.cpp
M  +1    -1    src/amarokurls/BookmarkTreeView.cpp
M  +8    -11   src/browsers/CollectionTreeView.cpp
M  +1    -1    src/browsers/CollectionTreeView.h
M  +7    -7    src/browsers/filebrowser/FileView.cpp
M  +1    -1    src/browsers/playlistbrowser/DynamicView.cpp
M  +10   -12   src/browsers/playlistbrowser/PlaylistBrowserView.cpp
M  +3    -3    src/browsers/playlistbrowser/PlaylistBrowserView.h
M  +12   -6    src/context/applets/albums/AlbumsView.cpp
M  +2    -1    src/context/applets/albums/AlbumsView.h
M  +2    -2    src/context/applets/similarartists/ArtistWidget.cpp
M  +2    -1    src/dbus/mpris1/TrackListHandler.cpp
M  +1    -1    src/dbus/mpris2/MediaPlayer2Player.cpp
M  +63   -48   src/playlist/PlaylistController.cpp
M  +19   -7    src/playlist/PlaylistController.h
M  +0    -1    src/playlist/PlaylistModel.cpp
M  +12   -18   src/playlist/view/listview/InlineEditorWidget.cpp
M  +9    -9    src/playlist/view/listview/PrettyListView.cpp
M  +1    -1    src/playlistgenerator/Preset.cpp
M  +2    -2    src/scriptengine/AmarokPlaylistScript.cpp
M  +1    -1    src/services/amazon/AmazonStore.cpp
M  +1    -1    src/services/lastfm/LastFmService.cpp
M  +3    -3    src/services/lastfm/LastFmTreeView.cpp
M  +1    -1    src/services/lastfm/SimilarArtistsAction.cpp

Comment 5 Matěj Laitl 2013-06-27 18:35:27 UTC
Git commit 71a0e27a7aa1899f063affd4854abf650978887b by Matěj Laitl.
Committed on 27/06/2013 at 10:40.
Pushed by laitl into branch 'master'.

Finally harmonize the double-click and other playlist-related actions

 * Playlist-related actions were harmonized, double-clicking or pressing enter will
   append tracks to playlist, middle-clicking or using any "play media" action will
   prepend tracks to queue and immediately start playing; append or replace actions will
   no longer start playback.

Funnily enough, this is exactly what Myriam suggested from the start, but
wasn't understood by me, because her Amarok behaved differently than mine
(how so?) and we both referred to that behaviour.

The CHANGES above are current state vs. Amarok 2.7.1 and ignore any
intermediate steps.
Related: bug 145490, bug 194549
GUI: revisit playlist-related actions, the changes are more subtle now, see CHANGES
CCMAIL: amarok-devel@kde.org
CCMAIL: amarok-promo@kde.org

M  +4    -4    ChangeLog
M  +3    -3    src/playlist/PlaylistController.h