[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 84047] Multiple Collections with a Drop-down Box
From:       Michael Reiher <michael.reiher () gmx ! de>
Date:       2005-05-10 22:25:12
Message-ID: 20050510222512.14666.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=84047         




------- Additional Comments From michael.reiher gmx de  2005-05-11 00:25 -------
I just wanted to add a wish for a multiple collections feature. It's already there, \
so modified what I already wrote and add it here... got a bit lengthy though..

The backround logic:
My first thought was to have several collections based on directories. Simply because \
I would/could organize my files that way. However my second thought resulted in \
something like the already described labels. As that would be much more flexible and \
as in reality there is no simple one to one relationship between collections(labels) \
and directories(directory here meaning some kind of top level dir with possibly other \
dirs below). In fact there can be any combination. These are:

Case 1) Multiple collections in one dir: I want to group my own songs into different \
categories. However I don't need to and don't want to move them around. I'm fine with \
them staying where they are. Or my girlfried, she has all her music thrown in that \
one big folder. She is never going to sort that random heap of files into \
directories;) She might however move them around in the collection tree. 

Case 2) Multiple dirs for one collection: For instance I have two dirs, one where I \
put all the ripped copies of CDs I own in and another one with files I got from \
friends or so. But thats just an organizational distinction (e.g. I don't need to \
back up the copies from my CDs) and has nothing to do with the music. This is \
actually what you can do at the moment, just that there can only be one collection.

Case 3) One label for one collection: You take you laptop somewhere, mount some \
network drive with the music. 

For cases 1 and 2) the solution is to simply throw everything into one collection and \
let the user move it around as he/she likes. However that's not going to work for \
case 3) You certainly don't want to sort hundreds or thousand of songs or albums \
manually. But that can be solved at GUI level so that amarok does that for you, see \
below.

The user interface:
I don't like the idea of a drop down list for selecting collections. That would make \
song management much less intuitive. Or an example from personal experience: At our \
next party, from those running the party, I would put everyones music into an own \
collection, because we listen to pretty different kinds of music. On the party people \
can modify the playlist as they like. Now I guess the average Windows-only-if-at-all \
party guest, who has never seen amarok, will never ever get the clue to use the \
dropdown list to get the music from another person.

So instead add a new level at the top of the collection tree, being the name of the \
collection. Maybe it should already be there by default, called something like "My \
Collection", to hint the user: there can be more. Then a button or RMB entry "Add \
Collection". That would open a dialog asking for a name. And optionally for a \
directory (Case 3). But that would only help sorting all the songs in there into the \
new collection, and new ones appearing later to be added there. Other than that it \
would be treated like any other dir and you can move songs to different collections. \
Then there could also be a checkbox to make that collection kinda persistent (comment \
#5). 

Hmm, on further thought that persistence should be bound _only_ to directories, not \
collections! Because if you take an album from the "network collection" and put it \
into a different one, you'll expect it to be still there when you reconnect to that \
network. Or you might add such a temporarily available dir to an existing collection \
and expect the songs to be kept if the dir disappears. In general amarok should mark \
non accessable songs from those temporary dirs if the dir(or rather it's content) \
disappears, and reshow and update them if the dir reappears. But I'm leaving the \
topic...


[prev in list] [next in list] [prev in thread] [next in thread]