Track Drop-down Menu commands

[steve]

Sorry, but that's hardly a reason, it's rather an obstacle for the programmer. Many menu commands do not care what is selected (play for example). In its simplest form, the key assignement could simply send "shift-m" and "u" to the keyboard buffer.

I'm perhaps being a bit pedantic, but you asked if there is any reason why the drop down menu isn't listed in the keyboard section.
A key assignment that sends shift+M and "u" to the keyboard buffer is not the same as a key binding to the "Move Track Up" command (not to say that it can't be done or would not look much like a key binding to the user). If we take a different example from the drop-down menu, let's say that we bound "Alt+shift+R" to "Set Sample Format" in the drop-down menu. If you have three audio tracks in the project, then there are three drop-down menus. As a "new feature" it could be developed so that a key binding sent a command to the drop down menu(s) of the selected track(s), or to the track in focus, or to all tracks. It probably wouldn't be particularly hard to develop, but it would be a new feature and not simply a matter of just including the drop-down menu commands in the keyboard preferences.

As you say, a little off topic, but I think worth considering (in a new topic).

I have always to move the focus to a neighbouring track to control if I am yet at the right position.

Are you saying that your screen reader only says what the track number is, only when you move focus to that track?
What does the screen reader do when you undo an operation?

[Robert J. H.]

I have always to move the focus to a neighbouring track to control if I am yet at the right position.

Are you saying that your screen reader only says what the track number is, only when you move focus to that track?
What does the screen reader do when you undo an operation?

I'm currently on Audacity 2.0.5.
I've created 4 tracks and the last is renamed to "Audio".
I call the context or drop down menu and choose "Move Track Up".
The screen reader says nothing. I read the current line and it says "Move Track Up". However, the command is applied after the first enter and the current track ("Audio") is read out after pressing enter again (but also "Audacity Panal Track view" is read before that).
I can also press the up or down key after the first enter and it then says "Audacity bla bla" + the track (name, position, etc.) I've navigated to.
If I am at the top, I press ctrl-z. NVDA reads out the usual things + all about the first track (which is now of course "Track 1").
I can now navigate to "Audio" and undo once again. I will always end up on the first track in the track view.
In conclusion, the main issues are:
- NVDA stays in the context menu.
- enter forces NVDA to leave this "hanging" state but also switches the track selectivness.
- Neither "Read Line" nor escape work for this case.
- undo moves the focus to the first track (and reads the information).
For you, only the last point is relevant (the first ones are simply annoying).

[steve]

Thanks for the info Robert.
I've now installed NVDA on my virtual XP machine. I can see the annoyances with loosing the selections. It appears to be a quirk of using NVDA (or perhaps screen readers in general).

I've attached a patch that adds "Move Track to Top", "Move Track to Bottom" and "Swap Stereo Channels". They are all in the main drop down menu and all have access keys as described in my previous post.

Please note, this patch has only been tested on Linux. If there are problems on Windows, perhaps Edgar could offer advice.

[Gale Andrews]

undo moves the focus to the first track

It's a bug: http://bugzilla.audacityteam.org/show_bug.cgi?id=510 .

In your example (rename the fourth track, move it up, undo move) is it most useful for the focus to move back to the fourth track, or stay on the third track? Generally (as a sighted user) I expect the focus to stay put after undo, but when the thing being undone had moved the focus, I'm not so sure.


Gale

[Gale Andrews]

I wonder how many people change waveform view on the fly? Putting just those in a sub-menu would reduce the complexity and mean no current access keys would need to change.

Do you mean, putting Waveform, Waveform dB, Spectrogram, Spectrogram log(f) and Pitch (EAC) into a "Track View" sub menu?

Yes.

My main concern about doing that would be that it reduces the visibility of the Spectrogram option, which is a very useful feature for seeing the precise location of clicks and other artefacts.

Yes, if the name of the cascading menu name was "Set Track View". The only counter I have to that is to call the cascade something like "Wave/Spectrogram Views >" or similar.

But I agree with Robert there should be direct shortcut operation on the drop-down menu items. IIRC, Edgar told me this was difficult, but it seems better to me to make it work on the focused track only in the first instance. If we want some of those commands to work on selected tracks, perhaps consider putting them in the Tracks Menu as well, or handle both selected and focused from the Tracks Menu somehow as per the quite common feature requests to do that.

Apart from that, I think that "U" and "D" for "Move Up" and "Move Down" is a good change. "P" should never have been used in the first place because on many machines the underscore is invisible.

Perhaps, there is an counter benefit that "P" sounds like "Up", and a disbenefit in changing existing keys. Perhaps David B. will have a view.


Gale

[Edgar]

Please note, this patch has only been tested on Linux. If there are problems on Windows, perhaps Edgar could offer advice.

Checking out 2.0.5 RC 1 right now will apply patch tonight sometime but I'm also working with someone else on another problem so it might be late.

[Edgar]

Works just fine on Windows 7. I could not test the accelerator keys because 80 years ago I turn them off and even Google can't tell me how to turn them back on.

[steve]

Thanks Edgar.

because 80 years ago I turn them off and even Google can't tell me how to turn them back on.

[Robert J. H.]

undo moves the focus to the first track

It's a bug: http://bugzilla.audacityteam.org/show_bug.cgi?id=510 .

In your example (rename the fourth track, move it up, undo move) is it most useful for the focus to move back to the fourth track, or stay on the third track? Generally (as a sighted user) I expect the focus to stay put after undo, but when the thing being undone had moved the focus, I'm not so sure.


Gale

For this case, it would be most convenient when the focus is not affected by the undo.
Let's say I want the last track after the 4th one:
I'd sent the last track to the top, move the focus to the target track (which is now the fifth one) and press undo until the previously last track is announced there.
At a first glance, saving the focus, applying the undo and restoring the focus seems straightforward (for the drop down menu actions anyway).
Otherwise, each undo point would have its own saved focus, that's only more ballast.
The only critical point is if your focus is on a track that disappears after the undo (after duplicate for example), in this case, the focus should be on the last track, I guess.

[Gale Andrews]

Thanks, Steve. I gave it a quick try.

I noticed the Undo item should have capitalised "U" in "up" and "D" in "down". Perhaps the History does not need to do so.

I strongly dislike Move Track Up and Down writing per track undo history items. First, it's slow. With 40 tracks on Windows 7, after Move Track Up or Down, I'm waiting for more than five seconds looking at a History box first with a whited out list, and then the whole History window whited out. Second, if I move a track from top to bottom of 40 tracks using "Move Track to Bottom", I expect to undo that in one undo, not iterate on CTRL + Z trying to guess how many undos I need.

I know dragging a track from top to bottom writes an undo step per track, but I would have thought a major benefit of "Move Track to Top/Bottom" was to have only one undo item. As soon as we can get a shortcut for "Move Track Up" and "Move Track Down" I think dragging the track up/down should then be aggregated into one undo item too - undo moves the track back to where you started the drag from.

Also Move Track Up/Down/to Bottom/Top raises the question of whether the view should move with the track that's been moved. Suppose I have the first four tracks of 40 tracks visible, track one selected and focused, and move the fourth track down using the mouse. I don't see the track I moved any longer. Maybe that's OK. But suppose the fourth track is focused - I still don't see the track I moved. Should we not always be able to see the focused track if we have explicitly moved it? Also I bet some people will want to see the track they moved from top to bottom of 40 tracks (and some won't), whether the track is focused or not.

So what do we think are the best rules to apply? Is "as now" best?



Gale