Re: search music fix

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 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.

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.






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