How should we generalize Track Panel focus and make it accessible?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How should we generalize Track Panel focus and make it accessible?

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 thinking thus:

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







------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

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).
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

On 18/05/2017, Paul Licameli <[hidden email]> wrote:

> 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
> thinking thus:
>
> 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
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

Robert Hänggi
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

On 18/05/2017, Robert Hänggi <[hidden email]> wrote:

> 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
>
> On 18/05/2017, Paul Licameli <[hidden email]> wrote:
>> 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
>> thinking thus:
>>
>> 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
>>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

Paul Licameli
In reply to this post by Robert Hänggi


On Thu, May 18, 2017 at 12:53 PM, Robert Hänggi <[hidden email]> wrote:
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.

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
 

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

On 18/05/2017, Paul Licameli <[hidden email]> wrote:
> 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
> thinking thus:
>
> 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
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

Robert Hänggi
>
> 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 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

> 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
>
>
>>
>> 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
>>
>> On 18/05/2017, Paul Licameli <[hidden email]> wrote:
>> > 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
>> > thinking thus:
>> >
>> > 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
>> >
>>
>> ------------------------------------------------------------
>> ------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

Paul Licameli


On Thu, May 18, 2017 at 4:07 PM, Robert Hänggi <[hidden email]> wrote:
>
> 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 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

 

> 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
>
>
>>
>> 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
>>
>> On 18/05/2017, Paul Licameli <[hidden email]> wrote:
>> > 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
>> > thinking thus:
>> >
>> > 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
>> >
>>
>> ------------------------------------------------------------
>> ------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

Robert Hänggi
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

On 18/05/2017, Paul Licameli <[hidden email]> wrote:

> On Thu, May 18, 2017 at 4:07 PM, Robert Hänggi <[hidden email]>
> wrote:
>
>> >
>> > 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 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
>
>
>
>>
>> > 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
>> >
>> >
>> >>
>> >> 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
>> >>
>> >> On 18/05/2017, Paul Licameli <[hidden email]> wrote:
>> >> > 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
>> >> > thinking thus:
>> >> >
>> >> > 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
>> >> >
>> >>
>> >> ------------------------------------------------------------
>> >> ------------------
>> >> 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
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> >>
>> >
>>
>> ------------------------------------------------------------
>> ------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

James Crook
In reply to this post by Robert Hänggi
On 5/18/2017 9:07 PM, Robert Hänggi wrote:

>> 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 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.

> 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.


> 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
>
>> 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
>>
>>
>>> 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
>>>
>>> On 18/05/2017, Paul Licameli <[hidden email]> wrote:
>>>> 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
>>>> thinking thus:
>>>>
>>>> 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
>>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> 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
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

Robert Hänggi
On 18/05/2017, James Crook <[hidden email]> wrote:

> On 5/18/2017 9:07 PM, Robert Hänggi wrote:
>>> 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 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

>> 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

>
>
>> 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
>>
>>> 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
>>>
>>>
>>>> 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
>>>>
>>>> On 18/05/2017, Paul Licameli <[hidden email]> wrote:
>>>>> 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
>>>>> thinking thus:
>>>>>
>>>>> 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
>>>>>
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> 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
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

Robert Hänggi
In reply to this post by James Crook
On 18/05/2017, James Crook <[hidden email]> wrote:

> On 5/18/2017 9:07 PM, Robert Hänggi wrote:
>>> 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 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

>> 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

>
>
>> 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
>>
>>> 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
>>>
>>>
>>>> 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
>>>>
>>>> On 18/05/2017, Paul Licameli <[hidden email]> wrote:
>>>>> 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
>>>>> thinking thus:
>>>>>
>>>>> 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
>>>>>
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> 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
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

James Crook
In reply to this post by Robert Hänggi
On 5/19/2017 6:26 AM, Robert Hänggi wrote:

> On 18/05/2017, James Crook <[hidden email]> wrote:
>> On 5/18/2017 9:07 PM, Robert Hänggi wrote:
>>>> 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 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
>
>>> 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.
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.

>
> Robert


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

Gale
Administrator
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


On 19 May 2017 at 08:23, James Crook <[hidden email]> wrote:

> On 5/19/2017 6:26 AM, Robert Hänggi wrote:
>> On 18/05/2017, James Crook <[hidden email]> wrote:
>>> On 5/18/2017 9:07 PM, Robert Hänggi wrote:
>>>>> 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 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
>>
>>>> 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.
> 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.
>
>>
>> Robert
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

Robert Hänggi
On 19/05/2017, Gale Andrews <[hidden email]> wrote:
> 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.

> 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

>
>
>
> Gale
>
>
> On 19 May 2017 at 08:23, James Crook <[hidden email]> wrote:
>> On 5/19/2017 6:26 AM, Robert Hänggi wrote:
>>> On 18/05/2017, James Crook <[hidden email]> wrote:
>>>> On 5/18/2017 9:07 PM, Robert Hänggi wrote:
>>>>>> 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 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
>>>
>>>>> 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.
>> 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.
>>
>>>
>>> Robert
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

David Bailes-3
In reply to this post by Paul Licameli
On Thu, May 18, 2017 at 4:05 PM, Paul Licameli <[hidden email]> wrote:
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 thinking thus:

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.
 

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.
 
  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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

Robert Hänggi
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

On 20/05/2017, David Bailes <[hidden email]> wrote:

> On Thu, May 18, 2017 at 4:05 PM, Paul Licameli <[hidden email]>
> wrote:
>
>> 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
>> thinking thus:
>>
>> 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.
>
>
>>
>> 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.
>
>
>>   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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

David Bailes-3
On Sat, May 20, 2017 at 1:26 PM, Robert Hänggi <[hidden email]> wrote:
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?

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

Robert

On 20/05/2017, David Bailes <[hidden email]> wrote:
> On Thu, May 18, 2017 at 4:05 PM, Paul Licameli <[hidden email]>
> wrote:
>
>> 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
>> thinking thus:
>>
>> 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.
>
>
>>
>> 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.
>
>
>>   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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How should we generalize Track Panel focus and make it accessible?

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

Robert

On 20/05/2017, David Bailes <[hidden email]> wrote:

> On Sat, May 20, 2017 at 1:26 PM, Robert Hänggi <[hidden email]>
> wrote:
>
>> 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?
>>
>
> The hierarchy looks ok here - the controls in the toolbars have the toolbar
> as parent.
> David.
>
>>
>> Robert
>>
>> On 20/05/2017, David Bailes <[hidden email]> wrote:
>> > On Thu, May 18, 2017 at 4:05 PM, Paul Licameli
>> > <[hidden email]>
>> > wrote:
>> >
>> >> 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
>> >> thinking thus:
>> >>
>> >> 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.
>> >
>> >
>> >>
>> >> 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.
>> >
>> >
>> >>   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
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> >>
>> >>
>> >
>>
>> ------------------------------------------------------------
>> ------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...