This task seems like it’s been on the roadmap for years with little-to-no updates. I’m not familiar enough with the Shotcut project’s codebase to add it myself (and also I don’t trust my C++ ability), but surely this would just be a matter of swapping two references in a list or something? Obviously since Shotcut is a FOSS project it’s unrealistic to expect every feature to be added immediately (and things like keyframes were far more important to work on IMO), but I wouldn’t imagine that this task would take more than a few hours of work if the codebase works in the way I’d expect it to.
Hopefully this gets added soon because I’ve had a ton of frustrations with projects where I wanted to add more background without having to redo all the track filters, especially since there’s currently a bug with filter presets that I’m going to post about in a moment which makes presets with over 50 keyframe positions not save properly.
If you think that this sort of task is simple enough for a 2nd-year comp-sci student with only a small amount of C++ experience, I’ll happily be able to donate my time after this exam period, since I really like Shotcut regardless of all the lag from my bad laptop and the missing features
Just a thought… An announcement this big might deserve its own thread. Rearranging tracks has been one of the most requested features, and people may not find this announcement in here. Great work! Many people will be happy.
An announcement will come with the Beta thread. This is an opportunity for continued discussion. For example, I expect someone will ask for drag-n-drop rearranging tracks. I have looked into that, but not started on it. Maybe there are other ideas about convenient ways this could be used.
Have two clips on top of each other. Select the clip on the track on top then go to the bottom clip and move that track up to take the spot that the track with the clip that was selected was on. Now both clips have been selected even though they haven’t been multi-selected. Demo.
Put a clip all the way at the start of the timeline. Zoom in on the timeline at least about 70% close. Move the track the clip is on either up or down. A spot will show up in the same color as the color that shows a track that is highlighted all the way to the left of the timeline. Demo.
One suggestion that I would want to make is that when you add the ability to actually drag with the mouse a track up or down, that it not need a dragging icon in order to do it. After all, you don’t need an icon to drag clips around the timeline. It’d be best to just make sure that no matter how short the track height that there always be an empty space on the track head where the user can place the mouse on to drag the track up or down. Maybe make the icons on the track head just a little smaller (which would also include the Filter icon that shows accordingly) to help accommodate.
I will not accept a smaller size. They are 16x16, which is already small, a standard size exactly one half their native size, and something smaller will introduce scaling artifacts - not to mention making them an even more difficult target.
How about making the track head slightly longer horizontally? So that way there is an extra space after the Filter icon in case a user is using the shortest height for the track head.
I am leaning toward clearing any selection when moving tracks. This would mean clearing: selected clips, selected tracks and “current” track. Some people might complain that they were expecting something to maintain its selection, but it would avoid these strange effects.
I agree with this. In my current mockup, I added a narrow blank space on the far left of the track head where the user would “grab” the track head. The dragging can not be associated with the name field or the buttons because those already have behaviors associated with clicking on them. I don’t think we need to make anything smaller.
Maybe as a last resort. I think it will be ok. The net effect of the new blank space is that there are about 10 fewer pixels available for the track name. This amounts to about one character. I will accept comments on this during the beta period.
Insert a grab area on the start of the track and making the track header a little wider would not be a big issue.
Maybe, it is possible to reduce the padding between the 4 icons a little to gain some extra pixels, visual it feels like these icons are to far from each other anyway, so move them closer together and to the right, will look better IMHO and doesn’t think it will effect the usability of the icons, if they keep the 16x16 size as they have today.
The grab area could contain the same stacked dots as used by scaling the views in other parts of the UI.
In the current upstream master from github, it is not posible to see the keyboard shotcuts, because the labels “Move track up” and “move track down”
as all these actions is in a “track Operation” sub menu, the “track” part is implicit
so “move up” & “move down” would be enough and don’t think it would make it harder for translators.
The track move both with keyboard and drag & drop is an awesome feature, thanks for that
@brian, the beta’s out but these two bugs are still around:
You think there’s a way this can fixed without having to have the clips be deselected? The beta doesn’t end until the 25th of this month so maybe that’s enough time to discover a solution?
A proper fix is going to require a major re-write of some longstanding code. I came up with a work-around. But it is a bit harsh. I added code to reload the entire timeline when tracks are moved. It works OK for small projects. Can you test it for a large project and see if it is too slow?
For me it’s too slow even on slow projects. I think it’s best to then revert this change because there was a quickness before when the tracks were moved around which was very nice. To lose that in order to correct the two bugs I reported above isn’t worth it.
By the way, has there been any discussion or consideration to rewrite the timeline? I know that would be an undertaking but it really needs improvement on a number of issues, speed all around would be one of them. Plus it wold allow room for more modernization.
