Feature request: Moving tracks

[steve]

As I see it, holding CTRL while clicking would not change selectedness or focus

Holding Ctrl down to not change selectedness (of any tracks) sounds like it could be a good idea.

I don't think that dragging a track that doesn't have focus makes sense, and may not be possible without a lot of hacking around the current code. How would you describe what track focus means?

I don't think the current drag behaviour is completely intuitive now, where you have to use SHIFT and click twice to drag without changing selectedness.

I agree that holding Shift and clicking twice is not intuitive. I don't think that is an intended "feature".
The intended behaviours are, as far as I'm aware,

• Click on track information panel selects the track.
• Shift + Click on track information panel toggles track selectedness.
• Drag a track information panel moves the track.

Mix and match these behaviours as you will.

What we don't currently have is the ability to change track focus with the mouse without also changing the selectedness. Ctrl+Click looks like a good way to do that.

[Gale Andrews]

I don't think that dragging a track that doesn't have focus makes sense, and may not be possible without a lot of hacking around the current code. How would you describe what track focus means?

Unless we are going to tackle this we will never be able to drag multiple selected clips up and down either, which seems a considerable limitation to me.

In your example scenario the unselected track being dragged does not have focus, but it takes focus when drag is released.

My suggestion is only to move all selected tracks when CTRL-dragging a selected track. Perhaps the dragged track takes focus when it is released, which isn't a change of behaviour, or...

What we don't currently have is the ability to change track focus with the mouse without also changing the selectedness. Ctrl+Click looks like a good way to do that.

...I wasn't envisaging that CTRL-click would change focus but I think it's OK that it does change focus. That would get over your objection above, wouldn't it?


Gale

[steve]

...I wasn't envisaging that CTRL-click would change focus but I think it's OK that it does change focus. That would get over your objection above, wouldn't it?

Probably, but I'm still interested in what "focus" means. I found several references to "focus" in the manual, but nothing that said what the yellow line around the track actually indicates (other than "track has focus").

[Gale Andrews]

Well how would you describe "focus"?

Its main importance as I understand it is for screen readers. The track that has focus is read.

Functionally, focus doesn't seem to have a great deal of importance otherwise, except it is the focused track whose Track Drop-Down Menu opens when you press SHIFT + M.

If no track has focus that's because the main project window does not have focus.


Gale

[steve]

Well how would you describe "focus"?

Not easily

I'd describe a track as a container for some type of data (according to the track type). Track focus indicates the "track" (as distinct from the data) that we are currently acting on. For example, to pan, solo, mute, drag, toggle the selectedness or open the menu of a track, we need to focus on that track. Our action is focussed on that track rather than any other track, in the same way as the "active project" is the project window that we can act on.

Focus is distinct from "selectedness" in that we "select" the contents of one or more tracks, but we can have the contents of one track selected while acting on a different track.

If we had a command to move multiple tracks, the (only) way that we could actually do that in the code is to iterate through the tracks. In effect, giving focus to one track and then moving it, then giving focus to the next track and moving it, then giving focus to the next track and so on. Even in the code we can't actually act on multiple tracks at the same time. An example can be seen in "Collapse All Tracks" which iterates through each track in turn and minimises it. We do that successfully with a menu command, but with a mouse/pointing device we can only click on one track collapse button at a time.

Code: Select all

void AudacityProject::OnCollapseAllTracks()
{
   TrackListIterator iter(mTracks);
   Track *t = iter.First();

   while (t)
   {
      t->SetMinimized(true);
      t = iter.Next();
   }

   ModifyState(true);
   RedrawProject();
}

[Gale Andrews]

Well how would you describe "focus"?

Not easily

I'd describe a track as a container for some type of data (according to the track type). Track focus indicates the "track" (as distinct from the data) that we are currently acting on. For example, to pan, solo, mute, drag, toggle the selectedness or open the menu of a track, we need to focus on that track. Our action is focussed on that track rather than any other track, in the same way as the "active project" is the project window that we can act on.

Even that description has a weakness, in that if using the mouse, you can change the mute/solo/gain/pan/perform many Track Drop-Down Menu actions without changing the yellow border focus.

I guess the best place to describe focus may be on http://manual.audacityteam.org/man/Audio_Tracks .

If we had a command to move multiple tracks, the (only) way that we could actually do that in the code is to iterate through the tracks. In effect, giving focus to one track and then moving it, then giving focus to the next track and moving it, then giving focus to the next track and so on. Even in the code we can't actually act on multiple tracks at the same time.

I'm reminded in Bug 500 – Vertical Drag: Drag Selection with clip/drag all clips in track/drag multiple tracks not implemented that we already reserve CTRL + left-click drag for vertical drag of clips, so that when vertical dragging you don't inadvertently drag horizontally.

So if we ever do mouse-vertically-drag multiple selected tracks and clips, we may want to use ALT rather than CTRL.

Neither James or Michael Chinen ever indicated to me that we could not vertical drag multiple clips. I created Bug 500 because it was suggested I do that when we were looking at other vertical drag bugs.


Gale

[steve]

Even that description has a weakness

It does.
Would you care to have a go at defining "focus"?

I guess the best place to describe focus may be on http://manual.audacityteam.org/man/Audio_Tracks .

Now that we're discussing it, it seems odd that page describes just about everything about tracks except for what "focus" means.

I'm reminded in Bug 500

I don't recall ever wanting to drag the selection in multiple tracks up or down, but James is right, if we support dragging multiple clips vertically then we need to know what to do if the selection is in multiple tracks.

Horizontally we drag the "selected" clips, but vertically we only drag the "pointed at" clip. Intuitively I'd expect multiple selected clips to drag together whether we are dragging vertically or horizontally or both, provided there is room for all of the selected clips without changing their relative positions. I can see the difficulty implementing that, but nevertheless that is what "should" happen imo.

[Gale Andrews]

Even that description has a weakness

It does.
Would you care to have a go at defining "focus"?

Do we want to describe only the yellow border focus? Is any other unseen focus relevant (the focus that would show if you ran accessibility tools)?

I guess the best place to describe focus may be on http://manual.audacityteam.org/man/Audio_Tracks .

Now that we're discussing it, it seems odd that page describes just about everything about tracks except for what "focus" means.

I added a Px for that .

I'm reminded in Bug 500

I don't recall ever wanting to drag the selection in multiple tracks up or down, but James is right, if we support dragging multiple clips vertically then we need to know what to do if the selection is in multiple tracks.

OK let's take a simple case. First two tracks each have a selected clip. Bottom two tracks are empty. If we could drag both clips together, I assume we don't change track selectedness so we now have empty space selected in the first two tracks.

What happens if we point over the second track to drag both selected tracks, and release drag over the third track? Moves both clips down one track?

What happens if there was only one empty track and you dragged both selected tracks down? Should only the pointed-to clip move?

Are these the "what to do" questions?

Intuitively I'd expect multiple selected clips to drag together whether we are dragging vertically or horizontally or both, provided there is room for all of the selected clips without changing their relative positions. I can see the difficulty implementing that, but nevertheless that is what "should" happen imo.

Good. But if we allow moving clips vertically with the mouse, I think we should allow moving tracks vertically with the mouse.


Gale

[steve]

Do we want to describe only the yellow border focus?

That would be a good start.

Is any other unseen focus relevant (the focus that would show if you ran accessibility tools)?

I've not used accessibility tools so I don't know what those things are.

Dragging selected audio in multiple tracks vertically:
For the simple case with 4 tracks:

"-----"= white space.
"WWWW" = selected audio clip.
"NNN" = Not selected audio clip.

Before dragging:

Code: Select all

---WWW----
WWWW------
----------
----------

After dragging either audio clip one track down:

Code: Select all

----------
---WWW----
WWWW------
----------

After dragging another track down:

Code: Select all

----------
----------
---WWW----
WWWW------

Provided there is room in the destination track for the dragged clips, the clips can be dragged. This is the same "rule" as when dragging multiple selected audio clips horizontally.

A more complex example:

Code: Select all

---WWW----
NNN--NNN--
WWWW------
----------
----------

The selected audio clips cannot be dragged down by one track because there is no room in track 2 for the audio clip in track 1, but if we keep dragging, they can be dragged down by two tracks to give:

Code: Select all

----------
NNN--NNN--
---WWW----
----------
WWWW------

Again it is the same rule as when dragging multiple clips horizontally; the clips can be dragged as long as there is room for them.

However, if we allow discontinuous selections and dragging multiple clips vertically as well as horizontally, it becomes horribly complicated in complex cases if multiple discontinuous selected audio clips are dragged vertically AND horizontally.

This:

Code: Select all

WWW----WWW----NN----------

can drag to here:

Code: Select all

---WWW----WWWNN-----------

and then drag (jump) to here:

Code: Select all

-----WWW--NNWWW--------------

and to here:

Code: Select all

-------WWWNN--WWW--------------

and then drag (jump) to here:

Code: Select all

-------NNWWW----WWW----------

and on...

Code: Select all

-------NN---WWW----WWW-------

Even as now where we only drag multiple clips horizontally, doing so when there are other clips "in the way" quickly reveals the difficulty in handling this in the code.Adding another "dimension" to the dragging makes it much more difficult, (although in my opinion it should be possible to keep to the same "simple" rule of allowing dragging provided there is room for all of the dragged clips).

[steve]

But if we allow moving clips vertically with the mouse, I think we should allow moving tracks vertically with the mouse.

I think the case is different.
When we drag audio clips, we are dragging "selected" audio clips.

(Currently) when we move tracks, either with the drop down menu command or with the mouse, we are moving the "track with focus" and its selectedness is irrelevant.

I think that we could allow dragging multiple tracks, but for it to make sense it would be a different type of track moving (and using different code). Moving the tracks would depend on "selectedness" and either track focus would then be irrelevant for this type of track moving, or it would be a hybrid of selectedness and focus. The behaviour of this new "type" of track moving, as far as the user is concerned, would be virtually the same as now, but different rules apply. Although there would be additioal functionality, I'm not convinced that it is worth the increased complexity. The current rule is simple: the track with focus is the track that moves.