relative paths can't be trusted once the program has been installed. To
get around this, I assume that the install directory has been configured
correctly and then point to images located in the subdirectory next to
the executable.
Random hasn't been implemented in libsaria yet, but I can still create
the button to test preferences. The random button should set itself to
the value store in the preferences file.
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 need to store the inode somewhere if I want to use a linked list to
store LibraryPath data. I currently have a map <ino_t, TrackTag>, so
the obvious choice is to store the inode in the TrackTag structure.
This function is used to access how far into the song the current audio
position is. The value is returned as a percentage of the total length
for easy use by the UI.
I always want to find tags if it's possible. Since I already have a way
to find the tags, it's fairly simple to tag a random file and pass the
result back to the UI.
Namespaces make code easier to follow, and remove the need to mangle the
beginning of function names by using ocarina_*() or libsaria_*(). In
other words: "namespaces are one honking good idea. Let's have more of
them!"
The SourceModel declares an insert() function that is called when
filling the list. I have defined this function in a way that the list
will be filled in through repeated calls to insert()
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.
It really should go into the include directory. I don't want to use
relative paths to include header files in a subdirectory... I don't know
why I even did it in the first place!
This cleans up the idle task code a lot, and reduces the size of
ocarina.bin to less than 1MB (with full debugging). It probably won't
stay there long...
I combined reference counting with the get_footer() function to make
using it easier (no manual reference counting). put_footer() will
deallocate the widget if the reference count is 0 (this is already done
by the g_object_unref() function) so it should work in a sane way.
Calling the remove() function will destroy the footer if it has no other
references. To prevent this, I need to call g_object_ref() add a
reference to the widget.
If the user no longer wishes to track a certain path, they can remove it
from the library. Note: it is unsafe to remove a path from the library
while that path is being scanned. This could potentially lead to a
segmentation fault.
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