Bug 69052 - Playlist order is destroyed by column sort
Summary: Playlist order is destroyed by column sort
Status: RESOLVED INTENTIONAL
Alias: None
Product: juk
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Scott Wheeler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-26 10:43 UTC by Russell Mull
Modified: 2006-09-29 01:05 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Russell Mull 2003-11-26 10:43:45 UTC
Version:           1.96 (2.0 Beta 2) (using KDE KDE 3.1.93)
Installed from:    Unlisted Binary Package
OS:          Linux

When I hit a sort column in a playlist, I have no way to get back to what I started with.  This is a bug to me because it's very easy to forget about this fact and destroy all the hard work you've done making your latest mix cd. 

A possible solution: Have a "playlist position" column show up for playlists.  (but then what happens when you change the order and you're currently sorting by album?)
Comment 1 Scott Wheeler 2003-11-26 11:44:10 UTC
I think this is pretty clear -- sorting is just another way of reordering items in a list.  However once I get around to implementing undo (which is already reported) it might make sense to allow undoing of the sort order.  But of course if you want different sort orders you can either save it before reordering or use "Duplicate" to create an identical set of items and order them differently.
Comment 2 Russell Mull 2003-11-26 16:38:15 UTC
A playlist, to me, is an ordered set of songs.  While you're right, sorting is only another way of reordoring that set, the order of a playlist in particular cannot be recovered once that operation is done.  Sorting effectively destroys the order.  

Why is this a problem?  Because the list view that's used in juk is used to view data in different ways, not to change it.  It makes a lot of sense for applications in which the order is unimportant or where the order is captured in one of the columns.  KMail, for example, has a Date column which represents the primary order of messages.  A directory is an unordered set of files, so it makes sense for konqueror to arbitrarily manipulate file order when viewing a directory.  It makes sense when browsing songs in the "Collection List" in juk, since any relevant order information is usually captured in the "Track Number" field.  

I don't think undo functionality is appropriate in this case because the sort columns should not have "operation" semantics.  XMMS is a case where it does makes sense, since its sorting functionality is driven by a command from a menu. 

Try making a playlist that you intend to burn to cd - I think you'll see what I mean.

(More along the same lines: can a search playlist be reordered?  I think it shouldn't be, because it's dynamic subset of an already unordered set.  Whenever it changes, its unclear what to do with the order.) 
Comment 3 Scott 2006-09-29 01:05:57 UTC
I agree with the originator that this should be resolved. Why not have a column for the order that files were queued? That seems an appropriate solution that allows things to be easily resorted/reordered.