Hi guys, I've been plugging away at the library rewrite for a while now, and I've got parts of the basic library functionality reimplemented. Things have gone mostly according to the plan which I outlined earlier, which is nice for a change. :)
What I've done is rewritten the library to use model/view and object-oriented design properly. Specifically, I've: - Removed the pseudo-facade "Track" class. Gone forever. - Implemented a new "Player" class that represents (gasp) the backend for one of the players in Mixxx's UI. - Rewritten WTrackTableView to talk to a new LibraryTableModel class. - LibraryTableModel wraps a rewritten TrackCollection, which talks to the database. TrackCollection probably needs to be renamed TrackDatabase when I'm done. - Reorganized and decoupled tons of code inside Mixxx to make this all work. Some of the architectural issues I need to deal with soon are: - Deal with memory management of TrackInfoObjects properly. Before, we had a giant QList of all the TrackInfoObjects present all the time. Now, a TrackInfoObject gets created only when it is retrieved from the database and loaded into a Player. When a Player unloads the track, the memory _should_ be freed, but this is a problem because eg. the TrackInfoObject pointer might still be sitting in the BPM detection queue. One solution to this might be using auto-pointers (reference counting), but this is a bit handy wavy and I'm not convinced this is the best solution. General related question: If a track is unloaded from a player, why do you want to be running BPM detection on it? I think you want to be running BPM detection on whatever is loaded next, and get rid of the queue behaviour. With Adam's new EngineAnalyzer stuff, I think you would just cancel all the analysis that's going on when a track is unloaded, which is probably better for the end user experience. Back to architectural issues: - Something that I'm trying VERY hard to do is keep the Player class as dumb as possible. That is, I don't want the Player class to have to know about TrackCollection. All I want the code to do is pass Player a TrackInfoObject and have it do its thing. It'll be super crappy for modularity if we couple Player with the TrackCollection, because then I can see it starting to look like the Track class again in a year (read: disaster). :) Another problem with our old library is that we were bastardizing a "track table view" widget to view more than just "track tables". I hacked it to show the "list of playlists", which was bad, bad, bad. That's not how model/view is supposed to work, and I think I'm guilty of accelerating the old library code's spaghettification. Anyways, the end result here is that the list of playlists MUST be displayed in a new widget, so it looks like we're going back to a two-pane library again. I'll make it collapsible or something at least though. My final thought is that the new library is a double-edged sword. I've been motivated to rewrite the code because of the sheer number of library related bugs that have come into the tracker after 1.6.0, most of which are getting increasingly hard to fix because of architectural issues with the old code. The problem is that now I'm not going to fix any of those old bugs in trunk, instead I'm devoting that time to the new code. The new library code definitely won't be ready for 1.6.2, so the library bugs in 1.6.1 will remain. Just another random update email, mostly me rambling out loud about design issues. I'm sure by now most of you have come to expect nothing more from me. :) Thanks, Albert ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
