Quantcast

Extra menus for VI (and other) use?

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

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.








------------------------------------------------------------------------------
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: Extra menus for VI (and other) use?

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


On 20 April 2017 at 09:48, James Crook <[hidden email]> wrote:

> 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.
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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: Extra menus for VI (and other) use?

James Crook
On 4/20/2017 5:22 PM, Gale Andrews wrote:

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

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

>
>
> Gale
>
>
> On 20 April 2017 at 09:48, James Crook <[hidden email]> wrote:
>> 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.
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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: Extra menus for VI (and other) use?

David Bailes-3
In reply to this post by James Crook
On Thu, Apr 20, 2017 at 9:48 AM, James Crook <[hidden email]> wrote:
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.

Can you list the commands that you are proposing moving from the existing menus into the new menus?
thanks,
David.
 
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
[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: Extra menus for VI (and other) use?

David Bailes-3
In reply to this post by James Crook
On Thu, Apr 20, 2017 at 9:48 AM, James Crook <[hidden email]> wrote:
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)

which commands are these?

thanks,
David.
 
* 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
[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: Extra menus for VI (and other) use?

Gale
Administrator
In reply to this post by James Crook
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


On 20 April 2017 at 17:46, James Crook <[hidden email]> wrote:

> On 4/20/2017 5:22 PM, Gale Andrews wrote:
>> 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.
>
>> 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.
>
>>
>>
>> Gale
>>
>>
>> On 20 April 2017 at 09:48, James Crook <[hidden email]> wrote:
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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: Extra menus for VI (and other) use?

James Crook
In reply to this post by David Bailes-3
On 4/20/2017 6:40 PM, David Bailes wrote:
On Thu, Apr 20, 2017 at 9:48 AM, James Crook [hidden email] wrote:

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)

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   




thanks,
David.


* 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
[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: Extra menus for VI (and other) use?

James Crook
In reply to this post by David Bailes-3
On 4/20/2017 6:37 PM, David Bailes wrote:
On Thu, Apr 20, 2017 at 9:48 AM, James Crook [hidden email] wrote:

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.

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
[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: Extra menus for VI (and other) use?

David Bailes-3
On Thu, Apr 20, 2017 at 7:36 PM, James Crook <[hidden email]> wrote:
On 4/20/2017 6:37 PM, David Bailes wrote:
On Thu, Apr 20, 2017 at 9:48 AM, James Crook [hidden email] wrote:

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.

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.
 
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
[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: Extra menus for VI (and other) use?

David Bailes-3
In reply to this post by James Crook
On Thu, Apr 20, 2017 at 7:36 PM, James Crook <[hidden email]> wrote:
On 4/20/2017 6:37 PM, David Bailes wrote:
On Thu, Apr 20, 2017 at 9:48 AM, James Crook [hidden email] wrote:

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.

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.
 
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
[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: Extra menus for VI (and other) use?

David Bailes-3
In reply to this post by David Bailes-3
On Thu, Apr 20, 2017 at 8:05 PM, David Bailes <[hidden email]> wrote:
On Thu, Apr 20, 2017 at 7:36 PM, James Crook <[hidden email]> wrote:
On 4/20/2017 6:37 PM, David Bailes wrote:
On Thu, Apr 20, 2017 at 9:48 AM, James Crook [hidden email] wrote:

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.

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.
 

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 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: Extra menus for VI (and other) use?

James Crook
In reply to this post by David Bailes-3
On 4/20/2017 8:08 PM, David Bailes wrote:
On Thu, Apr 20, 2017 at 7:36 PM, James Crook [hidden email] wrote:

On 4/20/2017 6:37 PM, David Bailes wrote:

On Thu, Apr 20, 2017 at 9:48 AM, James Crook [hidden email] [hidden email] wrote:


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

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.


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.




David.


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 [hidden email]



------------------------------------------------------------------------------
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 [hidden email]



------------------------------------------------------------
------------------
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: Extra menus for VI (and other) use?

Gale
Administrator
In reply to this post by James Crook
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


On 20 April 2017 at 19:36, James Crook <[hidden email]> wrote:

> On 4/20/2017 6:37 PM, David Bailes wrote:
>
> On Thu, Apr 20, 2017 at 9:48 AM, James Crook <[hidden email]> wrote:
>
> 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.
>
> 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
> [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: Extra menus for VI (and other) use?

James Crook
In reply to this post by David Bailes-3
On 4/20/2017 8:31 PM, David Bailes wrote:
On Thu, Apr 20, 2017 at 8:05 PM, David Bailes [hidden email] wrote:

On Thu, Apr 20, 2017 at 7:36 PM, James Crook [hidden email] wrote:

On 4/20/2017 6:37 PM, David Bailes wrote:

On Thu, Apr 20, 2017 at 9:48 AM, James Crook [hidden email] [hidden email] wrote:


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

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.


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 [hidden email]



------------------------------------------------------------------------------
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 [hidden email]



------------------------------------------------------------
------------------
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: Extra menus for VI (and other) use?

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


On 20 April 2017 at 21:19, James Crook <[hidden email]> wrote:

> On 4/20/2017 8:31 PM, David Bailes wrote:
>
> On Thu, Apr 20, 2017 at 8:05 PM, David Bailes <[hidden email]> wrote:
>
> On Thu, Apr 20, 2017 at 7:36 PM, James Crook <[hidden email]> wrote:
>
> On 4/20/2017 6:37 PM, David Bailes wrote:
>
> On Thu, Apr 20, 2017 at 9:48 AM, James Crook <[hidden email]>
> <[hidden email]> wrote:
>
>
> 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
>
> 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.
>
>
> 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
> [hidden email]://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
> [hidden email]://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
>

------------------------------------------------------------------------------
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: Extra menus for VI (and other) use?

Peter Sampson-2
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.

------------------------------------------------------------------------------
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: Extra menus for VI (and other) use?

David Bailes-3
In reply to this post by Gale
On Thu, Apr 20, 2017 at 9:19 PM, Gale Andrews <[hidden email]> wrote:
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:

David.
 


Gale


On 20 April 2017 at 19:36, James Crook <[hidden email]> wrote:
> On 4/20/2017 6:37 PM, David Bailes wrote:
>
> On Thu, Apr 20, 2017 at 9:48 AM, James Crook <[hidden email]> wrote:
>
> 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.
>
> 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
> [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


------------------------------------------------------------------------------
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: Extra menus for VI (and other) use?

James Crook
In reply to this post by Peter Sampson-2
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.



On 4/21/2017 3:03 PM, Peter Sampson wrote:
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.



------------------------------------------------------------------------------
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: Extra menus for VI (and other) use?

Peter Sampson-2


On Fri, Apr 21, 2017 at 4:19 PM, James Crook <[hidden email]> wrote:
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.




On 4/21/2017 3:03 PM, Peter Sampson wrote:
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.



------------------------------------------------------------------------------
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: Extra menus for VI (and other) use?

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

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