[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]