Design: Rethink groups and add in future ideas

I renamed "tags" to "groups" to avoid confusion with ID3 tags.  I also
thought out a better plan for eventually implementing user defined tags
so that I can build up to them with testing along the way.  With any
luck, I won't overwhelm myself with features =).

Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>

design.txt

@@ -17,9 +17,11 @@ Files:
 		design.txt
 	ocarina/gui/
 	ocarina/include/
+		group.h
 		library.h
 		playlist.h
 	ocarina/lib/
+		group.cpp
 		library.cpp
 		playlist.cpp
 	ocarina/tests/
@@ -65,15 +67,21 @@ Internal:
 	};
 	vector<Artist>
 
+	struct Genre {
+		unsigned int id;
+		string name;
+	};
+	vector<Genre>
+
 struct Track {
 	unsigned int id;
 	unsigned int artist_id;
 	unsigned int album_id;
+	unsigned int genre_id;
 	bool valid;
 
 	string filepath;
 	string title;
-	string genre;
 	string length_str;
 	short track;
 	short last_year;
@@ -139,18 +147,71 @@ Playlist: (lib/playlist.cpp)
 
 
 
-Tags:
-	Tags will be a new feature in Ocarina 6 and will be a more generic way
-	of implementing a banned-songs playlist.  Users will be able to create
-	new tags on the fly and add songs to and from them.  I can also use
-	an SQLite trigger to manage automatic tags.
+Groups: (lib/group.cpp)
+	Groups are going to be a new feature in Ocarina 6 and can compare
+	directly to Gmail-style labels.  Ocarina 6 will create dynamic groups
+	that cannot be deleted by the user based on library status.
+
+	Default groups:
+		All music
+			All tracks are added to this group
+		Library
+		Banned Songs
+			These groups are mutually exclusive.  A track is either
+			in the Library or the Banned Songs group
+		Unplayed tracks
+			Tracks with a play count of 0
 
-	The following tags will be created by default and will not be
-	deletable by the user: Artist, Album, Unplayed Songs, Genre
 
 - API
-	new_tag(name);
-	del_tag(name);
-	tag_song(name, songid);
-	untag_song(name, songid);
-	set_tag_visible(name, visible);
+	list_groups();
+		Return a list of group names
+	group_get_tracks(name):
+		Return a list of tracks that are in group "name"
+
+	Track.add_to_group(name);
+		Add a track to a group
+	Track.rm_from_group(name);
+		Remove a track from a group
+
+- Design TODO									<<<<<
+	- I need a way to loop over each track in the library to create
+	  dynamic groups.  Whole library iterator?
+	- A "Track" class with functions for accessing tags and with access
+	  to groups.  Perhaps make "Track" its own file, outside of the
+	  library and group code?
+
+
+
+Future work:
+	I want to set reasonable expectations for Ocarina 6 so that I don't
+	have to spend a large amount of time coding before releasing something
+	to the wild.  This section will be a list of features that I want, but
+	should be deferred to a future release so basic support can be coded.
+
+	Hint:  If feature B depends on A, implement A in 6.x and B in 6.x+1
+
+	- Categories: (6.1)
+		Use these to make "groups of groups" for better organization.
+		Different categories can include Album, Artist and Genere
+		dynamic groups in addition to user created groups (see below)
+
+		The Artist, Album and Genre "tables" can be used to populate
+		these categories.
+
+	- User created song groups: (6.2)
+		Basic add and remove features can be implemented using the
+		Library and Banned Songs groups.  This will give me a chance
+		to test saving groups on a small scale before letting users
+		create anything they want.
+
+	- Save a user's playlist as a group: (6.2)
+
+	- Library defragment: (6.1)
+		Ocarina 6.0 will leave holes in the library when tracks are
+		deleted, potentially leading to fragmentation and larger-than-
+		needed file sizes.  A "defragment" utility can be created to
+		clean up unused slots.
+
+		To help with fixing groups, a mapping of (old values) ->
+		(new values) should be kept.