Maybe I'm oversimplifying but isn't the way to do it to have a separate view, which can be a subclass of the trackview which just overrides the double click function to do something different? I mean you're right, it's not a track table view.
2008/11/18 Albert Santoni <[EMAIL PROTECTED]>: > On 17-Nov-08, at 12:30 PM, Adam Davison wrote: > >> My only comment is that I like being able to browse by double clicking >> on the right (main) pane as well. So we shouldn't you know, stop that >> from working :) >> >> Adam > > I like that too, but the fundamental problem with it is that directories > aren't tracks ==> they shouldn't be displayed in a "track table view" > widget. The widget should only provide a view onto tables of tracks. That's > one of the reasons why our old code imploded. :) > > (The double-click behaviour illustrates this problem. The double-click > behaviour is defined in the view widget, and what it does is ask the > TrackModel for song, then passes it to an active player. It doesn't care > what data model it has, as long as the data model implements the TrackModel > interface. I started writing a TrackModel/QDirModel-inherited class, but > then I realized that when you double-click on a directory, it'll try to load > it as a song. In order to override that behaviour so that it navigates to > the clicked directory, the _view widget_ code would have to turn into giant > block of if-statements, which subtly tells you that you're not using > model/view correctly. Extrapolate from there, toss in some bugs, and you'll > see how the code will end up crappy.) > > Albert > > > > > >> >> >> 2008/11/17 Albert Santoni <[EMAIL PROTECTED]>: >>> >>> On 16-Nov-08, at 2:03 AM, Adam Davison wrote: >>> >>>> It reassures me to know that in this new code we can has cheeseburger. >>>> >>> >>> Yes, but the question is: can we has playlists and browse mode? >>> >>> I need to take a break from the library stuff to think about how to >>> properly >>> reimplement these. Browse mode is definitely going to work a bit >>> differently, by nature of doing it the right way and not bastardizing the >>> track table again. It's going to end up something like there's an >>> expandable >>> directory tree as one of the items in the pane on the left, and when you >>> select a directory that's got MP3s/OGGs/music in it, they will appear in >>> the >>> track table to the right. The key point here being that the track table >>> will >>> only display _tracks_, not directories, etc. >>> >>> There will probably end up being a similar expandable item for playlists, >>> so >>> the pane on the left might end up looking like: >>> >>> Library >>> +Playlists >>> - ghetto beats >>> - my secret britney spears collection >>> - etc >>> +Browse >>> + C: >>> + Program Files >>> + Other Folders >>> + Blah >>> + D: >>> >>> If anyone sees any obvious (or not so obvious) problems with this, please >>> let me know. Also, feel free to share any suggestions for the new >>> library. >>> :) >>> >>> Thanks, >>> Albert >>> >>> >>> >>> >>> >>> >>> >>>> 2008/11/16 Garth Dahlstrom <[EMAIL PROTECTED]>: >>>>> >>>>> Very cool, reminds me of 1.4.x days... :) >>>>> >>>>> In the current implementation I was looking to see if there was a way >>>>> to reset the model on the third QHeaderView header click(ascending, >>>>> decending, unsorted), never found one, not sure if that still applies >>>>> coming from the SQL model though. I'll have to remember look at that >>>>> again one of these days. >>>>> >>>>> If the "smart" sorting of null/crap doesn't work in the new setup, let >>>>> me know and I'll try to port it to SQL. >>>>> >>>>> -G >>>>> >>>>> >>>>> >>>>> >>>>> On 11/15/08, Albert Santoni <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> Just another quick update. Started playing around with QSplitter to >>>>>> add a view of the "track sources" (eg. library, playlists, blah) to >>>>>> the UI: >>>>>> >>>>>> http://picsharp.com/images/0b3gt1qam2vukhzf3fo.png >>>>>> >>>>>> I also discovered a few days ago that the QHeaderView class, which >>>>>> corresponds to the column headers in our new track table has these >>>>>> "saveState()" and "restoreState()" functions, which allow us to >>>>>> serialize it's column positions/sizes and sorting to a QByteArray. >>>>>> That means it'll hopefully be trivial for me to make all that stuff >>>>>> auto-save. I think that's been a feature request for ages. :) >>>>>> >>>>>> Albert >>>>>> >>>>>> On 13-Nov-08, at 4:14 AM, Ben Wheeler wrote: >>>>>> >>>>>>> On Mon, Nov 10, 2008 at 11:28:10PM -0800, Albert Santoni wrote: >>>>>>>> >>>>>>>> I've been plugging away at the library rewrite for a while now, and >>>>>>>> I've >>>>>>>> got parts of the basic library functionality reimplemented. >>>>>>> >>>>>>> I'm in awe of the amount of hard and good work you put into the >>>>>>> "un-sexy" jobs that no-one else wants to do! Kudos, kudos. >>>>>>> >>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> I think that's fair enough. There comes a point where time spent >>>>>>> fathoming and fixing bugs becomes wasteful (and even less "sexy" >>>>>>> than fixing the core of the problem by redeveloping the >>>>>>> architecture). >>>>>>> One of the rules of open source innit: be prepared to "throw one >>>>>>> away". >>>>>>> >>>>>>> Anyway, just wanted to big you up for the work. :) >>>>>>> >>>>>>> One of these days I'll actually get on with the very minor >>>>>>> task of hooking up the DJM-800 for MIDI control... but, happy to say, >>>>>>> I have very little spare time at the moment because I'm too busy >>>>>>> DJing :) >>>>>>> >>>>>>> Ben >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> 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 >>>>>> >>>>> >>>>> -- >>>>> Sent from Gmail for mobile | mobile.google.com >>>>> >>>>> __ >>>>> --- == __/ t.O ==-- >>>>> http://stacktrace.org/ >>>>> >>>>> >>>>> ------------------------------------------------------------------------- >>>>> 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 >>>>> >>> >>> > > ------------------------------------------------------------------------- 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
