[Audacity-devel] How should we generalize Track Panel focus and make it accessible?

Hi Paul
Interesting thoughts.
Are you familiar with Reaper?
Some NVDA developers have built an extension that makes it accessible
to screen readers (not just NVDA).
It is written in C++ and can be found here:
https://github.com/nvaccess/osara
Perhaps, you'll find some interesting things there if you have some
leisure time...
Anyway, not all problems are resolved there either and we could make
some innovative headway in this respect if we wanted to.

NVDA has an interesting combination to set parameters of a voice, a so
called ring.
The model could work for sliders and other track properties as well:

First, you would press down Shift+Alt (as for gain and pan currently)
Arrows left and right would select the parameter to adjust;
in its simplest form gain-pan-gain... (ring)
The up and down keys select the value.
The value will be set after lifting the fingers on the modifiers.
The last selected parameter will be stored for the next invocation
(good if you want to make eg gain staging on multiple tracks).
Visually could a counterpart be defined, for instance a temporarily
popping up window with the title of the slider and the slider itself.
Mouse users could adjust the slider directly, choose another parameter
type etc.

The nice thing is that multiple effects could be served with the same
four shortcuts, not just two like it is now.

For example, the ring menu could hold:

- Gain
- Pan
- (Stereo) Width
- High pass (assuming a non-destructive effect, not yet implemented)
- Clip Shift
- Step Size (for movement or clip shift)
. . .

Ideally, other shortcuts that use Shift+Alt would still work.
-------------
A second idea is to have multiple selection modes for the clips/labels problem.
That is, the user can switch to clip navigation and use the same
keystrokes as for sample/time navigation.
Thus, left/right would jump from clip to clip, the shift modifier
would extend to the previous/next boundary, control could shift the
selected clips and so on.

Reaper uses here all possible key combinations with available
modifiers, arrow and page keys. Fairly hard to remember.

I will stop now lest I get trapped in an endless soliloquy.
Robert

Post by Paul Licameli
David Bailes' adding of commands to shift clips left and right, and Robert
Hänggi's reminder about the slider increase/decrease commands, has set me
Such commands combine "verb" and "object." It's not good that we need one
command for each useful combination, and therefore we proliferate many
commands like these. Better that we have a user interface to make the
recombinations more easily expressed as needed with your fingertips.
Better, in fact, that even without a talking desktop, Audacity should still
contain something like the VoiceOver navigation.
When I use VoiceOver, interactive things in applications are grouped into a
logical hierarchy. There are keystrokes that universally mean "navigate
across the hierarchy." These are control+alt+arrow -- any one of the four
arrows, to indicate the geometrical direction, but logically it always
moves across the hierarchy, from one sister to another.
Likewise "navigate up hierarchy" is universally shift+control+alt+up and
"navigate down hierarchy" is shift+control+alt+down.
Then for a properly implemented slider (not all of Audacity's are, yet),
you navigate "to" it, then "into" it, then use control+alt+arrows to adjust
it. And an adjustable clip might act like a slider.
I am less familiar with Jaws and NVDA (or Orca, which wxWidgets can't
interact with). I presume there is some similar keystroke convention.
Now notice that in our code, already there is a notion of focused track,
and it is maintained in the class TrackPanelAx, even if accessibility is
not enabled. It is drawn with a yellow border, which is like the black
border that the talking desktop draws over it. They yellow and black
borders always move together. Audacity implements change of focus by means
of unmodified presses of arrow keys, while VoiceOver also permits the other
control+alt+arrow convention.
I propose that what is already done for maintaining Audacity's notion of
focus in a wxAccessible class, even without accessibility -- should be
generalized to other things like the pan and gain sliders or individual
clips. Audacity should define a more extensive wxAccesible hierarchy of
objects, and use it in normal excution. Some keystrokes -- I don't know
which -- should be reserved for navigation of this hierarchy and made
non-reassignable in Preferences.
I did not have this in mind when I developed my track panel refactor, but I
mean to review my work and (I hope) push it, with this future development
in mind.
I do not propose to realize these ideas in 2.2.0, or do it all myself, but
perhaps David would be interested in extending my work in this direction,
once I share it.
David made some mention of alteration of samples or envelope points by
keyboard. I don't know what details are contemplated here. It could be an
extension of this.
PRL

Robert Hänggi

2017-05-18 17:11:33 UTC

PS.
It is very simple to navigate the hierarchy of Audacity with NVDA:
Press insert along with the number keys on the num pad.
Insert (or caps lock on lap-top layouts) + F1 = developer info for
navigator object.
I think the hierarchy could go deeper into the tracks.
The parent is now the track view panel but multiple tracks are not
siblings, ie only one track is recognized by this navigation method
and you can't switch to different areas (info, sliders, buttons,
waveform disply).
Not that the latter level would be useful, I just wanted to mention it.
It is of course interesting from a script developers perspective as it
would allow mouse restriction to the waveform during scrubbing. In
other words, it would be interesting to have all these items as info
available although they don't have to be focusable/selectable and so
on.
Robert

Post by Robert HÃ¤nggi
Hi Paul
Interesting thoughts.
Are you familiar with Reaper?
Some NVDA developers have built an extension that makes it accessible
to screen readers (not just NVDA).
https://github.com/nvaccess/osara
Perhaps, you'll find some interesting things there if you have some
leisure time...
Anyway, not all problems are resolved there either and we could make
some innovative headway in this respect if we wanted to.
NVDA has an interesting combination to set parameters of a voice, a so
called ring.
First, you would press down Shift+Alt (as for gain and pan currently)
Arrows left and right would select the parameter to adjust;
in its simplest form gain-pan-gain... (ring)
The up and down keys select the value.
The value will be set after lifting the fingers on the modifiers.
The last selected parameter will be stored for the next invocation
(good if you want to make eg gain staging on multiple tracks).
Visually could a counterpart be defined, for instance a temporarily
popping up window with the title of the slider and the slider itself.
Mouse users could adjust the slider directly, choose another parameter
type etc.
The nice thing is that multiple effects could be served with the same
four shortcuts, not just two like it is now.
- Gain
- Pan
- (Stereo) Width
- High pass (assuming a non-destructive effect, not yet implemented)
- Clip Shift
- Step Size (for movement or clip shift)
. . .
Ideally, other shortcuts that use Shift+Alt would still work.
-------------
A second idea is to have multiple selection modes for the clips/labels problem.
That is, the user can switch to clip navigation and use the same
keystrokes as for sample/time navigation.
Thus, left/right would jump from clip to clip, the shift modifier
would extend to the previous/next boundary, control could shift the
selected clips and so on.
Reaper uses here all possible key combinations with available
modifiers, arrow and page keys. Fairly hard to remember.
I will stop now lest I get trapped in an endless soliloquy.
Robert

Paul Licameli

2017-05-18 18:36:44 UTC

Regarding the last: I too had said enough for one email, but now I will
drop another idea:

The mapping from keystrokes to commands should not, as now, be merely
global. It should be *contextual.*

That is, for each type of focusable entity (assuming generalized focus as I
decribed), there is another mapping. The time (and frequency) selection
range would itself be one of the foci, but so too, as you suggest, could be
clips.

So the same key could mean different things in different contexts,
relieving the worry that we are running out of keystrokes.

And another idea: each keystroke could be programmed to invoke not one but
a sequence of commands, and also, changes, or pushes and pops, of the
focus. A key might also invoke a macro subroutine bound to some other key,
or a reusable subroutine bound to no key.

Obviously there would be quite a lot of work to realize this generalization
of our present keystroke preferences.

PRL

Post by Robert HÃ¤nggi
Reaper uses here all possible key combinations with available
modifiers, arrow and page keys. Fairly hard to remember.
I will stop now lest I get trapped in an endless soliloquy.
Robert

Post by Paul Licameli
David Bailes' adding of commands to shift clips left and right, and

Robert

Post by Paul Licameli
HÃ€nggi's reminder about the slider increase/decrease commands, has set me
Such commands combine "verb" and "object." It's not good that we need

one

Post by Paul Licameli
command for each useful combination, and therefore we proliferate many
commands like these. Better that we have a user interface to make the
recombinations more easily expressed as needed with your fingertips.
Better, in fact, that even without a talking desktop, Audacity should

still

Post by Paul Licameli
contain something like the VoiceOver navigation.
When I use VoiceOver, interactive things in applications are grouped

into a

Post by Paul Licameli
logical hierarchy. There are keystrokes that universally mean "navigate
across the hierarchy." These are control+alt+arrow -- any one of the

four

Post by Paul Licameli
arrows, to indicate the geometrical direction, but logically it always
moves across the hierarchy, from one sister to another.
Likewise "navigate up hierarchy" is universally shift+control+alt+up and
"navigate down hierarchy" is shift+control+alt+down.
Then for a properly implemented slider (not all of Audacity's are, yet),
you navigate "to" it, then "into" it, then use control+alt+arrows to

adjust

Post by Paul Licameli
it. And an adjustable clip might act like a slider.
I am less familiar with Jaws and NVDA (or Orca, which wxWidgets can't
interact with). I presume there is some similar keystroke convention.
Now notice that in our code, already there is a notion of focused track,
and it is maintained in the class TrackPanelAx, even if accessibility is
not enabled. It is drawn with a yellow border, which is like the black
border that the talking desktop draws over it. They yellow and black
borders always move together. Audacity implements change of focus by

means

Post by Paul Licameli
of unmodified presses of arrow keys, while VoiceOver also permits the

other

Post by Paul Licameli
control+alt+arrow convention.
I propose that what is already done for maintaining Audacity's notion of
focus in a wxAccessible class, even without accessibility -- should be
generalized to other things like the pan and gain sliders or individual
clips. Audacity should define a more extensive wxAccesible hierarchy of
objects, and use it in normal excution. Some keystrokes -- I don't know
which -- should be reserved for navigation of this hierarchy and made
non-reassignable in Preferences.
I did not have this in mind when I developed my track panel refactor,

but I

Post by Paul Licameli
mean to review my work and (I hope) push it, with this future development
in mind.
I do not propose to realize these ideas in 2.2.0, or do it all myself,

but

Post by Paul Licameli
perhaps David would be interested in extending my work in this direction,
once I share it.
David made some mention of alteration of samples or envelope points by
keyboard. I don't know what details are contemplated here. It could be

Post by Paul Licameli
extension of this.
PRL

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Robert Hänggi

2017-05-18 20:07:00 UTC

Post by Paul Licameli
Regarding the last: I too had said enough for one email, but now I will
The mapping from keystrokes to commands should not, as now, be merely
global. It should be *contextual.*
That is, for each type of focusable entity (assuming generalized focus as I
decribed), there is another mapping. The time (and frequency) selection
range would itself be one of the foci, but so too, as you suggest, could be
clips.
So the same key could mean different things in different contexts,
relieving the worry that we are running out of keystrokes.

And it is also a necessity if we want to fix eg the bug that you
cannot type numbers into a number control if a shortcut exists (like
the "1" bug in project rate).
Another example is that space bar always starts playback, regardless
of the fact that the focus is eg on a button in the tool bars.

I assume that some workarounds/hacks have been applied already but not
yet in a proper framework as you seem to support. (for instance,
Shift+Enter can start starts looped playback when on the play button.
However, if this shortcut will be assigned to another command, it will
no longer work on buttons.
See also James' comment on this subject.

Robert

Post by Paul Licameli
And another idea: each keystroke could be programmed to invoke not one but
a sequence of commands, and also, changes, or pushes and pops, of the
focus. A key might also invoke a macro subroutine bound to some other key,
or a reusable subroutine bound to no key.
Obviously there would be quite a lot of work to realize this generalization
of our present keystroke preferences.
PRL

Post by Paul Licameli
David Bailes' adding of commands to shift clips left and right, and

Robert

Post by Paul Licameli
Hänggi's reminder about the slider increase/decrease commands, has set me
Such commands combine "verb" and "object." It's not good that we need

one

still

Post by Paul Licameli
contain something like the VoiceOver navigation.
When I use VoiceOver, interactive things in applications are grouped

into a

Post by Paul Licameli
logical hierarchy. There are keystrokes that universally mean "navigate
across the hierarchy." These are control+alt+arrow -- any one of the

four

adjust

means

Post by Paul Licameli
of unmodified presses of arrow keys, while VoiceOver also permits the

other

but I

Post by Paul Licameli
mean to review my work and (I hope) push it, with this future development
in mind.
I do not propose to realize these ideas in 2.2.0, or do it all myself,

but

Post by Paul Licameli
extension of this.
PRL

Paul Licameli

2017-05-18 20:37:37 UTC

as I

Post by Paul Licameli
decribed), there is another mapping. The time (and frequency) selection
range would itself be one of the foci, but so too, as you suggest, could

Post by Paul Licameli
clips.
So the same key could mean different things in different contexts,
relieving the worry that we are running out of keystrokes.

And it is also a necessity if we want to fix eg the bug that you
cannot type numbers into a number control if a shortcut exists (like
the "1" bug in project rate).
Another example is that space bar always starts playback, regardless
of the fact that the focus is eg on a button in the tool bars.
I assume that some workarounds/hacks have been applied already but not
yet in a proper framework as you seem to support. (for instance,
Shift+Enter can start starts looped playback when on the play button.
However, if this shortcut will be assigned to another command, it will
no longer work on buttons.
See also James' comment on this subject.
Robert

Which comment, where?

PRL

Post by Paul Licameli
And another idea: each keystroke could be programmed to invoke not one

but

Post by Paul Licameli
a sequence of commands, and also, changes, or pushes and pops, of the
focus. A key might also invoke a macro subroutine bound to some other

key,

Post by Paul Licameli
or a reusable subroutine bound to no key.
Obviously there would be quite a lot of work to realize this

generalization

Post by Paul Licameli
of our present keystroke preferences.
PRL

Post by Paul Licameli
David Bailes' adding of commands to shift clips left and right, and

Robert

Post by Paul Licameli
HÃ€nggi's reminder about the slider increase/decrease commands, has set me
Such commands combine "verb" and "object." It's not good that we need

one

still

Post by Paul Licameli
contain something like the VoiceOver navigation.
When I use VoiceOver, interactive things in applications are grouped

into a

Post by Paul Licameli
logical hierarchy. There are keystrokes that universally mean "navigate
across the hierarchy." These are control+alt+arrow -- any one of the

four

adjust

black

Post by Paul Licameli
border that the talking desktop draws over it. They yellow and black
borders always move together. Audacity implements change of focus by

means

Post by Paul Licameli
of unmodified presses of arrow keys, while VoiceOver also permits the

other

individual

Post by Paul Licameli
clips. Audacity should define a more extensive wxAccesible hierarchy of
objects, and use it in normal excution. Some keystrokes -- I don't know
which -- should be reserved for navigation of this hierarchy and made
non-reassignable in Preferences.
I did not have this in mind when I developed my track panel refactor,

but I

Post by Paul Licameli
mean to review my work and (I hope) push it, with this future development
in mind.
I do not propose to realize these ideas in 2.2.0, or do it all myself,

but

Post by Paul Licameli
extension of this.
PRL

Robert Hänggi

2017-05-18 21:20:30 UTC

Sorry, I can't find it right now.

It came up within the clip discussion.
I've proposed differentiated catching of keyboard events and James
gave some reasons why this isn't currently possible due to WX and the
overall command hierarchy within Audacity, i.e. how events are
forwarded internally.

Robert

as I

Post by Paul Licameli
decribed), there is another mapping. The time (and frequency) selection
range would itself be one of the foci, but so too, as you suggest, could

Post by Paul Licameli
clips.
So the same key could mean different things in different contexts,
relieving the worry that we are running out of keystrokes.

And it is also a necessity if we want to fix eg the bug that you
cannot type numbers into a number control if a shortcut exists (like
the "1" bug in project rate).
Another example is that space bar always starts playback, regardless
of the fact that the focus is eg on a button in the tool bars.
I assume that some workarounds/hacks have been applied already but not
yet in a proper framework as you seem to support. (for instance,
Shift+Enter can start starts looped playback when on the play button.
However, if this shortcut will be assigned to another command, it will
no longer work on buttons.
See also James' comment on this subject.
Robert

Which comment, where?
PRL

Post by Paul Licameli
And another idea: each keystroke could be programmed to invoke not one

but

Post by Paul Licameli
a sequence of commands, and also, changes, or pushes and pops, of the
focus. A key might also invoke a macro subroutine bound to some other

key,

Post by Paul Licameli
or a reusable subroutine bound to no key.
Obviously there would be quite a lot of work to realize this

generalization

Post by Paul Licameli
of our present keystroke preferences.
PRL

Post by Paul Licameli
David Bailes' adding of commands to shift clips left and right, and

Robert

Post by Paul Licameli
Hänggi's reminder about the slider increase/decrease commands, has
set
me
Such commands combine "verb" and "object." It's not good that we need

one

still

Post by Paul Licameli
contain something like the VoiceOver navigation.
When I use VoiceOver, interactive things in applications are grouped

into a

Post by Paul Licameli
logical hierarchy. There are keystrokes that universally mean "navigate
across the hierarchy." These are control+alt+arrow -- any one of the

four

adjust

Post by Paul Licameli
it. And an adjustable clip might act like a slider.
I am less familiar with Jaws and NVDA (or Orca, which wxWidgets can't
interact with). I presume there is some similar keystroke convention.
Now notice that in our code, already there is a notion of focused track,
and it is maintained in the class TrackPanelAx, even if
accessibility
is
not enabled. It is drawn with a yellow border, which is like the

black

Post by Paul Licameli
border that the talking desktop draws over it. They yellow and black
borders always move together. Audacity implements change of focus by

means

Post by Paul Licameli
of unmodified presses of arrow keys, while VoiceOver also permits the

other

individual

Post by Paul Licameli
clips. Audacity should define a more extensive wxAccesible
hierarchy
of
objects, and use it in normal excution. Some keystrokes -- I don't know
which -- should be reserved for navigation of this hierarchy and made
non-reassignable in Preferences.
I did not have this in mind when I developed my track panel refactor,

but I

Post by Paul Licameli
mean to review my work and (I hope) push it, with this future development
in mind.
I do not propose to realize these ideas in 2.2.0, or do it all myself,

but

Post by Paul Licameli
extension of this.
PRL

James Crook

2017-05-18 21:34:26 UTC

And it is also a necessity if we want to fix eg the bug that you
cannot type numbers into a number control if a shortcut exists (like
the "1" bug in project rate).

That bug is DEVEL-FIX MADE. I expect it will be closed when possible
unwanted side effects have been properly tested.

Post by Robert HÃ¤nggi
Another example is that space bar always starts playback, regardless
of the fact that the focus is eg on a button in the tool bars.

Currently that is deliberate, but I can change that.

Post by Robert HÃ¤nggi
I assume that some workarounds/hacks have been applied already but not
yet in a proper framework as you seem to support. (for instance,
Shift+Enter can start starts looped playback when on the play button.
However, if this shortcut will be assigned to another command, it will
no longer work on buttons.
See also James' comment on this subject.
Robert

Post by Paul Licameli
David Bailes' adding of commands to shift clips left and right, and

Robert

Post by Paul Licameli
Hänggi's reminder about the slider increase/decrease commands, has set me
Such commands combine "verb" and "object." It's not good that we need

one

still

Post by Paul Licameli
contain something like the VoiceOver navigation.
When I use VoiceOver, interactive things in applications are grouped

into a

Post by Paul Licameli
logical hierarchy. There are keystrokes that universally mean "navigate
across the hierarchy." These are control+alt+arrow -- any one of the

four

adjust

means

Post by Paul Licameli
of unmodified presses of arrow keys, while VoiceOver also permits the

other

but I

Post by Paul Licameli
mean to review my work and (I hope) push it, with this future development
in mind.
I do not propose to realize these ideas in 2.2.0, or do it all myself,

but

Post by Paul Licameli
extension of this.
PRL

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Robert Hänggi

2017-05-19 05:26:34 UTC

And it is also a necessity if we want to fix eg the bug that you
cannot type numbers into a number control if a shortcut exists (like
the "1" bug in project rate).

That bug is DEVEL-FIX MADE. I expect it will be closed when possible
unwanted side effects have been properly tested.

Perfect

Post by Robert HÃ¤nggi
Another example is that space bar always starts playback, regardless
of the fact that the focus is eg on a button in the tool bars.

Currently that is deliberate, but I can change that.

It's not a severe issue, on the contrary.
I wished it would also work in effects, i.e. pressing space bar on any
slider or numerical control would start and stop playback (RTP) or
preview. It would be far more convenient than Alt+P. Same with comma
and period. However, that's difficult due to the processing chain of
the inputs, as you said earlier.

Robert

Post by Paul Licameli
And another idea: each keystroke could be programmed to invoke not one but
a sequence of commands, and also, changes, or pushes and pops, of the
focus. A key might also invoke a macro subroutine bound to some other key,
or a reusable subroutine bound to no key.
Obviously there would be quite a lot of work to realize this
generalization
of our present keystroke preferences.
PRL

Post by Paul Licameli
David Bailes' adding of commands to shift clips left and right, and

Robert

Post by Paul Licameli
Hänggi's reminder about the slider increase/decrease commands, has set me
Such commands combine "verb" and "object." It's not good that we need

one

still

Post by Paul Licameli
contain something like the VoiceOver navigation.
When I use VoiceOver, interactive things in applications are grouped

into a

Post by Paul Licameli
logical hierarchy. There are keystrokes that universally mean "navigate
across the hierarchy." These are control+alt+arrow -- any one of the

four

adjust

means

Post by Paul Licameli
of unmodified presses of arrow keys, while VoiceOver also permits the

other

but I

Post by Paul Licameli
mean to review my work and (I hope) push it, with this future development
in mind.
I do not propose to realize these ideas in 2.2.0, or do it all myself,

but

Post by Paul Licameli
extension of this.
PRL

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Robert Hänggi

2017-05-19 05:26:34 UTC

And it is also a necessity if we want to fix eg the bug that you
cannot type numbers into a number control if a shortcut exists (like
the "1" bug in project rate).

That bug is DEVEL-FIX MADE. I expect it will be closed when possible
unwanted side effects have been properly tested.

Perfect

Post by Robert HÃ¤nggi
Another example is that space bar always starts playback, regardless
of the fact that the focus is eg on a button in the tool bars.

Currently that is deliberate, but I can change that.

Post by Paul Licameli
And another idea: each keystroke could be programmed to invoke not one but
a sequence of commands, and also, changes, or pushes and pops, of the
focus. A key might also invoke a macro subroutine bound to some other key,
or a reusable subroutine bound to no key.
Obviously there would be quite a lot of work to realize this
generalization
of our present keystroke preferences.
PRL

Post by Paul Licameli
David Bailes' adding of commands to shift clips left and right, and

Robert

Post by Paul Licameli
Hänggi's reminder about the slider increase/decrease commands, has set me
Such commands combine "verb" and "object." It's not good that we need

one

still

Post by Paul Licameli
contain something like the VoiceOver navigation.
When I use VoiceOver, interactive things in applications are grouped

into a

Post by Paul Licameli
logical hierarchy. There are keystrokes that universally mean "navigate
across the hierarchy." These are control+alt+arrow -- any one of the

four

adjust

means

Post by Paul Licameli
of unmodified presses of arrow keys, while VoiceOver also permits the

other

but I

Post by Paul Licameli
mean to review my work and (I hope) push it, with this future development
in mind.
I do not propose to realize these ideas in 2.2.0, or do it all myself,

but

Post by Paul Licameli
extension of this.
PRL

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2017-05-19 07:23:50 UTC

And it is also a necessity if we want to fix eg the bug that you
cannot type numbers into a number control if a shortcut exists (like
the "1" bug in project rate).

That bug is DEVEL-FIX MADE. I expect it will be closed when possible
unwanted side effects have been properly tested.

Perfect

Post by Robert HÃ¤nggi
Another example is that space bar always starts playback, regardless
of the fact that the focus is eg on a button in the tool bars.

Currently that is deliberate, but I can change that.

That too could probably be made to work, at least for the built-in
effects, by adding to the EffectUIHost event table, catching chars
there, and using the same logic as in the toolbars of giving
CommandManager::FilterKeyEvent first dibs on handling the command.

Probably needs a little more clarity about exactly what is wanted/what
the ideal is. Also the current logic treats all controls the same way,
and if we use it inside effects dialogs we might want 'Space' to
continue to toggle checkboxes, but on a slider to start/stop play.

Gale Andrews

2017-05-19 15:32:19 UTC

It seems useful to me that using Space when in e.g. focused
Playback Volume Slider or in a focused TimeText control in
Selection Toolbar should play the audio, but that arrow keys
still operate the slider or TimeText control.

ENTER clicks the button in a docked or undocked toolbar if it
has focus.

Gale

And it is also a necessity if we want to fix eg the bug that you
cannot type numbers into a number control if a shortcut exists (like
the "1" bug in project rate).

That bug is DEVEL-FIX MADE. I expect it will be closed when possible
unwanted side effects have been properly tested.

Perfect

Post by Robert HÃ¤nggi
Another example is that space bar always starts playback, regardless
of the fact that the focus is eg on a button in the tool bars.

Currently that is deliberate, but I can change that.

That too could probably be made to work, at least for the built-in
effects, by adding to the EffectUIHost event table, catching chars
there, and using the same logic as in the toolbars of giving
CommandManager::FilterKeyEvent first dibs on handling the command.
Probably needs a little more clarity about exactly what is wanted/what
the ideal is. Also the current logic treats all controls the same way,
and if we use it inside effects dialogs we might want 'Space' to
continue to toggle checkboxes, but on a slider to start/stop play.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Robert Hänggi

2017-05-19 20:27:59 UTC

Post by Gale Andrews
It seems useful to me that using Space when in e.g. focused
Playback Volume Slider or in a focused TimeText control in
Selection Toolbar should play the audio, but that arrow keys
still operate the slider or TimeText control.

Absolutely
That's why I said that it would be marvellous to extend this behaviour
to the modeless dialogs (RTP) as well.
In other words, forwarding keystrokes to the track panel if they are
not applicable to the currently focused item.
In most cases, this would be space bar (unless there's a button,
checkbox or text input)
Similarly, "j" would jump to the start of the track, comma could
replace seek forward and so on.
Some shortcuts had to be blocked of course (executing another effect
for example).
And all would have to be made control-type by control-type
(fortunately, one can add them step-by-step).
However, it would be worth the labour I think since it does
essentially avoid the necessity to switch around with Alt+F6.

Post by Gale Andrews
ENTER clicks the button in a docked or undocked toolbar if it
has focus.

...and if Enter is not assigned differently.
Since this is a unlikely case, I've brought the example with
Shift+Enter which can easily be assigned to a command but not longer
be used on Play or Play-at-Speed.

Robert

Post by Gale Andrews
Gale

Post by Paul Licameli
Regarding the last: I too had said enough for one email, but now I will
The mapping from keystrokes to commands should not, as now, be merely
global. It should be *contextual.*
That is, for each type of focusable entity (assuming generalized focus
as
I
decribed), there is another mapping. The time (and frequency) selection
range would itself be one of the foci, but so too, as you suggest,
could
be
clips.
So the same key could mean different things in different contexts,
relieving the worry that we are running out of keystrokes.

And it is also a necessity if we want to fix eg the bug that you
cannot type numbers into a number control if a shortcut exists (like
the "1" bug in project rate).

That bug is DEVEL-FIX MADE. I expect it will be closed when possible
unwanted side effects have been properly tested.

Perfect

Post by Robert HÃ¤nggi
Another example is that space bar always starts playback, regardless
of the fact that the focus is eg on a button in the tool bars.

Currently that is deliberate, but I can change that.

That too could probably be made to work, at least for the built-in
effects, by adding to the EffectUIHost event table, catching chars
there, and using the same logic as in the toolbars of giving
CommandManager::FilterKeyEvent first dibs on handling the command.
Probably needs a little more clarity about exactly what is wanted/what
the ideal is. Also the current logic treats all controls the same way,
and if we use it inside effects dialogs we might want 'Space' to
continue to toggle checkboxes, but on a slider to start/stop play.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

David Bailes

2017-05-20 11:45:50 UTC

Post by Paul Licameli
David Bailes' adding of commands to shift clips left and right, and Robert
HÃ€nggi's reminder about the slider increase/decrease commands, has set me
Such commands combine "verb" and "object." It's not good that we need one
command for each useful combination, and therefore we proliferate many
commands like these. Better that we have a user interface to make the
recombinations more easily expressed as needed with your fingertips.
Better, in fact, that even without a talking desktop, Audacity should
still contain something like the VoiceOver navigation.
When I use VoiceOver, interactive things in applications are grouped into
a logical hierarchy. There are keystrokes that universally mean "navigate
across the hierarchy." These are control+alt+arrow -- any one of the four
arrows, to indicate the geometrical direction, but logically it always
moves across the hierarchy, from one sister to another.
Likewise "navigate up hierarchy" is universally shift+control+alt+up and
"navigate down hierarchy" is shift+control+alt+down.
Then for a properly implemented slider (not all of Audacity's are, yet),
you navigate "to" it, then "into" it, then use control+alt+arrows to adjust
it. And an adjustable clip might act like a slider.
I am less familiar with Jaws and NVDA (or Orca, which wxWidgets can't
interact with). I presume there is some similar keystroke convention.
Now notice that in our code, already there is a notion of focused track,
and it is maintained in the class TrackPanelAx, even if accessibility is
not enabled. It is drawn with a yellow border, which is like the black
border that the talking desktop draws over it. They yellow and black
borders always move together. Audacity implements change of focus by means
of unmodified presses of arrow keys, while VoiceOver also permits the other
control+alt+arrow convention.
I propose that what is already done for maintaining Audacity's notion of
focus in a wxAccessible class, even without accessibility -- should be
generalized to other things like the pan and gain sliders or individual
clips. Audacity should define a more extensive wxAccesible hierarchy of
objects, and use it in normal excution. Some keystrokes -- I don't know
which -- should be reserved for navigation of this hierarchy and made
non-reassignable in Preferences.

The standard model for moving focus in Windows is flat, it isn't
hierarchical. So, at least on Windows, I don't think it would be helpful
to users to use a hierarchical model in Audacity.

Many Windows screen readers can navigate the accessible api in a
hierarchical manner, but the primary purpose of this is not to move focus.

Post by Paul Licameli
I did not have this in mind when I developed my track panel refactor, but
I mean to review my work and (I hope) push it, with this future development
in mind.
I do not propose to realize these ideas in 2.2.0, or do it all myself, but
perhaps David would be interested in extending my work in this direction,
once I share it.
David made some mention of alteration of samples or envelope points by
keyboard. I don't know what details are contemplated here.

Envelope points could be made keyboard accessible by having a set of
commands available similar to those available in Reaper. That is something
along the lines of:
1. commands to move to the next/previous envelope point.
2. a context/pop up menu for envelope points whose contents varies
depending on whether the cursor is at an envelope point. The menu would
contains commands such as create, delete, properties, clear all points,
etc, where appropriate.

David.

Post by Paul Licameli
It could be an extension of this.
PRL
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Robert Hänggi

2017-05-20 12:26:34 UTC

Regarding Hierarchy:

It seems to be broken in the currant build.
If I navigate up to the parent of Track Panel, I land on Track view.
The siblings of it are the scroll bars and then all tool bar controls
in succession.
In other words, they are not longer children of the tool bars
themselves and their parents "tool docks" and "Frames" (for floating
tool bars)

Is that only on my system so?

Robert

Post by Paul Licameli
David Bailes' adding of commands to shift clips left and right, and Robert
Hänggi's reminder about the slider increase/decrease commands, has set me
Such commands combine "verb" and "object." It's not good that we need one
command for each useful combination, and therefore we proliferate many
commands like these. Better that we have a user interface to make the
recombinations more easily expressed as needed with your fingertips.
Better, in fact, that even without a talking desktop, Audacity should
still contain something like the VoiceOver navigation.
When I use VoiceOver, interactive things in applications are grouped into
a logical hierarchy. There are keystrokes that universally mean "navigate
across the hierarchy." These are control+alt+arrow -- any one of the four
arrows, to indicate the geometrical direction, but logically it always
moves across the hierarchy, from one sister to another.
Likewise "navigate up hierarchy" is universally shift+control+alt+up and
"navigate down hierarchy" is shift+control+alt+down.
Then for a properly implemented slider (not all of Audacity's are, yet),
you navigate "to" it, then "into" it, then use control+alt+arrows to adjust
it. And an adjustable clip might act like a slider.
I am less familiar with Jaws and NVDA (or Orca, which wxWidgets can't
interact with). I presume there is some similar keystroke convention.
Now notice that in our code, already there is a notion of focused track,
and it is maintained in the class TrackPanelAx, even if accessibility is
not enabled. It is drawn with a yellow border, which is like the black
border that the talking desktop draws over it. They yellow and black
borders always move together. Audacity implements change of focus by means
of unmodified presses of arrow keys, while VoiceOver also permits the other
control+alt+arrow convention.
I propose that what is already done for maintaining Audacity's notion of
focus in a wxAccessible class, even without accessibility -- should be
generalized to other things like the pan and gain sliders or individual
clips. Audacity should define a more extensive wxAccesible hierarchy of
objects, and use it in normal excution. Some keystrokes -- I don't know
which -- should be reserved for navigation of this hierarchy and made
non-reassignable in Preferences.

The standard model for moving focus in Windows is flat, it isn't
hierarchical. So, at least on Windows, I don't think it would be helpful
to users to use a hierarchical model in Audacity.
Many Windows screen readers can navigate the accessible api in a
hierarchical manner, but the primary purpose of this is not to move focus.

Envelope points could be made keyboard accessible by having a set of
commands available similar to those available in Reaper. That is something
1. commands to move to the next/previous envelope point.
2. a context/pop up menu for envelope points whose contents varies
depending on whether the cursor is at an envelope point. The menu would
contains commands such as create, delete, properties, clear all points,
etc, where appropriate.
David.

David Bailes

2017-05-20 12:54:05 UTC

Post by Robert HÃ¤nggi
It seems to be broken in the currant build.
If I navigate up to the parent of Track Panel, I land on Track view.
The siblings of it are the scroll bars and then all tool bar controls
in succession.
In other words, they are not longer children of the tool bars
themselves and their parents "tool docks" and "Frames" (for floating
tool bars)
Is that only on my system so?

The hierarchy looks ok here - the controls in the toolbars have the toolbar
as parent.
David.

Post by Paul Licameli
David Bailes' adding of commands to shift clips left and right, and Robert
HÃ€nggi's reminder about the slider increase/decrease commands, has set

Post by Paul Licameli
Such commands combine "verb" and "object." It's not good that we need one
command for each useful combination, and therefore we proliferate many
commands like these. Better that we have a user interface to make the
recombinations more easily expressed as needed with your fingertips.
Better, in fact, that even without a talking desktop, Audacity should
still contain something like the VoiceOver navigation.
When I use VoiceOver, interactive things in applications are grouped

into

Post by Paul Licameli
a logical hierarchy. There are keystrokes that universally mean "navigate
across the hierarchy." These are control+alt+arrow -- any one of the four
arrows, to indicate the geometrical direction, but logically it always
moves across the hierarchy, from one sister to another.
Likewise "navigate up hierarchy" is universally shift+control+alt+up and
"navigate down hierarchy" is shift+control+alt+down.
Then for a properly implemented slider (not all of Audacity's are, yet),
you navigate "to" it, then "into" it, then use control+alt+arrows to adjust
it. And an adjustable clip might act like a slider.
I am less familiar with Jaws and NVDA (or Orca, which wxWidgets can't
interact with). I presume there is some similar keystroke convention.
Now notice that in our code, already there is a notion of focused track,
and it is maintained in the class TrackPanelAx, even if accessibility is
not enabled. It is drawn with a yellow border, which is like the black
border that the talking desktop draws over it. They yellow and black
borders always move together. Audacity implements change of focus by means
of unmodified presses of arrow keys, while VoiceOver also permits the other
control+alt+arrow convention.
I propose that what is already done for maintaining Audacity's notion of
focus in a wxAccessible class, even without accessibility -- should be
generalized to other things like the pan and gain sliders or individual
clips. Audacity should define a more extensive wxAccesible hierarchy of
objects, and use it in normal excution. Some keystrokes -- I don't know
which -- should be reserved for navigation of this hierarchy and made
non-reassignable in Preferences.

The standard model for moving focus in Windows is flat, it isn't
hierarchical. So, at least on Windows, I don't think it would be helpful
to users to use a hierarchical model in Audacity.
Many Windows screen readers can navigate the accessible api in a
hierarchical manner, but the primary purpose of this is not to move

focus.

Post by Paul Licameli
I did not have this in mind when I developed my track panel refactor,

but

Post by Paul Licameli
I mean to review my work and (I hope) push it, with this future development
in mind.
I do not propose to realize these ideas in 2.2.0, or do it all myself, but
perhaps David would be interested in extending my work in this

direction,

Post by Paul Licameli
once I share it.
David made some mention of alteration of samples or envelope points by
keyboard. I don't know what details are contemplated here.

Envelope points could be made keyboard accessible by having a set of
commands available similar to those available in Reaper. That is

something

Post by David Bailes
1. commands to move to the next/previous envelope point.
2. a context/pop up menu for envelope points whose contents varies
depending on whether the cursor is at an envelope point. The menu would
contains commands such as create, delete, properties, clear all points,
etc, where appropriate.
David.

Robert Hänggi

2017-05-20 14:47:12 UTC

Thanks David
I'll see how it looks like in the next build or after restart.

Robert

The hierarchy looks ok here - the controls in the toolbars have the toolbar
as parent.
David.