[Audacity-devel] Extra menus for VI (and other) use?

[James Crook]

There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.

They are shown as belonging to a menu called 'Command'.

The commands which are bound by default are also listed in the manual,
in tables at the end of the page
http://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference

There they are organised better than in preferences:
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.


I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.

When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
menus will likely be called:

* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)


This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.


The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.


What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?


--James.

[Gale Andrews]

Thanks, James.

I'm +1 to my current thinking. It certainly aids discoverability of
these commands. Some experienced sighted users will find them
useful too.

I think the new Preference could mention "keyboard" in its name
to declare its purpose. "Show keyboard commands as extra
menus" or similar.

I hope we might manage with only two extra menus. The current
organisation of the commands in Keyboard Shortcut Reference is
necessarily arbitrary. For example I might have put the -at-speed
commands in a Transcription Toolbar section.

Do you envisage all the commands on Keyboard Shortcut Reference
that are now under "Audio Track Dropdown Menu" should go under
the proposed Extra-Focus menu item?


Gale

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the page
http://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[James Crook]

Post by Gale Andrews
Thanks, James.
I'm +1 to my current thinking. It certainly aids discoverability of
these commands. Some experienced sighted users will find them
useful too.
I think the new Preference could mention "keyboard" in its name
to declare its purpose. "Show keyboard commands as extra
menus" or similar.
I hope we might manage with only two extra menus. The current
organisation of the commands in Keyboard Shortcut Reference is
necessarily arbitrary. For example I might have put the -at-speed
commands in a Transcription Toolbar section.

Extra-Bar and Extra-Commands, with Focus as a submenu would work too.
For VI users there is a slight advantage in having more rather than
fewer top-level menus.

Post by Gale Andrews
Do you envisage all the commands on Keyboard Shortcut Reference
that are now under "Audio Track Dropdown Menu" should go under
the proposed Extra-Focus menu item?

I hadn't noticed that there were some that were not already on the Audio
Track Dropdown menu.
Now that I have, I'd be tempted to add a submenu to that menu, with name
'Controls', and it has pan, gain, mute solo on it. Sighted users would
see it, whether or not they enable Extra-menus, and if they explore the
submenu they will see that there are keyboard shortcuts for the track
controls.

--James.

Post by Gale Andrews
Gale

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the page
http://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

[Gale Andrews]

The extra "Controls" submenu for Audio Track Dropdown Menu
could be good. A bugbear of sighted users that is often expressed
in projects with many tracks is that (apparently) you have to
expand or drag down a collapsed track to access its controls.

It might not be so obvious to them though that this works only if
the track is focused.



Gale

Post by James Crook

Post by Gale Andrews
Thanks, James.
I'm +1 to my current thinking. It certainly aids discoverability of
these commands. Some experienced sighted users will find them
useful too.
I think the new Preference could mention "keyboard" in its name
to declare its purpose. "Show keyboard commands as extra
menus" or similar.
I hope we might manage with only two extra menus. The current
organisation of the commands in Keyboard Shortcut Reference is
necessarily arbitrary. For example I might have put the -at-speed
commands in a Transcription Toolbar section.

Extra-Bar and Extra-Commands, with Focus as a submenu would work too.
For VI users there is a slight advantage in having more rather than
fewer top-level menus.

Post by Gale Andrews
Do you envisage all the commands on Keyboard Shortcut Reference
that are now under "Audio Track Dropdown Menu" should go under
the proposed Extra-Focus menu item?

I hadn't noticed that there were some that were not already on the Audio
Track Dropdown menu.
Now that I have, I'd be tempted to add a submenu to that menu, with name
'Controls', and it has pan, gain, mute solo on it. Sighted users would
see it, whether or not they enable Extra-menus, and if they explore the
submenu they will see that there are keyboard shortcuts for the track
controls.
--James.

Post by Gale Andrews
Gale

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the page
http://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

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

[David Bailes]

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the page
http://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.

Can you list the commands that you are proposing moving from the existing
menus into the new menus?
thanks,
David.

Post by James Crook
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[James Crook]

Post by David Bailes

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the page
http://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.

Can you list the commands that you are proposing moving from the existing
menus into the new menus?
thanks,
David.

Mostly it is that the occult commands become bone-fide menu commands,
for people who choose to have the extra menus.

If it were my decision alone, I would move the zoom 1px commands and the
save/restore cursor position. I'd move some others too, IF the extra
menus, once enabled, are convenient for VI users. It is, or will be, a
group decision though, as was the decision to elevate 'select' to a new
top level menu.

Mainly I want to establish whether the extra-menus idea itself is a net
win. If it is not good at all for VI users, it is back to the drawing
board on that idea for how to make things work well for both sighted and
VI users.

--James.

Post by David Bailes

Post by James Crook
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

[David Bailes]

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the pagehttp://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
Can you list the commands that you are proposing moving from the existing
menus into the new menus?
thanks,
David.
Mostly it is that the occult commands become bone-fide menu commands, for
people who choose to have the extra menus.
If it were my decision alone, I would move the zoom 1px commands and the
save/restore cursor position. I'd move some others too,

which are "some others" ?

David.

Post by James Crook
IF the extra menus, once enabled, are convenient for VI users. It is, or
will be, a group decision though, as was the decision to elevate 'select'
to a new top level menu.
Mainly I want to establish whether the extra-menus idea itself is a net
win. If it is not good at all for VI users, it is back to the drawing
board on that idea for how to make things work well for both sighted and VI
users.
--James.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[David Bailes]

Post by David Bailes

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the pagehttp://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
Can you list the commands that you are proposing moving from the existing
menus into the new menus?
thanks,
David.
Mostly it is that the occult commands become bone-fide menu commands, for
people who choose to have the extra menus.
If it were my decision alone, I would move the zoom 1px commands and the
save/restore cursor position. I'd move some others too,

which are "some others" ?

I presume these are the commands which you say 'get in the way'. These may
well be the same commands as "some others", but if not, could you give me a
full list of the commands which you think 'get in the way'.

thanks,
David.

Post by David Bailes
David.

Post by James Crook
IF the extra menus, once enabled, are convenient for VI users. It is, or
will be, a group decision though, as was the decision to elevate 'select'
to a new top level menu.
Mainly I want to establish whether the extra-menus idea itself is a net
win. If it is not good at all for VI users, it is back to the drawing
board on that idea for how to make things work well for both sighted and VI
users.
--James.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[James Crook]

Post by David Bailes

Post by David Bailes

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the pagehttp://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
Can you list the commands that you are proposing moving from the existing
menus into the new menus?
thanks,
David.
Mostly it is that the occult commands become bone-fide menu commands, for
people who choose to have the extra menus.
If it were my decision alone, I would move the zoom 1px commands and the
save/restore cursor position. I'd move some others too,

which are "some others" ?

I presume these are the commands which you say 'get in the way'. These may
well be the same commands as "some others", but if not, could you give me a
full list of the commands which you think 'get in the way'.

The 'some others' matter less to me than the ones I named first, so I am
not going to be lobbying hard to move the 'some others', particularly if
there are good arguments for keeping them in the default menus.

For me personally the select->Region, the select->Clip-Boundaries, the
view->skip-to and transport->cursor-to commands all just 'get in the
way'. For me it is easier to select/navigate visually than use these.
Gale currently regards the commands to navigate to clips as essential
for all users, so I think it is likely that group would stay.




Note that I also think we may be able to make some commands more logical
/ more systematic. Navigating between labels, and navigating between
clips, could/should be analogous things, and for example a single
preference option for wrapping round at the end / not doing so, would be
good. It could be no-wrap by default, and some sighted users would find
it convenient to wrap, because they can see when a wrap round has happened.

The current cursor, and the current point where we are playing/recording
audio are in my view similar things, so ought to behave analogously
too. We ought to be able to move the play head to next clip boundary or
next label boundary whilst playing. It could be that those navigation
commands affect the play head if playing, and the cursor if not.

There are many actions where there is a natural question of whether the
action is on the focused track, is on all selected tracks, or is on all
tracks. That could be made more systematic too.

--James.

Post by David Bailes
thanks,
David.

Post by David Bailes
David.

Post by James Crook
IF the extra menus, once enabled, are convenient for VI users. It is, or
will be, a group decision though, as was the decision to elevate 'select'
to a new top level menu.
Mainly I want to establish whether the extra-menus idea itself is a net
win. If it is not good at all for VI users, it is back to the drawing
board on that idea for how to make things work well for both sighted and VI
users.
--James.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

[Gale Andrews]

I agree with "more systematic" in principle. It helps if similar things
can be predicted to behave in similar ways.

Skipping playback to the next or previous label boundary works now
with David's ALT + RIGHT or LEFT.


Gale

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the
pagehttp://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
Can you list the commands that you are proposing moving from the existing
menus into the new menus?
thanks,
David.
Mostly it is that the occult commands become bone-fide menu commands, for
people who choose to have the extra menus.
If it were my decision alone, I would move the zoom 1px commands and the
save/restore cursor position. I'd move some others too,
which are "some others" ?
I presume these are the commands which you say 'get in the way'. These may
well be the same commands as "some others", but if not, could you give me a
full list of the commands which you think 'get in the way'.
The 'some others' matter less to me than the ones I named first, so I am not
going to be lobbying hard to move the 'some others', particularly if there
are good arguments for keeping them in the default menus.
For me personally the select->Region, the select->Clip-Boundaries, the
view->skip-to and transport->cursor-to commands all just 'get in the way'.
For me it is easier to select/navigate visually than use these. Gale
currently regards the commands to navigate to clips as essential for all
users, so I think it is likely that group would stay.
Note that I also think we may be able to make some commands more logical /
more systematic. Navigating between labels, and navigating between clips,
could/should be analogous things, and for example a single preference option
for wrapping round at the end / not doing so, would be good. It could be
no-wrap by default, and some sighted users would find it convenient to wrap,
because they can see when a wrap round has happened.
The current cursor, and the current point where we are playing/recording
audio are in my view similar things, so ought to behave analogously too. We
ought to be able to move the play head to next clip boundary or next label
boundary whilst playing. It could be that those navigation commands affect
the play head if playing, and the cursor if not.
There are many actions where there is a natural question of whether the
action is on the focused track, is on all selected tracks, or is on all
tracks. That could be made more systematic too.
--James.
thanks,
David.
David.
IF the extra menus, once enabled, are convenient for VI users. It is, or
will be, a group decision though, as was the decision to elevate 'select'
to a new top level menu.
Mainly I want to establish whether the extra-menus idea itself is a net
win. If it is not good at all for VI users, it is back to the drawing
board on that idea for how to make things work well for both sighted and VI
users.
--James.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------
------------------
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
------------------------------------------------------------------------------
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
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Peter Sampson]

I am generally in favour of this approach, as I would :

a) like to be able to simplify the interface for normally-sighted users,

b) while not removing functionality from VI users

c) and providing a framework to extend VI capability without impacting
unnecessarily on normally sighted-users.

If we achieve us I can envisage us released two Audacities, one for VI
and te other for normally sighted users - where the only differences are
the default options, preferences and Toolbars that we set.

I do not feel competent to comment on the details of this proposal.

Peter.

[James Crook]

I would much prefer that we release one actual tested release of
Audacity rather than two Peter.
There is too much risk that we'd do it once or twice and then the 'VI
version' would lag behind Audacity.

I think the features for VI users need explaining, and such an
explanation can also explain how to set keyboard shortcuts and make
other customisations that are useful for VI users. Obviously we want to
make that easy, rather than to force VI users to make many settings
changes. But we should do that within Audacity rather than as a
separate version.


--James.

Post by Peter Sampson
a) like to be able to simplify the interface for normally-sighted users,
b) while not removing functionality from VI users
c) and providing a framework to extend VI capability without impacting
unnecessarily on normally sighted-users.
If we achieve us I can envisage us released two Audacities, one for VI
and te other for normally sighted users - where the only differences are
the default options, preferences and Toolbars that we set.
I do not feel competent to comment on the details of this proposal.
Peter.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Peter Sampson]

I would much prefer that we release one actual tested release of Audacity
rather than two Peter.
There is too much risk that we'd do it once or twice and then the 'VI
version' would lag behind Audacity.

Maybe we could have a special command that would set/unset the VI
features/functionality?

Off by default.

Peter

I think the features for VI users need explaining, and such an explanation
can also explain how to set keyboard shortcuts and make other
customisations that are useful for VI users. Obviously we want to make
that easy, rather than to force VI users to make many settings changes.
But we should do that within Audacity rather than as a separate version.
--James.
a) like to be able to simplify the interface for normally-sighted users,
b) while not removing functionality from VI users
c) and providing a framework to extend VI capability without impacting
unnecessarily on normally sighted-users.
If we achieve us I can envisage us released two Audacities, one for VI
and te other for normally sighted users - where the only differences are
the default options, preferences and Toolbars that we set.
I do not feel competent to comment on the details of this proposal.
Peter.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Nigel Worsley]

Post by Peter Sampson
Maybe we could have a special command that would set/unset the VI
features/functionality?

And perhaps have this set by an installer option? That would make it
far easier to find for those that need it, as well as drawing their
attention to the fact that it exists!

Nigle

[Gale Andrews]

Post by Nigel Worsley

Post by Peter Sampson
Maybe we could have a special command that would set/unset the VI
features/functionality?

And perhaps have this set by an installer option? That would make it
far easier to find for those that need it, as well as drawing their
attention to the fact that it exists!

The special command would (per current thinking) be in
Preferences.

For practical purposes, only Windows would benefit from an
installer option, though Audacity for Windows does have the
best VI support.


Gale

[David Bailes]

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the pagehttp://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
Can you list the commands that you are proposing moving from the existing
menus into the new menus?
thanks,
David.
Mostly it is that the occult commands become bone-fide menu commands, for
people who choose to have the extra menus.
If it were my decision alone, I would move the zoom 1px commands and the
save/restore cursor position. I'd move some others too, IF the extra
menus, once enabled, are convenient for VI users. It is, or will be, a
group decision though,

you mean it will be a group decision which commands get moved from the
current menus to the new additional menus?

David.

Post by James Crook
as was the decision to elevate 'select' to a new top level menu.
Mainly I want to establish whether the extra-menus idea itself is a net
win. If it is not good at all for VI users, it is back to the drawing
board on that idea for how to make things work well for both sighted and VI
users.
--James.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[James Crook]

Post by David Bailes

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the pagehttp://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
Can you list the commands that you are proposing moving from the existing
menus into the new menus?
thanks,
David.
Mostly it is that the occult commands become bone-fide menu commands, for
people who choose to have the extra menus.
If it were my decision alone, I would move the zoom 1px commands and the
save/restore cursor position. I'd move some others too, IF the extra
menus, once enabled, are convenient for VI users. It is, or will be, a
group decision though,

you mean it will be a group decision which commands get moved from the
current menus to the new additional menus?

Yes.

Post by David Bailes
David.

Post by James Crook
as was the decision to elevate 'select' to a new top level menu.
Mainly I want to establish whether the extra-menus idea itself is a net
win. If it is not good at all for VI users, it is back to the drawing
board on that idea for how to make things work well for both sighted and VI
users.
--James.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

[Gale Andrews]

The "save"/restore selection commands are valuable for sighted
users. It is unfortunate that they are now hidden in a submenu,
but IMO they should be developed to restore the zoom level
and Timeline position as per (sighted) user requests, not made
optional as if they were only for VI users.

I think the "Zoom 1px to" commands actually are VI commands
on the whole, and should be capable of freeform text entry and
of being decoupled from zoom level, as Robert suggested.

If consensus is not to move them into the Extra menu and nothing
else happens, I intend to move them into the top level of View as
"Step Size", below "Track Size". In my opinion they are mostly
useless as zoom presets and are a confusing liability where they
are now.


Gale

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the page
http://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
Can you list the commands that you are proposing moving from the existing
menus into the new menus?
thanks,
David.
Mostly it is that the occult commands become bone-fide menu commands, for
people who choose to have the extra menus.
If it were my decision alone, I would move the zoom 1px commands and the
save/restore cursor position. I'd move some others too, IF the extra menus,
once enabled, are convenient for VI users. It is, or will be, a group
decision though, as was the decision to elevate 'select' to a new top level
menu.
Mainly I want to establish whether the extra-menus idea itself is a net win.
If it is not good at all for VI users, it is back to the drawing board on
that idea for how to make things work well for both sighted and VI users.
--James.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[David Bailes]

Post by Gale Andrews
The "save"/restore selection commands are valuable for sighted
users. It is unfortunate that they are now hidden in a submenu,
but IMO they should be developed to restore the zoom level
and Timeline position as per (sighted) user requests, not made
optional as if they were only for VI users.
I think the "Zoom 1px to" commands actually are VI commands
on the whole, and should be capable of freeform text entry and
of being decoupled from zoom level, as Robert suggested.
If consensus is not to move them into the Extra menu and nothing
else happens, I intend to move them into the top level of View as
"Step Size", below "Track Size". In my opinion they are mostly
useless as zoom presets and are a confusing liability where they
are now.

I've removed the presets:
https://github.com/audacity/audacity/commit/592453082bee5fbca271405304c124638a341d85

David.

Post by Gale Andrews
Gale

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the page
http://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
Can you list the commands that you are proposing moving from the existing
menus into the new menus?
thanks,
David.
Mostly it is that the occult commands become bone-fide menu commands, for
people who choose to have the extra menus.
If it were my decision alone, I would move the zoom 1px commands and the
save/restore cursor position. I'd move some others too, IF the extra

menus,

Post by James Crook
once enabled, are convenient for VI users. It is, or will be, a group
decision though, as was the decision to elevate 'select' to a new top

level

Post by James Crook
menu.
Mainly I want to establish whether the extra-menus idea itself is a net

win.

Post by James Crook
If it is not good at all for VI users, it is back to the drawing board on
that idea for how to make things work well for both sighted and VI users.
--James.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------

------------------

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

------------------

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

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

[James Crook]

Post by David Bailes
https://github.com/audacity/audacity/commit/592453082bee5fbca271405304c124638a341d85
David.

Meanwhile I have organised the 'occult' commands, the ones that can have
key bindings but that do not normally appear in the menus.

The occult commands can be revealed by using view->Extra-Menus. They
then appear in two extra menus after 'Help'.

So we now have a mechanism to make extra menu items visible/available.

--James.

[Gale Andrews]

Post by David Bailes
https://github.com/audacity/audacity/commit/592453082bee5fbca271405304c124638a341d85
David.

Thanks, David. I look forward to further developments for some
kind of Step Size feature, wherever it goes. I think the idea was
right, but not presented as zoom presets.


Gale

[James Crook]

Post by Gale Andrews

Post by David Bailes
https://github.com/audacity/audacity/commit/592453082bee5fbca271405304c124638a341d85
David.

Thanks, David. I look forward to further developments for some
kind of Step Size feature, wherever it goes. I think the idea was
right, but not presented as zoom presets.

+1

I think it would be OK to make the selection toolbar longer, with an
extra setting for step-size.
Then there could be menu presets to set the step size. And the step
size would affect cursor left/right and selection extend/contract
left/right, short seek left/right. Possibly the play before/after times
too.

--James.

[Gale Andrews]

Post by James Crook

Post by David Bailes
https://github.com/audacity/audacity/commit/592453082bee5fbca271405304c124638a341d85
David.

Meanwhile I have organised the 'occult' commands, the ones that can have
key bindings but that do not normally appear in the menus.
The occult commands can be revealed by using view->Extra-Menus. They
then appear in two extra menus after 'Help'.
So we now have a mechanism to make extra menu items visible/available.

Thanks, James.

I only tested on Windows 10 so far. The interaction of the
View menu item for extra menus with its Preference control
and the operation of the menu items, updating their shortcuts
properly, seems fine there.

I wondered in Ext-Command if the Track group should come
after Focus, which would group the focus commands one
after the other.

Of course when the extra items are settled they will have to be
kitted out with access keys. Getting to them is a long haul now by
keyboard.



Gale

[James Crook]

Post by Gale Andrews

Post by James Crook

Post by David Bailes
https://github.com/audacity/audacity/commit/592453082bee5fbca271405304c124638a341d85
David.

Meanwhile I have organised the 'occult' commands, the ones that can have
key bindings but that do not normally appear in the menus.
The occult commands can be revealed by using view->Extra-Menus. They
then appear in two extra menus after 'Help'.
So we now have a mechanism to make extra menu items visible/available.

Thanks, James.
I only tested on Windows 10 so far. The interaction of the
View menu item for extra menus with its Preference control
and the operation of the menu items, updating their shortcuts
properly, seems fine there.
I wondered in Ext-Command if the Track group should come
after Focus, which would group the focus commands one
after the other.

I'm leaving it where it is for the moment.
My thinking is that the cursor is a kind of 'micro focus'.

So the first two groups are selecting some kind of focus.
And the last group is doing something with a (track) focus.

We could swap cursor and focus and get adjacency for both, but I think
'Focus' deserves to be top.

Post by Gale Andrews
Of course when the extra items are settled they will have to be
kitted out with access keys. Getting to them is a long haul now by
keyboard.

Yes. And thanks for your work on other access keys.

Access keys to the two top-level Ext items would go a long way towards
reducing the long-haul journey.

--James.

[Gale Andrews]

Windows 10 x64 release build.

I've updated to:
https://github.com/audacity/audacity/commit/a68f7fc1

but still crash when using Ext-Command > Cursor > Cursor Left or
Cursor Right in a generated mono tone. I was assuming that commit
was in response to the crash.

Audacity.xml in the debug report has the below.


Gale

<stack>
<frame level="0" function="AudacityProject::OnCursorLeft"
offset="00000016"/>
<frame level="1" function="AudacityProject::OnCursorMove"
offset="000009f3"/>
<frame level="2" function="CommandManager::HandleCommandEntry"
offset="0000009d"/>
<frame level="3" function="CommandManager::HandleMenuID" offset="0000005e"/>
<frame level="4" function="AudacityProject::OnMenu" offset="0000002b"/>
<frame level="5" function="wxAppConsoleBase::HandleEvent"
offset="0000000f"/>
<frame level="6" function="wxAppConsoleBase::CallEventHandler"
offset="00000027"/>
<frame level="7" function="wxEvtHandler::ProcessEventIfMatchesId"
offset="00000052"/>
<frame level="8" function="wxEventHashTable::HandleEvent"
offset="00000056"/>
<frame level="9" function="wxEvtHandler::TryHereOnly" offset="00000037"/>
<frame level="10" function="wxEvtHandler::ProcessEvent" offset="00000051"/>
<frame level="11" function="wxEvtHandler::DoTryChain" offset="0000004f"/>
<frame level="12" function="wxEvtHandler::ProcessEvent" offset="00000092"/>
<frame level="13" function="wxWindowBase::TryAfter" offset="00000071"/>
<frame level="14" function="wxEvtHandler::ProcessEvent" offset="000000a0"/>
<frame level="15" function="wxEvtHandler::SafelyProcessEvent"
offset="0000003a"/>
<frame level="16" function="wxMenuBase::SendEvent" offset="000000b6"/>
<frame level="17" function="wxFrameBase::ProcessCommand" offset="00000072"/>
<frame level="18" function="wxFrame::HandleCommand" offset="0000003d"/>
<frame level="19" function="wxFrame::MSWWindowProc" offset="00000107"/>
<frame level="20" function="wxWndProc" offset="0000009a"/>
<frame level="21" function="AddClipboardFormatListener" offset="0000126b"/>
<frame level="22" function="DispatchMessageW" offset="000008b3"/>
<frame level="23" function="DispatchMessageW" offset="00000242"/>
<frame level="24" function="DispatchMessageW" offset="00000010"/>
<frame level="25" function="wxGUIEventLoop::ProcessMessage"
offset="00000021"/>
<frame level="26" function="wxGUIEventLoop::Dispatch" offset="00000184"/>
<frame level="27" function="wxEventLoopManual::DoRun" offset="0000006d"/>
<frame level="28" function="wxEventLoopBase::Run" offset="0000007f"/>
<frame level="29" function="wxAppConsoleBase::MainLoop" offset="00000085"/>
<frame level="30" function="wxEntryCleanup" offset="0000015d"/>
<frame level="31" function="wxEntry" offset="00000053"/>
<frame level="32" function="wxEntry" offset="00000084"/>
<frame level="33" function="AutoSaveFile::`default constructor
closure'" offset="00000c3a"/>
<frame level="34"
function="SimpleBlockFile::GetNeedWriteCacheToDisk"
offset="001cdf77"/>
<frame level="35" function="BaseThreadInitThunk" offset="00000024"/>
<frame level="36" function="RtlGetAppContainerNamedObjectPath"
offset="000000fd"/>
<frame level="37" function="RtlGetAppContainerNamedObjectPath"
offset="000000cd"/>
</stack>

Post by James Crook

Post by Gale Andrews

Post by James Crook

Post by David Bailes
https://github.com/audacity/audacity/commit/592453082bee5fbca271405304c124638a341d85
David.

Meanwhile I have organised the 'occult' commands, the ones that can have
key bindings but that do not normally appear in the menus.
The occult commands can be revealed by using view->Extra-Menus. They
then appear in two extra menus after 'Help'.
So we now have a mechanism to make extra menu items visible/available.

Thanks, James.
I only tested on Windows 10 so far. The interaction of the
View menu item for extra menus with its Preference control
and the operation of the menu items, updating their shortcuts
properly, seems fine there.
I wondered in Ext-Command if the Track group should come
after Focus, which would group the focus commands one
after the other.

I'm leaving it where it is for the moment.
My thinking is that the cursor is a kind of 'micro focus'.
So the first two groups are selecting some kind of focus.
And the last group is doing something with a (track) focus.
We could swap cursor and focus and get adjacency for both, but I think
'Focus' deserves to be top.

Post by Gale Andrews
Of course when the extra items are settled they will have to be
kitted out with access keys. Getting to them is a long haul now by
keyboard.

Yes. And thanks for your work on other access keys.
Access keys to the two top-level Ext items would go a long way towards
reducing the long-haul journey.
--James.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[James Crook]

Thanks Gale. I missed two commands which do that.
Fixed at
https://github.com/audacity/audacity/commit/218f2ebb8d9eb4ec11916eb1119a13c58c829fab

--James.

Post by Gale Andrews
Windows 10 x64 release build.
https://github.com/audacity/audacity/commit/a68f7fc1
but still crash when using Ext-Command > Cursor > Cursor Left or
Cursor Right in a generated mono tone. I was assuming that commit
was in response to the crash.
Audacity.xml in the debug report has the below.
Gale
<stack>
<frame level="0" function="AudacityProject::OnCursorLeft"
offset="00000016"/>
<frame level="1" function="AudacityProject::OnCursorMove"
offset="000009f3"/>
<frame level="2" function="CommandManager::HandleCommandEntry"
offset="0000009d"/>
<frame level="3" function="CommandManager::HandleMenuID" offset="0000005e"/>
<frame level="4" function="AudacityProject::OnMenu" offset="0000002b"/>
<frame level="5" function="wxAppConsoleBase::HandleEvent"
offset="0000000f"/>
<frame level="6" function="wxAppConsoleBase::CallEventHandler"
offset="00000027"/>
<frame level="7" function="wxEvtHandler::ProcessEventIfMatchesId"
offset="00000052"/>
<frame level="8" function="wxEventHashTable::HandleEvent"
offset="00000056"/>
<frame level="9" function="wxEvtHandler::TryHereOnly" offset="00000037"/>
<frame level="10" function="wxEvtHandler::ProcessEvent" offset="00000051"/>
<frame level="11" function="wxEvtHandler::DoTryChain" offset="0000004f"/>
<frame level="12" function="wxEvtHandler::ProcessEvent" offset="00000092"/>
<frame level="13" function="wxWindowBase::TryAfter" offset="00000071"/>
<frame level="14" function="wxEvtHandler::ProcessEvent" offset="000000a0"/>
<frame level="15" function="wxEvtHandler::SafelyProcessEvent"
offset="0000003a"/>
<frame level="16" function="wxMenuBase::SendEvent" offset="000000b6"/>
<frame level="17" function="wxFrameBase::ProcessCommand" offset="00000072"/>
<frame level="18" function="wxFrame::HandleCommand" offset="0000003d"/>
<frame level="19" function="wxFrame::MSWWindowProc" offset="00000107"/>
<frame level="20" function="wxWndProc" offset="0000009a"/>
<frame level="21" function="AddClipboardFormatListener" offset="0000126b"/>
<frame level="22" function="DispatchMessageW" offset="000008b3"/>
<frame level="23" function="DispatchMessageW" offset="00000242"/>
<frame level="24" function="DispatchMessageW" offset="00000010"/>
<frame level="25" function="wxGUIEventLoop::ProcessMessage"
offset="00000021"/>
<frame level="26" function="wxGUIEventLoop::Dispatch" offset="00000184"/>
<frame level="27" function="wxEventLoopManual::DoRun" offset="0000006d"/>
<frame level="28" function="wxEventLoopBase::Run" offset="0000007f"/>
<frame level="29" function="wxAppConsoleBase::MainLoop" offset="00000085"/>
<frame level="30" function="wxEntryCleanup" offset="0000015d"/>
<frame level="31" function="wxEntry" offset="00000053"/>
<frame level="32" function="wxEntry" offset="00000084"/>
<frame level="33" function="AutoSaveFile::`default constructor
closure'" offset="00000c3a"/>
<frame level="34"
function="SimpleBlockFile::GetNeedWriteCacheToDisk"
offset="001cdf77"/>
<frame level="35" function="BaseThreadInitThunk" offset="00000024"/>
<frame level="36" function="RtlGetAppContainerNamedObjectPath"
offset="000000fd"/>
<frame level="37" function="RtlGetAppContainerNamedObjectPath"
offset="000000cd"/>
</stack>

Post by James Crook

Post by Gale Andrews

Post by James Crook

Post by David Bailes
https://github.com/audacity/audacity/commit/592453082bee5fbca271405304c124638a341d85
David.

Meanwhile I have organised the 'occult' commands, the ones that can have
key bindings but that do not normally appear in the menus.
The occult commands can be revealed by using view->Extra-Menus. They
then appear in two extra menus after 'Help'.
So we now have a mechanism to make extra menu items visible/available.

Thanks, James.
I only tested on Windows 10 so far. The interaction of the
View menu item for extra menus with its Preference control
and the operation of the menu items, updating their shortcuts
properly, seems fine there.
I wondered in Ext-Command if the Track group should come
after Focus, which would group the focus commands one
after the other.

I'm leaving it where it is for the moment.
My thinking is that the cursor is a kind of 'micro focus'.
So the first two groups are selecting some kind of focus.
And the last group is doing something with a (track) focus.
We could swap cursor and focus and get adjacency for both, but I think
'Focus' deserves to be top.

Post by Gale Andrews
Of course when the extra items are settled they will have to be
kitted out with access keys. Getting to them is a long haul now by
keyboard.

Yes. And thanks for your work on other access keys.
Access keys to the two top-level Ext items would go a long way towards
reducing the long-haul journey.
--James.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

[David Bailes]

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the page
http://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)

which commands are these?

thanks,
David.

Post by James Crook
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[James Crook]

Post by David Bailes

Post by James Crook
There are many keyboard-bindable commands that are not in our menus.
You can find them at the end of the table in
Edit->Preferences->Keyboard, when you view 'by tree'.
They are shown as belonging to a menu called 'Command'.
The commands which are bound by default are also listed in the manual,
in tables at the end of the page
http://alphamanual.audacityteam.org/man/Keyboard_Shortcut_Reference
Device Toolbar, Mixer Toolbar, Selection Toolbar, Tools Toolbar,
Keyboard Focus.
I'm proposing a new preference, 'Show Extra Menus' (off by default) and
to do this for 2.2.0.
When it is enabled, extra top level menus will appear, and ALL remaining
bindable commands will be available from them. These new top level
* Extra-Bar (with the 4 toolbar submenus)
* Extra-Focus (with current focus commands, and likely some more in time)

which commands are these?

Change Audio Host SHIFT + H
Change Playback Device SHIFT + O
Change Recording Device SHIFT + I
Change Recording Channels SHIFT + N

Adjust Playback Volume (User-assigned)
Increase Playback Volume (User-assigned)
Decrease Playback Volume (User-assigned)
Adjust Recording Volume (User-assigned)
Increase Recording Volume (User-assigned)
Decrease Recording Volume (User-assigned)

Snap To Off (User-assigned)
Snap To Nearest (User-assigned)
Snap To Prior (User-assigned)

Selection Tool F1
Envelope Tool F2
Draw Tool F3
Zoom Tool F4
Time Shift Tool F5
Multi-Tool F6
Next Tool D
Previous Tool A

Move backward through currently focused toolbar in Upper Toolbar dock
area, Track View and currently focused toolbar in Lower Toolbar dock
area CTRL + SHIFT + F6
Move forward through currently focused toolbar in Upper Toolbar dock
area, Track View and currently focused toolbar in Lower Toolbar dock
area CTRL + F6
Move backward through modeless windows, undocked Toolbars and the main
project window ALT + SHIFT + F6
Move forward through modeless windows, undocked Toolbars and the main
project window ALT + F6

Post by David Bailes
thanks,
David.

Post by James Crook
* Extra-Command (with everything else that does not have a logical place)
This way, commands which are useful to VI users but that get in the way
for new users can still be as accessible for VI users as normal menu
commands are. This has some other advantages too.
* It becomes easier to regenerate tables of commands.
* The keyboard preferences dialog becomes a little clearer about what
the commands do.
* When later we come to have a menu rearrangement too, it means fewer
'special cases' for the code that rearranges menus.
The possible downside is that VI users may prefer to have some of the
Extra-Command menu items in one of the existing main menu categories.
I'd suggest that argues for the importance of a future tool to rearrange
menus - especially effects.
What do people think? Are the proposed new menus and the 'extra menus'
preference a good idea?
--James.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

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