I want to have all of Ocarina documented in the code, rather than in a
difficult-to-maintain DESIGN file. Let's get going on that!
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>
Ocarina was preserving the results set even if there were 0 search
results for the entire search string. So a search for "walllllll" would
still return results for "wall".
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>
The user could search for a term that isn't stored in the filter index.
This is represented through a NULL pointer returned from the
Index.find() function. Let's check this pointer before attempting to
dereference it ...
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>
Initialize everything from the core/ layer, that way lib/ doesn't need
to know the correct order.
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>
Whenever a Track is destructed, library->count is decremented. This
means that even if tagging fails we need to increment library->count to
keep this value consistent.
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>
Without this check we could end up creating a Track for a .ini file or
some other non-audio file.
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>
I now mimic the effects of the "changed" callback with inheritance.
This makes for a cleaner implementation.
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>
I plan to introduce a new lib/ that sits between the gui and the backend
files (similar to how glibc sits between the kernel and userspace).
This gets the rename out of the way before I change my mind again.
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>