Ocarina no longer has a header file subdirectory so there is no reason
to have a libsaria subdirectory anymore. Putting header files directly
in the include/ directory is a bit simpler.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I initially made this class so that multiple front ends could be used at
once and all receive the same notifications. I see now that this was a
stupid idea, since I only need to keep one list of the library. My
notify() function does the same stuff without the need for a driver
list.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
- Delete the library file
- Remove tracks from each playlist
- Notify the renderer that tracks have been removed
- Notify library drivers that the path has been removed
- Remove the path from the list
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
- Change WriteTask() to take an extra void pointer argument
- Pass library path pointer through WriteTask
- Store tracks to file named after library id.
- Remove newline from tags
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I sort the subset of tracks to be added, and then use insertion sort to
add them to the playlist object.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
This gives the UI a chance to set the new path or new size. I also
updated Ocarina to show the library path size in its liststore row.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I was using the sid_t to lookups for tracks and library paths. I think
I can simplify things by storing pointers in the UI rather than using
id numbers. This will give me direct access to whatever it is I want to
manipulate.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I created a new "list_dir()" function to recursively list directory
contents. I plan on using this to find songs to add to the library, but
it could also be modified to read playlists and library paths in the
appdir.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
The UI calls the library::add_path() function to create a new
LibraryPath structure to be managed by the library.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
get_info() performed a loop over all library paths and over each track
in each path to find the requested sid_t. I now keep a map sid_t ->
Track * to make finding the track easier and faster.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I return the number of visible songs, so if the user has entered a
filter string then I return the size of the results set. If we're not
filtered then I return the size of the playlist.
This is an index of every substring in the (artist, album, title) tags
of the library. This should be easier to work with than regular
expression based filtering since I don't need to compare every key with
every search term.
Right now this will only be triggered when the library is loaded from
disk. Once I get farther I can easily create a function to index a
track as it is added to the library (so I won't need to reindex
everything during this case)
Lookup by id will be slighly slower, but now I will have one list for
each path that can be merged together and sorted to represent the
library. This sounds like a good tradeoff to me, especially since I can
store an iterator to the current track when deciding what to play next.
This will give me much faster access to song for the current track.
I was using a map, but the map required duplicating the library path
everywhere. Except for removing a path, I don't ever need to look up a
specific path by name, so why bother optimizing this case? Iterating
over a linked list should be more efficient (and easier to comprehend)
The source model class is used to more tightly control how songs are
inserted into the UI. I provide an insert() function that the library's
for_each() function can take advantage of. This allows me to directly
insert songs into the UI rather than having to use a static function as
the "middle man"
This function will generate a Track object based on the current file
stored by the audio. I then pass this object to to provided function so
the UI can be updated.
The code was a bit messy and didn't make use of namespaces very well.
By converting to a set of functions (instead of a class) I can use
each function as a function pointer if I want to. I am also able to
remove libsaria/library.cpp since this was just a set of wrapper
functions to the old static class functions.
Bryan Schumaker
Bryan Schumaker