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