Quantcast

Panel-Nav Shortcuts in Menus.

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

Panel-Nav Shortcuts in Menus.

James Crook
TL;DR;

What rating would the 'Panel navigation accelerators don't appear in the
menus' bug have?
Is its rating affected by whether we have Ext-Menus?



Details:

We currently have a workaround implemented for what is actually an old bug.

Panel navigation keys, Left-Arrow, Right-Arrow and Enter IF they appear
in menus bound to our commands 'trump' navigation in the docked
toolbars.  I.e. you can no longer use them to navigate in those panels.  
Our/my workaround is to not show them there, if they are so bound.  
That's unarguably a bug.  We would like them to show there.

This is discussed in:

http://bugzilla.audacityteam.org/show_bug.cgi?id=1637
Bug 1637 - Keyboard interaction with many controls in toolbars broken

http://bugzilla.audacityteam.org/show_bug.cgi?id=1639
Bug 1639 - Panel navigation keys don't work in docked toolbars, if bound
to some action


I believe my workaround largely addresses the P1 bug, 1637.  I think the
non appearance of arrow keys and enter in menus is no more than P3.  If
we kill the feature of showing Ext-Menus, one of the claimed benefits of
which is to familiarise people more easily with the shortcuts, then it
could be as low as P4 as we are no worse of than for 2.1.3.  and we have
had no reports of this binding issue in many years of use of Audacity.

A proper fix (to excluding these accelerators from display) entails
fixing a bug in wxWidgets,
http://wxwidgets.10942.n7.nabble.com/Disabling-Menu-Accelerators-td83700.html 
and a nasty hack in adding/removing accelerators that works around a
Windows built in behaviour.  There is an alternative approach/hack which
separates the docks from the track panel completely.  Flags to stop
event propagation are not enough, I tried.  Then Docks would then behave
like the frames holding floating toolbars and prevent events reaching
the menu bar.  That could entail nasty code to move the dock with the
parent window, when the Audacity project window moves or is resized, so
the docks continue to appear to be parented by the project window even
though they aren't.  I don't intend to do either of these 'fixes' myself
as I think they are more problem than they are worth.

Yet another fix/hack is to rebuild the menus (with proper accelerators)
when a user clicks to open the menus.  That would be awfully hacky too,
I think and likely would have different issues on Mac/Windows/Linux.

I've tried other approaches, like adding " Left" rather than "Left" as a
menu accelerator.  It displays exactly the same, but the space kills the
acceleration and makes it invalid. Unfortunately invalid accelerator
strings mess up the event system so it does not actually fix the issue.


My preferred option is that we continue with the current fix of hiding
the few problematic accelerators when they are in menus. If that is a P2
bug, I'd argue we can reduce it to P3 by NOT providing the Ext-Menu
feature.  If it is P3 already, then we release note it and don't have to
do more than that for 2.2.0.


--James.





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Panel-Nav Shortcuts in Menus.

Robert Hänggi
Hi James

My opinion is that there should be a framework for capturing all key
(and mouse) events happening in the tool docks/floating toolbars.

This allows for additional commands.
For instance, we could define that holding "Shift" in the selection
toolbar swaps to "Clip mode" and arrowing up and down in the selection
start control (while still pressing the modifier key) would shift a
clip, rather than define the start time of it.

The problematic keys include also numbers: it is for instance not
possible to enter a project rate that has a "1" in it because this
plays a one second preview.

Also, some keys would better be propagated to the track panel if no
special event/function is defined for the control with focus:
It is not possible to jump to the beginning of a track by simply
pressing "j" while the focus is in e.g. the selection start.

I'm personally not very fond of navigating toolbars with arrow
keys--it will only work with buttons, lists, radio buttons input
fields and so on will trap Left/Right.

There's another idea that strikes me: why not extend the acceleration
system to toolbars as well, example:
(assuming the "menu for toolbars would be "O")
Alt+OSE would bring you to the selection End/Length control.

The current combination is:
Control+F6
Tab
Tab
Tab

And that's a modest example, try to reach the playback meter with  the
default toolbars enabled: around 11 keystrokes are necessary.

Of course, I'm speaking of the first time usage in a new session,
after that the last control focus will be remembered.

Robert

On 06/05/2017, James Crook <[hidden email]> wrote:

> TL;DR;
>
> What rating would the 'Panel navigation accelerators don't appear in the
> menus' bug have?
> Is its rating affected by whether we have Ext-Menus?
>
>
>
> Details:
>
> We currently have a workaround implemented for what is actually an old bug.
>
> Panel navigation keys, Left-Arrow, Right-Arrow and Enter IF they appear
> in menus bound to our commands 'trump' navigation in the docked
> toolbars.  I.e. you can no longer use them to navigate in those panels.
> Our/my workaround is to not show them there, if they are so bound.
> That's unarguably a bug.  We would like them to show there.
>
> This is discussed in:
>
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1637
> Bug 1637 - Keyboard interaction with many controls in toolbars broken
>
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1639
> Bug 1639 - Panel navigation keys don't work in docked toolbars, if bound
> to some action
>
>
> I believe my workaround largely addresses the P1 bug, 1637.  I think the
> non appearance of arrow keys and enter in menus is no more than P3.  If
> we kill the feature of showing Ext-Menus, one of the claimed benefits of
> which is to familiarise people more easily with the shortcuts, then it
> could be as low as P4 as we are no worse of than for 2.1.3.  and we have
> had no reports of this binding issue in many years of use of Audacity.
>
> A proper fix (to excluding these accelerators from display) entails
> fixing a bug in wxWidgets,
> http://wxwidgets.10942.n7.nabble.com/Disabling-Menu-Accelerators-td83700.html
>
> and a nasty hack in adding/removing accelerators that works around a
> Windows built in behaviour.  There is an alternative approach/hack which
> separates the docks from the track panel completely.  Flags to stop
> event propagation are not enough, I tried.  Then Docks would then behave
> like the frames holding floating toolbars and prevent events reaching
> the menu bar.  That could entail nasty code to move the dock with the
> parent window, when the Audacity project window moves or is resized, so
> the docks continue to appear to be parented by the project window even
> though they aren't.  I don't intend to do either of these 'fixes' myself
> as I think they are more problem than they are worth.
>
> Yet another fix/hack is to rebuild the menus (with proper accelerators)
> when a user clicks to open the menus.  That would be awfully hacky too,
> I think and likely would have different issues on Mac/Windows/Linux.
>
> I've tried other approaches, like adding " Left" rather than "Left" as a
> menu accelerator.  It displays exactly the same, but the space kills the
> acceleration and makes it invalid. Unfortunately invalid accelerator
> strings mess up the event system so it does not actually fix the issue.
>
>
> My preferred option is that we continue with the current fix of hiding
> the few problematic accelerators when they are in menus. If that is a P2
> bug, I'd argue we can reduce it to P3 by NOT providing the Ext-Menu
> feature.  If it is P3 already, then we release note it and don't have to
> do more than that for 2.2.0.
>
>
> --James.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Panel-Nav Shortcuts in Menus.

James Crook
On 5/6/2017 1:09 PM, Robert Hänggi wrote:
> Hi James
>
> My opinion is that there should be a framework for capturing all key
> (and mouse) events happening in the tool docks/floating toolbars.
Hmm.  Well there IS such a framework.  It is just its design seems to be
'wrong'.

Commands are handled (1) by our custom controls first, then (2) by our
'command handler' (which has all keyboard bindings we define) then
handed on to wxWidgets.  wxWidgets then hands stuff on to windows, which
does (3) menu bar before it does (4) windows controls.

The 'correct' order for us is (1), (4), (2), (3).  Unfortunately the way
wxWidgets is written seems to force us to do (3) and then (4) as the
last two steps.  I finagled it by modifying step (2) so that our command
handler only catches the panel navigation commands if track panel has
focus, rather than some smaller windows control.  That way panel
navigation that we want to go to (4) gets through step (2).  I finagled
step (3) by removing panel navigation keys from menu accelerators.  That
way those keys get through both (2) and (3) and end up at (4) ,which is
where we wanted them.



> This allows for additional commands.
> For instance, we could define that holding "Shift" in the selection
> toolbar swaps to "Clip mode" and arrowing up and down in the selection
> start control (while still pressing the modifier key) would shift a
> clip, rather than define the start time of it.
>
> The problematic keys include also numbers: it is for instance not
> possible to enter a project rate that has a "1" in it because this
> plays a one second preview.
Thanks yes.  Hadn't spotted that.  I believe it is only a problem for
the project rate, which is for step (4).  It isn't a problem for the
start/end controls which are ours, and are captured in step (1).  So one
solution would be to change the project rate control to 'be' a variant
of our custom start/end controls.

> Also, some keys would better be propagated to the track panel if no
> special event/function is defined for the control with focus:
> It is not possible to jump to the beginning of a track by simply
> pressing "j" while the focus is in e.g. the selection start.
It seems we are catching too much in step (1) and that could be fixed.

> I'm personally not very fond of navigating toolbars with arrow
> keys--it will only work with buttons, lists, radio buttons input
> fields and so on will trap Left/Right.
I'm not keen on it either, as I navigate by clicking with the mouse.

> There's another idea that strikes me: why not extend the acceleration
> system to toolbars as well, example:
> (assuming the "menu for toolbars would be "O")
> Alt+OSE would bring you to the selection End/Length control.
I think Ext-Menu commands for shortcuts to the toolbars would be good.  
Bindings for these could be added by the user.
I'm not keen on more default bindings.  I'd rather we offered an
optional vibindings.xml that was more complete than our standard bindings.

I'm not keen on the 'SE' extension idea.  I think it gains not very much
over the shortcut to the toolbar.  How do we know 'S' is not for
Snap-To?  I'd be fine with rearranging the toolbar so that the most used
fields were first.

> The current combination is:
> Control+F6
> Tab
> Tab
> Tab
>
> And that's a modest example, try to reach the playback meter with  the
> default toolbars enabled: around 11 keystrokes are necessary.
>
> Of course, I'm speaking of the first time usage in a new session,
> after that the last control focus will be remembered.


--James.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Panel-Nav Shortcuts in Menus.

David Bailes-3
On Sat, May 6, 2017 at 3:16 PM, James Crook <[hidden email]> wrote:
On 5/6/2017 1:09 PM, Robert Hänggi wrote:
> Hi James
>
> My opinion is that there should be a framework for capturing all key
> (and mouse) events happening in the tool docks/floating toolbars.
Hmm.  Well there IS such a framework.  It is just its design seems to be
'wrong'.

Commands are handled (1) by our custom controls first, then (2) by our
'command handler' (which has all keyboard bindings we define) then
handed on to wxWidgets.  wxWidgets then hands stuff on to windows, which
does (3) menu bar before it does (4) windows controls.

One possibility might be for the toolbars to call AudacityProject::CaptureKeyboard(this), rather than our custom controls (I see that some do, but I'm not sure whether this is a hangover from previous ways of handling keyboard events). The toolbars would then be responsible for forwarding keyboard events to the focused control, and dealing with navigation. Note, this is just an idea, which I haven't thought through. Maybe Leland would have some ideas?

David.
 

The 'correct' order for us is (1), (4), (2), (3).  Unfortunately the way
wxWidgets is written seems to force us to do (3) and then (4) as the
last two steps.  I finagled it by modifying step (2) so that our command
handler only catches the panel navigation commands if track panel has
focus, rather than some smaller windows control.  That way panel
navigation that we want to go to (4) gets through step (2).  I finagled
step (3) by removing panel navigation keys from menu accelerators.  That
way those keys get through both (2) and (3) and end up at (4) ,which is
where we wanted them.



> This allows for additional commands.
> For instance, we could define that holding "Shift" in the selection
> toolbar swaps to "Clip mode" and arrowing up and down in the selection
> start control (while still pressing the modifier key) would shift a
> clip, rather than define the start time of it.
>
> The problematic keys include also numbers: it is for instance not
> possible to enter a project rate that has a "1" in it because this
> plays a one second preview.
Thanks yes.  Hadn't spotted that.  I believe it is only a problem for
the project rate, which is for step (4).  It isn't a problem for the
start/end controls which are ours, and are captured in step (1).  So one
solution would be to change the project rate control to 'be' a variant
of our custom start/end controls.

> Also, some keys would better be propagated to the track panel if no
> special event/function is defined for the control with focus:
> It is not possible to jump to the beginning of a track by simply
> pressing "j" while the focus is in e.g. the selection start.
It seems we are catching too much in step (1) and that could be fixed.

> I'm personally not very fond of navigating toolbars with arrow
> keys--it will only work with buttons, lists, radio buttons input
> fields and so on will trap Left/Right.
I'm not keen on it either, as I navigate by clicking with the mouse.

> There's another idea that strikes me: why not extend the acceleration
> system to toolbars as well, example:
> (assuming the "menu for toolbars would be "O")
> Alt+OSE would bring you to the selection End/Length control.
I think Ext-Menu commands for shortcuts to the toolbars would be good.
Bindings for these could be added by the user.
I'm not keen on more default bindings.  I'd rather we offered an
optional vibindings.xml that was more complete than our standard bindings.

I'm not keen on the 'SE' extension idea.  I think it gains not very much
over the shortcut to the toolbar.  How do we know 'S' is not for
Snap-To?  I'd be fine with rearranging the toolbar so that the most used
fields were first.

> The current combination is:
> Control+F6
> Tab
> Tab
> Tab
>
> And that's a modest example, try to reach the playback meter with  the
> default toolbars enabled: around 11 keystrokes are necessary.
>
> Of course, I'm speaking of the first time usage in a new session,
> after that the last control focus will be remembered.


--James.

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


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Panel-Nav Shortcuts in Menus.

David Bailes-3
In reply to this post by Robert Hänggi
On Sat, May 6, 2017 at 1:09 PM, Robert Hänggi <[hidden email]> wrote:
Hi James

My opinion is that there should be a framework for capturing all key
(and mouse) events happening in the tool docks/floating toolbars.

This allows for additional commands.
For instance, we could define that holding "Shift" in the selection
toolbar swaps to "Clip mode" and arrowing up and down in the selection
start control (while still pressing the modifier key) would shift a
clip, rather than define the start time of it.

The problematic keys include also numbers: it is for instance not
possible to enter a project rate that has a "1" in it because this
plays a one second preview.

Also, some keys would better be propagated to the track panel if no
special event/function is defined for the control with focus:
It is not possible to jump to the beginning of a track by simply
pressing "j" while the focus is in e.g. the selection start.

Pressing J works here when selection start is the focus,

David. 

I'm personally not very fond of navigating toolbars with arrow
keys--it will only work with buttons, lists, radio buttons input
fields and so on will trap Left/Right.

There's another idea that strikes me: why not extend the acceleration
system to toolbars as well, example:
(assuming the "menu for toolbars would be "O")
Alt+OSE would bring you to the selection End/Length control.

The current combination is:
Control+F6
Tab
Tab
Tab

And that's a modest example, try to reach the playback meter with  the
default toolbars enabled: around 11 keystrokes are necessary.

Of course, I'm speaking of the first time usage in a new session,
after that the last control focus will be remembered.

Robert

On 06/05/2017, James Crook <[hidden email]> wrote:
> TL;DR;
>
> What rating would the 'Panel navigation accelerators don't appear in the
> menus' bug have?
> Is its rating affected by whether we have Ext-Menus?
>
>
>
> Details:
>
> We currently have a workaround implemented for what is actually an old bug.
>
> Panel navigation keys, Left-Arrow, Right-Arrow and Enter IF they appear
> in menus bound to our commands 'trump' navigation in the docked
> toolbars.  I.e. you can no longer use them to navigate in those panels.
> Our/my workaround is to not show them there, if they are so bound.
> That's unarguably a bug.  We would like them to show there.
>
> This is discussed in:
>
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1637
> Bug 1637 - Keyboard interaction with many controls in toolbars broken
>
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1639
> Bug 1639 - Panel navigation keys don't work in docked toolbars, if bound
> to some action
>
>
> I believe my workaround largely addresses the P1 bug, 1637.  I think the
> non appearance of arrow keys and enter in menus is no more than P3.  If
> we kill the feature of showing Ext-Menus, one of the claimed benefits of
> which is to familiarise people more easily with the shortcuts, then it
> could be as low as P4 as we are no worse of than for 2.1.3.  and we have
> had no reports of this binding issue in many years of use of Audacity.
>
> A proper fix (to excluding these accelerators from display) entails
> fixing a bug in wxWidgets,
> http://wxwidgets.10942.n7.nabble.com/Disabling-Menu-Accelerators-td83700.html
>
> and a nasty hack in adding/removing accelerators that works around a
> Windows built in behaviour.  There is an alternative approach/hack which
> separates the docks from the track panel completely.  Flags to stop
> event propagation are not enough, I tried.  Then Docks would then behave
> like the frames holding floating toolbars and prevent events reaching
> the menu bar.  That could entail nasty code to move the dock with the
> parent window, when the Audacity project window moves or is resized, so
> the docks continue to appear to be parented by the project window even
> though they aren't.  I don't intend to do either of these 'fixes' myself
> as I think they are more problem than they are worth.
>
> Yet another fix/hack is to rebuild the menus (with proper accelerators)
> when a user clicks to open the menus.  That would be awfully hacky too,
> I think and likely would have different issues on Mac/Windows/Linux.
>
> I've tried other approaches, like adding " Left" rather than "Left" as a
> menu accelerator.  It displays exactly the same, but the space kills the
> acceleration and makes it invalid. Unfortunately invalid accelerator
> strings mess up the event system so it does not actually fix the issue.
>
>
> My preferred option is that we continue with the current fix of hiding
> the few problematic accelerators when they are in menus. If that is a P2
> bug, I'd argue we can reduce it to P3 by NOT providing the Ext-Menu
> feature.  If it is P3 already, then we release note it and don't have to
> do more than that for 2.2.0.
>
>
> --James.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

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


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Panel-Nav Shortcuts in Menus.

Gale
Administrator
In reply to this post by James Crook
No-one is blaming James for bug 1637 as far as I know. So
I'm opposed to making Ext-Menus experimental for the sake
of James then having a lever to lobby to demote a bug a grade.

Ext-Menus is a useful feature, IMO. Also please think of the
work that has gone into documenting and testing it already,
on assurances this item was in. For the most part, it works
well.

As I see it, the correct choice from the information we have
now is indeed to proceed with hiding the affected accelerators.
As I pointed out, this affects any menu these keys are bound in,
so just turning off Ext-Menus does not even fully hide the problem.

It is (as James says) a bug, and must have been frustrating for
James to work on.


Gale



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

> TL;DR;
>
> What rating would the 'Panel navigation accelerators don't appear in the
> menus' bug have?
> Is its rating affected by whether we have Ext-Menus?
>
>
>
> Details:
>
> We currently have a workaround implemented for what is actually an old bug.
>
> Panel navigation keys, Left-Arrow, Right-Arrow and Enter IF they appear
> in menus bound to our commands 'trump' navigation in the docked
> toolbars.  I.e. you can no longer use them to navigate in those panels.
> Our/my workaround is to not show them there, if they are so bound.
> That's unarguably a bug.  We would like them to show there.
>
> This is discussed in:
>
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1637
> Bug 1637 - Keyboard interaction with many controls in toolbars broken
>
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1639
> Bug 1639 - Panel navigation keys don't work in docked toolbars, if bound
> to some action
>
>
> I believe my workaround largely addresses the P1 bug, 1637.  I think the
> non appearance of arrow keys and enter in menus is no more than P3.  If
> we kill the feature of showing Ext-Menus, one of the claimed benefits of
> which is to familiarise people more easily with the shortcuts, then it
> could be as low as P4 as we are no worse of than for 2.1.3.  and we have
> had no reports of this binding issue in many years of use of Audacity.
>
> A proper fix (to excluding these accelerators from display) entails
> fixing a bug in wxWidgets,
> http://wxwidgets.10942.n7.nabble.com/Disabling-Menu-Accelerators-td83700.html
> and a nasty hack in adding/removing accelerators that works around a
> Windows built in behaviour.  There is an alternative approach/hack which
> separates the docks from the track panel completely.  Flags to stop
> event propagation are not enough, I tried.  Then Docks would then behave
> like the frames holding floating toolbars and prevent events reaching
> the menu bar.  That could entail nasty code to move the dock with the
> parent window, when the Audacity project window moves or is resized, so
> the docks continue to appear to be parented by the project window even
> though they aren't.  I don't intend to do either of these 'fixes' myself
> as I think they are more problem than they are worth.
>
> Yet another fix/hack is to rebuild the menus (with proper accelerators)
> when a user clicks to open the menus.  That would be awfully hacky too,
> I think and likely would have different issues on Mac/Windows/Linux.
>
> I've tried other approaches, like adding " Left" rather than "Left" as a
> menu accelerator.  It displays exactly the same, but the space kills the
> acceleration and makes it invalid. Unfortunately invalid accelerator
> strings mess up the event system so it does not actually fix the issue.
>
>
> My preferred option is that we continue with the current fix of hiding
> the few problematic accelerators when they are in menus. If that is a P2
> bug, I'd argue we can reduce it to P3 by NOT providing the Ext-Menu
> feature.  If it is P3 already, then we release note it and don't have to
> do more than that for 2.2.0.
>
>
> --James.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Panel-Nav Shortcuts in Menus.

Gale
Administrator
In reply to this post by Robert Hänggi
On 6 May 2017 at 13:09, Robert Hänggi <[hidden email]> wrote:

> Hi James
>
> My opinion is that there should be a framework for capturing all key
> (and mouse) events happening in the tool docks/floating toolbars.
>
> This allows for additional commands.
> For instance, we could define that holding "Shift" in the selection
> toolbar swaps to "Clip mode" and arrowing up and down in the selection
> start control (while still pressing the modifier key) would shift a
> clip, rather than define the start time of it.
>
> The problematic keys include also numbers: it is for instance not
> possible to enter a project rate that has a "1" in it because this
> plays a one second preview.

That's already separately logged at:
http://bugzilla.audacityteam.org/show_bug.cgi?id=1260 .



Gale


> Also, some keys would better be propagated to the track panel if no
> special event/function is defined for the control with focus:
> It is not possible to jump to the beginning of a track by simply
> pressing "j" while the focus is in e.g. the selection start.
>
> I'm personally not very fond of navigating toolbars with arrow
> keys--it will only work with buttons, lists, radio buttons input
> fields and so on will trap Left/Right.
>
> There's another idea that strikes me: why not extend the acceleration
> system to toolbars as well, example:
> (assuming the "menu for toolbars would be "O")
> Alt+OSE would bring you to the selection End/Length control.
>
> The current combination is:
> Control+F6
> Tab
> Tab
> Tab
>
> And that's a modest example, try to reach the playback meter with  the
> default toolbars enabled: around 11 keystrokes are necessary.
>
> Of course, I'm speaking of the first time usage in a new session,
> after that the last control focus will be remembered.
>
> Robert
>
> On 06/05/2017, James Crook <[hidden email]> wrote:
>> TL;DR;
>>
>> What rating would the 'Panel navigation accelerators don't appear in the
>> menus' bug have?
>> Is its rating affected by whether we have Ext-Menus?
>>
>>
>>
>> Details:
>>
>> We currently have a workaround implemented for what is actually an old bug.
>>
>> Panel navigation keys, Left-Arrow, Right-Arrow and Enter IF they appear
>> in menus bound to our commands 'trump' navigation in the docked
>> toolbars.  I.e. you can no longer use them to navigate in those panels.
>> Our/my workaround is to not show them there, if they are so bound.
>> That's unarguably a bug.  We would like them to show there.
>>
>> This is discussed in:
>>
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1637
>> Bug 1637 - Keyboard interaction with many controls in toolbars broken
>>
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1639
>> Bug 1639 - Panel navigation keys don't work in docked toolbars, if bound
>> to some action
>>
>>
>> I believe my workaround largely addresses the P1 bug, 1637.  I think the
>> non appearance of arrow keys and enter in menus is no more than P3.  If
>> we kill the feature of showing Ext-Menus, one of the claimed benefits of
>> which is to familiarise people more easily with the shortcuts, then it
>> could be as low as P4 as we are no worse of than for 2.1.3.  and we have
>> had no reports of this binding issue in many years of use of Audacity.
>>
>> A proper fix (to excluding these accelerators from display) entails
>> fixing a bug in wxWidgets,
>> http://wxwidgets.10942.n7.nabble.com/Disabling-Menu-Accelerators-td83700.html
>>
>> and a nasty hack in adding/removing accelerators that works around a
>> Windows built in behaviour.  There is an alternative approach/hack which
>> separates the docks from the track panel completely.  Flags to stop
>> event propagation are not enough, I tried.  Then Docks would then behave
>> like the frames holding floating toolbars and prevent events reaching
>> the menu bar.  That could entail nasty code to move the dock with the
>> parent window, when the Audacity project window moves or is resized, so
>> the docks continue to appear to be parented by the project window even
>> though they aren't.  I don't intend to do either of these 'fixes' myself
>> as I think they are more problem than they are worth.
>>
>> Yet another fix/hack is to rebuild the menus (with proper accelerators)
>> when a user clicks to open the menus.  That would be awfully hacky too,
>> I think and likely would have different issues on Mac/Windows/Linux.
>>
>> I've tried other approaches, like adding " Left" rather than "Left" as a
>> menu accelerator.  It displays exactly the same, but the space kills the
>> acceleration and makes it invalid. Unfortunately invalid accelerator
>> strings mess up the event system so it does not actually fix the issue.
>>
>>
>> My preferred option is that we continue with the current fix of hiding
>> the few problematic accelerators when they are in menus. If that is a P2
>> bug, I'd argue we can reduce it to P3 by NOT providing the Ext-Menu
>> feature.  If it is P3 already, then we release note it and don't have to
>> do more than that for 2.2.0.
>>
>>
>> --James.
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Panel-Nav Shortcuts in Menus.

Gale
Administrator
In reply to this post by James Crook
James wrote in reply to Robert's complaint about the number of
keypresses to get into the meters:

> I think Ext-Menu commands for shortcuts to the toolbars would
> be good.

Yes I agree, and it is a reason that we might continue to allow
Ext-Menu to be turned on.

Are there not some missing commands for the meters? Until
we have monitoring always on, should there not be a binding
(no shortcut set by default) to "Start Monitoring"? Lots of
sighted users might appreciate that too.

Also I can't find a shortcut to open the Playback Meter and
Recording Meter Options. Almost all other dialogues have a
binding to open them.


Gale



On 6 May 2017 at 15:16, James Crook <[hidden email]> wrote:

> On 5/6/2017 1:09 PM, Robert Hänggi wrote:
>> Hi James
>>
>> My opinion is that there should be a framework for capturing all key
>> (and mouse) events happening in the tool docks/floating toolbars.
> Hmm.  Well there IS such a framework.  It is just its design seems to be
> 'wrong'.
>
> Commands are handled (1) by our custom controls first, then (2) by our
> 'command handler' (which has all keyboard bindings we define) then
> handed on to wxWidgets.  wxWidgets then hands stuff on to windows, which
> does (3) menu bar before it does (4) windows controls.
>
> The 'correct' order for us is (1), (4), (2), (3).  Unfortunately the way
> wxWidgets is written seems to force us to do (3) and then (4) as the
> last two steps.  I finagled it by modifying step (2) so that our command
> handler only catches the panel navigation commands if track panel has
> focus, rather than some smaller windows control.  That way panel
> navigation that we want to go to (4) gets through step (2).  I finagled
> step (3) by removing panel navigation keys from menu accelerators.  That
> way those keys get through both (2) and (3) and end up at (4) ,which is
> where we wanted them.
>
>
>
>> This allows for additional commands.
>> For instance, we could define that holding "Shift" in the selection
>> toolbar swaps to "Clip mode" and arrowing up and down in the selection
>> start control (while still pressing the modifier key) would shift a
>> clip, rather than define the start time of it.
>>
>> The problematic keys include also numbers: it is for instance not
>> possible to enter a project rate that has a "1" in it because this
>> plays a one second preview.
> Thanks yes.  Hadn't spotted that.  I believe it is only a problem for
> the project rate, which is for step (4).  It isn't a problem for the
> start/end controls which are ours, and are captured in step (1).  So one
> solution would be to change the project rate control to 'be' a variant
> of our custom start/end controls.
>
>> Also, some keys would better be propagated to the track panel if no
>> special event/function is defined for the control with focus:
>> It is not possible to jump to the beginning of a track by simply
>> pressing "j" while the focus is in e.g. the selection start.
> It seems we are catching too much in step (1) and that could be fixed.
>
>> I'm personally not very fond of navigating toolbars with arrow
>> keys--it will only work with buttons, lists, radio buttons input
>> fields and so on will trap Left/Right.
> I'm not keen on it either, as I navigate by clicking with the mouse.
>
>> There's another idea that strikes me: why not extend the acceleration
>> system to toolbars as well, example:
>> (assuming the "menu for toolbars would be "O")
>> Alt+OSE would bring you to the selection End/Length control.
> I think Ext-Menu commands for shortcuts to the toolbars would be good.
> Bindings for these could be added by the user.
> I'm not keen on more default bindings.  I'd rather we offered an
> optional vibindings.xml that was more complete than our standard bindings.
>
> I'm not keen on the 'SE' extension idea.  I think it gains not very much
> over the shortcut to the toolbar.  How do we know 'S' is not for
> Snap-To?  I'd be fine with rearranging the toolbar so that the most used
> fields were first.
>
>> The current combination is:
>> Control+F6
>> Tab
>> Tab
>> Tab
>>
>> And that's a modest example, try to reach the playback meter with  the
>> default toolbars enabled: around 11 keystrokes are necessary.
>>
>> Of course, I'm speaking of the first time usage in a new session,
>> after that the last control focus will be remembered.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Panel-Nav Shortcuts in Menus.

Robert Hänggi
@David

Yes, the j/k commands work now, that's great.
Either it wasn't there in another version or missed it's working
because the number is not reported by the screen reader automatically
after refreshing it.
Sorry, I should have double-checked it.

I'm fine with just a few additional assignable commands. There
shouldn't be to much of them left.
- the meters as described by Gale
- The selection controls (or just a rearrangement of the entries since
we've already have control-F6 to get into the selection toolbar)
- Perhaps one for the spectral selection toolbar

The ext-menu covers a lot of the other commands, that's very nice.

Robert

On 06/05/2017, Gale Andrews <[hidden email]> wrote:

> James wrote in reply to Robert's complaint about the number of
> keypresses to get into the meters:
>
>> I think Ext-Menu commands for shortcuts to the toolbars would
>> be good.
>
> Yes I agree, and it is a reason that we might continue to allow
> Ext-Menu to be turned on.
>
> Are there not some missing commands for the meters? Until
> we have monitoring always on, should there not be a binding
> (no shortcut set by default) to "Start Monitoring"? Lots of
> sighted users might appreciate that too.
>
> Also I can't find a shortcut to open the Playback Meter and
> Recording Meter Options. Almost all other dialogues have a
> binding to open them.
>
>
> Gale
>
>
>
> On 6 May 2017 at 15:16, James Crook <[hidden email]> wrote:
>> On 5/6/2017 1:09 PM, Robert Hänggi wrote:
>>> Hi James
>>>
>>> My opinion is that there should be a framework for capturing all key
>>> (and mouse) events happening in the tool docks/floating toolbars.
>> Hmm.  Well there IS such a framework.  It is just its design seems to be
>> 'wrong'.
>>
>> Commands are handled (1) by our custom controls first, then (2) by our
>> 'command handler' (which has all keyboard bindings we define) then
>> handed on to wxWidgets.  wxWidgets then hands stuff on to windows, which
>> does (3) menu bar before it does (4) windows controls.
>>
>> The 'correct' order for us is (1), (4), (2), (3).  Unfortunately the way
>> wxWidgets is written seems to force us to do (3) and then (4) as the
>> last two steps.  I finagled it by modifying step (2) so that our command
>> handler only catches the panel navigation commands if track panel has
>> focus, rather than some smaller windows control.  That way panel
>> navigation that we want to go to (4) gets through step (2).  I finagled
>> step (3) by removing panel navigation keys from menu accelerators.  That
>> way those keys get through both (2) and (3) and end up at (4) ,which is
>> where we wanted them.
>>
>>
>>
>>> This allows for additional commands.
>>> For instance, we could define that holding "Shift" in the selection
>>> toolbar swaps to "Clip mode" and arrowing up and down in the selection
>>> start control (while still pressing the modifier key) would shift a
>>> clip, rather than define the start time of it.
>>>
>>> The problematic keys include also numbers: it is for instance not
>>> possible to enter a project rate that has a "1" in it because this
>>> plays a one second preview.
>> Thanks yes.  Hadn't spotted that.  I believe it is only a problem for
>> the project rate, which is for step (4).  It isn't a problem for the
>> start/end controls which are ours, and are captured in step (1).  So one
>> solution would be to change the project rate control to 'be' a variant
>> of our custom start/end controls.
>>
>>> Also, some keys would better be propagated to the track panel if no
>>> special event/function is defined for the control with focus:
>>> It is not possible to jump to the beginning of a track by simply
>>> pressing "j" while the focus is in e.g. the selection start.
>> It seems we are catching too much in step (1) and that could be fixed.
>>
>>> I'm personally not very fond of navigating toolbars with arrow
>>> keys--it will only work with buttons, lists, radio buttons input
>>> fields and so on will trap Left/Right.
>> I'm not keen on it either, as I navigate by clicking with the mouse.
>>
>>> There's another idea that strikes me: why not extend the acceleration
>>> system to toolbars as well, example:
>>> (assuming the "menu for toolbars would be "O")
>>> Alt+OSE would bring you to the selection End/Length control.
>> I think Ext-Menu commands for shortcuts to the toolbars would be good.
>> Bindings for these could be added by the user.
>> I'm not keen on more default bindings.  I'd rather we offered an
>> optional vibindings.xml that was more complete than our standard bindings.
>>
>> I'm not keen on the 'SE' extension idea.  I think it gains not very much
>> over the shortcut to the toolbar.  How do we know 'S' is not for
>> Snap-To?  I'd be fine with rearranging the toolbar so that the most used
>> fields were first.
>>
>>> The current combination is:
>>> Control+F6
>>> Tab
>>> Tab
>>> Tab
>>>
>>> And that's a modest example, try to reach the playback meter with  the
>>> default toolbars enabled: around 11 keystrokes are necessary.
>>>
>>> Of course, I'm speaking of the first time usage in a new session,
>>> after that the last control focus will be remembered.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

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