I switched over to using pango <span> tags to set font properties to
make the text larger. I decided that the title will be bigger than
artist and album, so I can't have one generic function for setting the
label properties. Instead, I divided it up into one function for each
label.
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"
I want controls to be on the same level as the artist / album / title
labels. This will be more compact, and it won't waste a lot of empty
space above the labels and next to the controls.
This is just an initial implementation, so it's not very good right now.
It does give all the information, though. That's a plus. I also set
the artist / album / playlist whenever a SONG_LOADED callback is given.
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.
Bryan Schumaker
Bryan Schumaker