Hi,
I got everything working properly now that I moved the connecting of the
m_autoExpandTimer timeout signal to the constructor (don't know why I didn't
do this in the first place). I made a personal bzr branch to launchpad (
https://code.launchpad.net/~miko-kiiski/+junk/mixxx-development), but was
not able to find the "Purpose Merge" -link/button in launchpad. Could
someone give me a hint how I could get the merge request sent to
mixxxdevelopers?
When testing the changes I made, I noticed that the table views in the
library won't update until the sorting is changed after an item is dropped
into them. I tested this also with trunk, so it is not an issue that is
resulting from my changes. Anyone else having this issue? I'm testing on
Kubuntu 9.10 with KDE 4.3.
I also checked the smart pointer stuff Albert mentioned and will check the
TrackInfoObjects today. Does anyone have insights or suggestions on which
smart pointer class we should use? I'm not 100% sure I got everything in the
smart pointer article.
-Miko
2010/3/20 Albert Santoni <[email protected]>
> 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
