[kde-doc-english] [amarok] /: Make playlist-related actions consistent throughout Amarok code (behaviour change)
Myriam Schweingruber
myriam at kde.org
Sat Jun 15 12:56:54 UTC 2013
Hi all
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)
>
> 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:
> OnDoubleClickOnSelectedItems
> OnMiddleClickOnSelectedItems
> OnReturnPressedOnSelectedItems
> OnPlayMediaAction
> OnAppendToPlaylistAction
> OnReplacePlaylistAction
> OnQueueToPlaylistAction
>
> ...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.
>
> CHANGES:
> * 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 at kde.org
> CCMAIL: amarok-devel at kde.org
> BUG: 145468
> BUG: 145490
> BUG: 194549
> FIXED-IN: 2.8
> 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
>
> http://commits.kde.org/amarok/a43e7e6f5a14307f543e7807a8d2351af027635a
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.
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)
More information about the kde-doc-english
mailing list