Re: search music fix

On Mon, 2003-10-06 at 09:32, Ed Sweetman wrote:
> Kristian Kvilekval wrote:
> > On Sun, 2003-10-05 at 23:56, Ed Sweetman wrote:
> > 
> > 
> >>This causes it to not add . and .., and it seems to scan through all of 
> >>my files and generate a database. But zinf continues to say i have no 
> >>database.  Also, why does zinf have two databases now for the same thing 
> >>and two sets of code for the same thing (sometimes three) ?  Was the 
> >>previous code not redundent and messy enough ? Or is it planned to gut 
> >>the old code when the new code has been in zinf for a while, which by 
> >>that time nobody remembers what code they needed to gut and where the 
> >>new code is just like half of the lines of code in zinf are attributed 
> >>to now.
> > 
> > 
> > The mdb code is integrated only with the musicbrowsermm code.
> Then why is it active with the non-mm ui
> 
> > Both are in heavy development right now.   
> I thought the mdb code was in development already for a year, recursing 
> through ".." and "." is a pretty basic bug in the search code.  I'd 
> figure what would be in actual development now that it's in cvs would be 
> the making it optional at build time.

The old lazydb was used only as inspiration for the new mdb code,
it's still getting filled out.  In fact, it needs to get broken
apart so that it can loaded as plugins.

> > The old music catalog is still used in parts of zinf
> Tell that to zinf. Both seem to be in use and it's getting itself 
> confused. i see one database being built (the new one) yet zinf bonking 
> out on building the old one (which is all the gtk+ ui of musicbrowser 
> seems to be able to access).
> > including the win32 interface.  
> 
> The code i'm talking about is not in win32 defines or win32 specific 
> source files so this is a non-issue.
> 
> > Eventually this should be build option,
> 
> I dont disagree with this in itself.  But i do disagree in the way it's 
> being integrated for a couple reasons.
> 
> 1. The searching and such things have nothing to do with the toolkit the 
> musicbrowser is rendered in.  They should not be binded together or you 
> just lose a lot of the functionality available in the code and you've 
> basically wasted a lot of your time writing the code since toolkits 
> change often, the code to search a fs doesn't have to. Reusability is 
> key.  All you have to do is spend 15 minutes browsing the source to zinf 
>   to know that people would rather copy and paste functions everywhere 
> they're needed instead of write a single function that can be called 
> when applicable.

They are not bound together.. in fact there is far less dependence
now and an even lighter binding is planned.. The browser will
communicate with player through URL  and lists of URLS only. 
Unfortunately there are some issues concerning keeping the players
playlist view and the browser playlist view consistent.  


> 2.  You unecessarily add dependencies to the musicbrowser.  The 
> musicbrowser code "/base/src" is  meant to be a backend. the new musicdb 
> code is supposed to replace this ( NOT THE GTK ui of the musicbrowser, 
> which the mm version replaces).  By binding the musicdb code to the mm 
> version of the musicbrowser you make it impossible to use the new 
> musicdb code and thus all it's added functionality without gtk--   This 
> is just insane.  I mean, i didn't spend the time to rewrite the 
> musicbrowser, but i know if i did I wouldn't cripple it by binding it to 
> the ui toolkit.

Umm.. I said the musicdb is integrated with musicbrowsermm, not bound
to.  Look at the code there.  It's not much..   Eventually they will be
completely decoupled.


-- 
email:[email protected] office:(805)893-4276 http://www.cs.ucsb.edu/~kris



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf