Hi Miko, On Fri, 2010-03-19 at 17:22 +0200, Miko Kiiski wrote: > Hi! > > > I've been working lately a bit with enabling the auto expand > functionality in the WLibrarySidebar class. What I've tried to do is > to make the features (playlists, crates) in the list expand when an > item is dragged over them. I noticed that QTreeView already kind of > has this functionality and it should work by just setting the > autoExpandDelay to a positive value, but for some reason I could not > get this working with the side bar (made even a test application and > noticed that it might be difficult to get the auto expand to work when > dragging content from outside the application). Thus I created an > implementation of my own. I branched the trunk and made the following > modifications: http://pastebin.com/7H93ZL2W (bzr diff output). The > problem with this is that for some reason I don't get only one, but > six, timeout events from the timer (or atleast the > WLibrarySidebar::toggleExpansion gets called six times). Does anyone > have any clue what could be causing this? I think that this kind of > functionality would be really nice in the library.
I looked at your diff and I don't immediately see the problem, though your diff isn't actually against trunk. Did you commit and then diff against that? I don't see any references to "expand" in library.cpp in trunk.... I think the problem might something along the lines of bindWidget(..) or another function is getting called 6 times (once for each library sidebar model), and that's why you're seeing 6 messages. If you can get my a full diff against trunk, I might be able to poke at it if you can't figure it out. > > > Also I currently have time to work kind of full time on the project, > so I'd appreciate very much if someone could point me to a task and > briefly tell what should be done about it, so that I don't have to use > hours to get an understanding of what is wrong (if no-one knows what's > wrong, then I'll of course try to figure the issue out myself). It really depends on what you want to hack on. :) Right now we're trying to wrap up 1.8, and that mostly entails us finishing up some odds and ends in various branches so we can release another beta. This list of "very important tasks for beta2" is basically still up-to-date: http://mixxx.org/wiki/doku.php/1.8.0_to_do_list I think at this point we've probably deferred all of the stuff that we didn't get done for beta1 to a later release (1.9 or 1.8.x). One remaining task is to use auto-pointers for places where we get TrackInfoObjects and do stuff with them. The badly-named "TrackInfoObject" class just contains song metadata. We use these objects in several places, but figuring out when the pointers are safe to delete has become VERY difficult due to the amount of multithreading that can be going on. Both myself and Adam have tried various approaches to keeping track of when they're safe to delete without resorting to auto-pointers, but we both ended up giving up after realizing how complex the system is. That said, it's probably not very difficult to sit down and rework the few bits of code that we have to use auto-pointers. This is really important because if we do it right, it'll help prevent memory leaks and double-frees, which lead to crashes. If you want to work on this, it would be a huge help! The easiest place to start is in player.cpp and analyserqueue.cpp. (They're tied together via slots/signals in mixxx.cpp). When a new track is loaded into a player, Player emits a signal that tells AnalyserQueue to start doing BPM detection and other analysis on that track. Player passes a TrackInfoObject pointer to AnalyserQueue through that signal. The problem is that when a track is unloaded from a Player, we don't know whether the TrackInfoObject pointer is safe to delete or not because the AnalyserQueue might still be processing it. If both Player and AnalyserQueue soft-deleted an auto-pointer instead, it would solve this problem in a simple way. Qt provides lots of auto-pointer classes, but I've never sat down and figured out which one to use. Give this blog article a read and pick whichever one you think is most appropriate: http://labs.trolltech.com/blogs/2009/08/25/count-with-me-how-many-smart-pointer-classes-does-qt-have/ So if you're interested in hacking on this (it's not a lot work), send us a patch or push a branch to trunk when you've got something to show. It'd be a big help because it's something that would be nice for 1.8.0 Beta2, but we absolutely need for 1.8.0 final, and everyone else has their hands full at the moment. :) Thanks, and feel free to ask mixxx-devel or email me off-list if you get stuck! Albert ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
