On Thu, Oct 8, 2009 at 8:12 AM, Matti <[email protected]> wrote: > > Don't you think it would easier if I modify the patches for the new > code than you modify my patches for the new code? I'll need to get > familiar with new code anyway..
Yes, probably... :) Most of these modifications are worth discussing though first. For example, I'm not quite sure that all the extra play queue actions are useful, they might just be adding clutter. > >> We'd love more help with ongoing tasks, and I think many of them are >> aligned with your personal goals that we can see from your patches. >> I'd invite you to take a look at the minutes and slides from our most >> recent developer meeting, available here: >> >> http://www.mixxx.org/wiki/doku.php/9_20_2009_developer_meeting_minutes >> >> The slides and notes outline our current development status. You might >> also wish to look at the slides and notes from the meeting before >> that, to help you get a sense of our development pace and direction: >> http://www.mixxx.org/wiki/doku.php/5_17_2009_developer_meeting_minutes >> >> To give you some very quick, but honest feedback on your patches, some >> of these we're going to be able to use, but others are going to be >> more challenging. Most of the EngineBuffer code has been given a >> rewrite by Russell (RJ) Ryan in the feature_looping branch, and that >> branch is targeted to be merged into trunk (1.8) as soon as some >> remaining kinks are worked out. That means I'm not sure what to do >> your gapless code. Also, I completely obliterated track.cpp in our >> features_sqlite branch, and replaced it with a more straight forward >> Player class and separate library classes. At the very least, we'll >> definitely study what you did in your patch and probably end up >> applying the same technique to our newer set of code. > > By the way what is the future of sqlite(old > track.cpp)-wtracktablemodel-wtracktableview? For my opinion is that it > has quite much hardcoded HACKs in it. For my opinion is that a lot > better way to do this would be to have all things user controls in > tableview or in some helper class. Then all displayapple data would be > in tablemodels. Table models then set their display options for > tableview to display them correctly and tableview doesn't have to treat > different models differently! In other words tablemodel is a superclass > with virtual functions and then playlistlistmodel and all other models > would inherit the superclass. Also the models should own their lists and > all other classes would control the lists (like the library) via the > model! That is important because QT's model will get mixed up if you > modify the list within. > > This is huge change and would require a lot of work but it will make the > view a lot more portable and flexible. Well, track.cpp no longer exists in the SQLite branch. All of the new library code is in the "src/library/" directory in the branch, with the exception of src/wtracktableview.cpp. We've tried hard to remove all of the hacks - all of the if (mode == browse) style hacks are gone from the view code, and we've moved a lot of behavioural logic down into the data model classes. We've also abstracted the concept of a track source much better, and you can see how we've taken advantage of that with our example Rhythmbox track source. In other words, we pretty much agree with your criticisms of the old design and have tried to solve these problems in the new code. :) Let me know if you have any other questions about the library, please don't hesitate to get in touch. We're currently trying to finish up the following library features for 1.8: * track db -- mostly done * searching -- needs to be implemented in an asynchronous way * browse -- RJ almost has this done * playlists -- the branch has this like 75% done * play queue -- easy to code after playlist support is done * working rescan -- we have a reasonably smart algorithm designed for this, but no code at all. We need someone to work on it, so if you're interested, I can explain how we think this should work. * tagging -- should also be fairly straightforward once playlists are done * external sources -- we have some of these done, but we're still working out some design kinks Please let us know if you're interested in hacking on any of these things so that we can guide you better. Thanks! Albert ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
