Add menu option to move tracks up and down

[bmatherly]

Added simple move up/down options in the track context menu

Any suggestions for keyboard shortcuts?

[ddennedy]

This is a nice start, thanks, but I had wanted the tracks to be draggable so it can be moved directly to the new place in one step. For that maybe a collection of small bumps to look like a "grip" could be added to the left edge of the track header. Also, I was thinking there should be an API in MLT for this as it is far from obvious for an app how to and a main point of MLT is its manipulation API. Your thoughts on these?

[bmatherly]

I had wanted the tracks to be draggable so it can be moved directly to the new place in one step. For that maybe a collection of small bumps to look like a "grip" could be added to the left edge of the track header.

I thought about that, but I had some prejudice:

• I generally have trouble in applications with dragging rows around. If I drop a row on another row, is it placed before or after the row?
• I'm concerned that drag and drop will cause some extra complication in the code (make sure audio/video can not be intermingled, etc). Is this a high frequency operation that people need the convenience of drag and drop?
• There are already other controls on the track header and I was afraid that people would accidentally click things when trying to drag, or drag things when trying to click
• Would we do DnD in addition to the move up/down commands? Because I expect people are going to want keyboard shortcuts - and I think that would work best with the up/down paradigm.

I am open minded about this, but what I did just seemed simpler than DnD. So that is where I started. But if this is a high-frequency use feature, then it is worth extra effort to make it friendly.

I was thinking there should be an API in MLT for this as it is far from obvious for an app how to

I agree with this, and this is actually where I started. I created a move_track() function. But I failed to figure out a general way to handle the transitions that didn't require me to still write application code to fix the a_track and b_track parameters. So all the function did was replace two calls (remove/insert) with one call (move). I think the a_track and b_track assignments are application specific. Also, the idea of having a specific transition on track 0 would be application specific. So I am not sure how to generalize that. But maybe you can suggest some simple heuristics that would be a generalized way to handle the transitions. I'd be happy to implement that.

Also, I can simply wrap remove()/insert() in a move() function if you think that would be helpful.

I am open minded on both these points. I'm just giving you the perspective of where I started. I'm happy to steer another direction or try something different.

[ddennedy]

OK, I agree and am glad to hear you thought about each of these.

[bmatherly]

Thinking about this some more... I think we could keep the "up/down" commands and also add DnD.

[timlau]

Nice feature, Ctrl-Alt-Up/Down would good candidates to keyboard shortcuts.

Up/Down move active track
Ctrl Up/Down move selection up/down

Ctrl-Alt-I insert new track.

DND would be awesome, but this is very awesome for a keyboard based workflow.

[ddennedy]

I agree with those keyboard shortcuts.

[ddennedy]

I will merge this after keyboard shortcuts are added, and drag-n-drop can be done later if someone gets around to it.

[bmatherly]

Nice feature, Ctrl-Alt-Up/Down would good candidates to keyboard shortcuts.

I agree that suggestion is very intuitive.

On my Ubuntu desktop, CTL+ALT+UP/Down rotates between desktop workspaces. So the keyboard command does not get to Shotcut.

Also, I read that in Windows, some display drivers use CTL+ALT+DOWN to flip the screen. I tested on my Windows desktop and it does not do that. So I am not sure how common that is.

I think that ALT+SHIFT+Up/Down might still be available. How does that sound? Or any other suggestions?

[ddennedy]

On my Ubuntu desktop, CTL+ALT+UP/Down rotates between desktop workspaces.

I see that too, and I suspect it a GNOME Shell default rather than Ubuntu. I found an unofficial source of info says these are alternative shortcuts even though they are not shown in the official docs. Nonetheless, if it prevents Shotcut getting the input events, it's a problem.

ALT+SHIFT+Up/Down might still be available

I have not found any issue with that on macOS desktop with its default shortcuts.

[bmatherly]

I added shortcuts for ALT+SHIFT+Up/Down. We can test it out. It is easy to change later if we don't like it.

drag-n-drop can be done later if someone gets around to it.

I agree it would be a nice improvement. I'll put it somewhere in the back of my TODO list.

[Butterfly]

On my Ubuntu desktop, CTL+ALT+UP/Down rotates between desktop workspaces.

I see that too, and I suspect it a GNOME Shell default rather than Ubuntu. I found an unofficial source of info says these are alternative shortcuts even though they are not shown in the official docs. Nonetheless, if it prevents Shotcut getting the input events, it's a problem.

ALT+SHIFT+Up/Down might still be available

I have not found any issue with that on macOS desktop with its default shortcuts.

I just test drove these in Debian Bookworm XFCE4. On a screen where everything is minimalized, nothing occurred, at least visually, for CTRL+, CTRL+SHIFT+, ALT+, CTRL+ALT+(UP & DOWN). I even tried CTRL+ALT+SHIFT+, and still nothing. Yay. 😆

The following ramble may be obvious to most but is just being said since I'm already here....

Within Firefox Nightly (and most, if not all, of their most recent releases), CTRL+UP/Down visually moves the User's focus back and forth one tab at a time across all of the open tabs. In other words, a User is switched to a completely different tab when using those keyboard shortcuts.

CTRL+SHIFT+UP/Down physically keeps the focus on and then moves a single, affected tab up or down to a different location in a current window's lineup. This is actually something that has worked across multiple different browsers over the last few years.

Accessibility-wise, CTRL+SHIFT+UP/Down is potentially the easier CHOICE for someone with dexterity related disabilities when considered versus using a cursor to drag-n-drop. The only benefit I've seen for choosing a cursor over keyboard shortcuts is that a cursor can drag-n-drop a tab to a new or existing secondary (different) window. I've not (yet) tripped over a similar keyboard shortcut that performs the same function.

As an afterthought, if someone's looking for example code, Firefox does do the cursor drag-n-drop for physically moving single tabs around in a window, too. Firefox-ESR was doing it, but I'm in Nightly these days so I can only assume that still holds true.

A couple other browsers did (and two others actually did NOT) respond to CTRL+SHIFT+UP/Down just now. The significance is about the "borrowing" of code that is truly open source versus protected. Chromium and epiphany-browser did respond, and both are installed via Debian's main repositories.

Rightly or wrongly, I've always assumed that inclusion in Main implies that the included code could be morphed into other unrelated projects, although it may mean that a courtesy head nod would be necessary somewhere in a project's credits block. Then it comes down to a decision about how one creator views another creator's reputation out in the open source community overall... and does one want one's own reputation to be tied to that via an explicit online and inline hat tip. /ramble 😄