Implementing drag to reorder tracks in media clipboard (Issue 318)

[NatalieElizabeth]

Issue 318

Implemented drag-and-drop for reordering tracks in the media clipboard. Created some mouse event overrides to detect dragging behavior with a drag threshold of 5 pixels, and made some changes to the painting of the TrackAreaWidget to display and update a drop line. The appearance (color, thickness) of the drop line can be discussed before merging.

Files modified:
TrackAreaWidget.h

[cwitkowitz]

Great start! I found two small issues:

1. The tracks are still reordered (and the horizontal bar still shown) if drag/drop is performed outside of the track area (media clipboard)
2. When moving to a track underneath the current track (i.e., later in the order), the reordering seems to skip a track (resulting in one extra track in between the original and intended ordering)

[NatalieElizabeth]

Thank you for catching those issues!

The latest commit fixes the downward drag offset issue and ensures that a.) the indicator line won't be drawn if the drag is moved outside the widget, and that b.) the reordering won't occur if the mouse is released outside the widget. You can still start the drag in the widget, move outside the widget, and then move back inside and release the mouse button to reorder, as long as the release is within the bounds of the widget.

[cwitkowitz]

Looks good! Only thing I would say is to be wary of calling repaint() in mouseDrag, since this may invoke the function repeatedly over the course of the drag. Obviously, this is necessary to move the delimiter, but repaint() can sometimes be a bulky operation and could slow things down if called in a loop. With that being said, it doesn't seem to be a problem on my end.

[NatalieElizabeth]

You were right to warn against the repaint() calls. Once I implemented visual drag and drop, I had to reorganize some things to make the visual update more efficient.

The latest commit implements a visual drag and drop. I've created an overlay that spans the entire window and gets handed down to TrackAreaWidget.h, where nearly everything else is handled. Essentially, a snapshot of the dragged track is taken and a gap is created in the slot below the hovering cursor. The gap position updates as the cursor is moved, and the track moves as it should.

At present, I've made it so that the track can be "dragged" anywhere in the window, but it can only be dropped inside the TrackAreaWidget. I did this so that the dragged track wouldn't clip at the sides of the TrackAreaWidget, hence the window-wide overlay. It still clips at the edges of the application, which I'm not too sure how to feel about. I could do one of the following:
A.) Leave it as it is
B.) Attempt to make the drag screen-wide rather than window-wide (?)
C.) Constrain the drag to the y-axis only, so it can't be moved outside of the TrackAreaWidget and therefore can't clip at all.

I pushed this commit because the feature is now technically shippable, but I intend to make one more adjustment before I call it finished and request a review. I'm going to attempt to animate the gap (as opposed to every track, which would be difficult) to make the visual transition smoother. That being said, if there's any input or feedback on the current iteration, I can incorporate that into the next (and hopefully final) commit.