Clipboard problems, part deux

I think I got it figured out. First of all, let's simplify audio/video clipboard pasting. Since tracks can only be either video or audio, each track needs to have a video-type flag telling which kind of track it is. This way it won't accept clips of different kinds. Ordering of tracks will be handled by the UI, so it doesn't matter if audio and video tracks are mixed, audio track will always appear at the bottom and video tracks at the top. However, for pasting purposes, having only the track's type is sufficient.

Declaring one clipboard type for single clips is annoying. Instead, let's add a function that detects whether a sequence has only a single clip. Or even better, just add a friggin' flag. This is OOP, we can derive a clipboard from a sequence.

With that, we can turn the clipboard into a full-fledged sequence and our copy/paste problems will be gone.

When pasting multiple tracks, we just have to use an identifier for the track's z-position, and act accordingly. If the topmost track is pasted below, we can either deny the paste or (at the user's choice in the options dialog), create new tracks to do the paste.

Having the z-position stored in the clipboard tracks allows for moving clips at will without any difficulties, even if sequence tracks have been added or deleted.

Now the problem is nested tracks. How to handle them? Well, we have to analyse the global effect of having tracks nested. Let's say we have tracks A,B,C and D.

A
B
C
D

Now let's add some container tracks E and F, which will contain A and B, and C and D respectively. Let's call A and B "leaf" tracks, and E and F "branch" tracks.

E - A
 - B
F - C
   D

In the end, it doesn't matter how nested they are, they keep the same order. If D is rendered and C on top of it, combined, they form a single track but the effect is exactly the same. Meaning that when the tree is expanded to its full extent, there will be no problem. We just have to take care of pasting into the "leaf" tracks and everything will be as usual.

This means container tracks can't have clips. They're only made for visualization and handling purposes. So that would leave us with having to use a "trackbase" class to define branch and leaf tracks. Tracks would then need a function to calculate their Z position based on their parent tracks' position. This can be expressed with the following functions:

unsigned int zpos() {
 return get_parent_zpos() + local_zpos;
}

unsigned int get_parent_zpos() {
 unsigned int result;
 if(!m_ParentTrack) {
    result = 0;
 } else {
    result = m_ParentTrack->zpos();
 }
 return result;
}

Finally, to paste and move tracks, we only have to make sure that all tracks are fully expanded - otherwise, pasting (or moving) clips/selections will be forbidden.

The paste operation then becomes simple, it's just iterating over the tracks and pasting the contents. Note that audio tracks will also be copied/cut/pasted if they're linked to the video tracks. To do so, we need to add a "track" member to the clip, to know which track they belong to. For that we also need a "position" member, to tell us the local position in the track. If the track's position slot doesn't equal to the clips', the clips' position is invalidated and the track is rescanned to find the clip. If the clip isn't found, it's then searched in all the tracks, and updated accordingly. If still the cip isn't found, it means we have an orphan clip and it will be deleted.

Our timeline structure is getting more defined :)