Status bar messages, modifier keys, brevity, and completeness

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

Status bar messages, modifier keys, brevity, and completeness

Paul Licameli
I raise this rather late, because it occurred to me late, but maybe we want to decide to do something in a hurry before there is a string freeze.

Should status bar messages be shorter and more numerous, changing appropriately with the modifier keys, and not mentioning them?  That is, should we assume a user would be acquainted enough with other programs, to try out modifier keys as part of exploration of Audacity, without our cluing them?

The advantage is overcoming the tl;dr effect.

So for instance this message for the wave track vertical ruler,

"Click to vertically zoom in. Shift-click to zoom out. Drag to specify a zoom region."


would be replaced with two shorter messages.  (Drag works the same, shift or no.)

"Click to vertically zoom in. Drag to specify a zoom region."

"Click to zoom out. Drag to specify a zoom region."

What about mouse wheel actions?  These messages are incomplete without them!  But because there are several mouse wheel actions dependent on modifier key combinations, mentioning them all would really be tl;dr. this supports the notion that you only see the one message appropriate for the key combination that is down.

So a concise message with Shift down could be:

"Click to zoom out. Drag to zoom region. Rotate to scroll."

Which is more complete, for the case of Shift, while still briefer than the original.

Other messages would be appropriate for no key (no scrolling), for Ctrl (scroll to magnify), and (in Waveform dB) for Shift+Ctrl (scroll to change dB scale -- actually two ways, depending on the y coordinate also), covering the various scroll wheel possibilities.

What about right-click actions?  (The last example is still incomplete, as shift+right click to zoom out maximally is not mentioned.)

I would rather reserve right click actions for context menus, and one small reason in favor of that, is that you can't anticipate which button will go down in the status bar message (unless on Mac with the Control modifier key, but that's only Mac), so you have to make longer messages if you want completeness.  But, that ship has sailed for now.  At least for 2.2.0 we will not change what right button does anywhere.  With perhaps the following exception... :

Addendum:

I note these small inconsistencies about Note tracks, which are getting more love in this release:
  1. To mute/unmute a channel, you left-click its button; to solo/unsolo it, you right click.  But should solo/unsolo be a shift-click?  That is somewhat analogous to the Solo buttons, for which Shift makes the difference between exclusive and nonexclusive.
  2. The status bar message for the Stretch tool hides when it is unsafe to do because playback is in progress.  This is not consistent with other messages, which don't hide.  Fix that?  (There is consistency in the cursor change to "disallowed" while playing.)
PRL




------------------------------------------------------------------------------
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: Status bar messages, modifier keys, brevity, and completeness

Cliff Scott
Regarding the length of the status messages, to me the length isn't an issue. I actually rarely look at the status unless I am trying to figure out something at which time the longer message is helpful as it has more information and saves me looking something up in the help. Guess it's a lazy way of doing things. It's hard to assume the user has seen the similar behavior in other software so can figure it out here. There is such a wide experience level out there it's really hard to know. We seem to be thinking of the new user in things like Append Record so maybe that is what should rule here as well. Give the more information and the experienced user can just ignore it.

Cliff

On Jul 13, 2017, at 10:25 PM, Paul Licameli <[hidden email]> wrote:

I raise this rather late, because it occurred to me late, but maybe we want to decide to do something in a hurry before there is a string freeze.

Should status bar messages be shorter and more numerous, changing appropriately with the modifier keys, and not mentioning them?  That is, should we assume a user would be acquainted enough with other programs, to try out modifier keys as part of exploration of Audacity, without our cluing them?

The advantage is overcoming the tl;dr effect.

So for instance this message for the wave track vertical ruler,
"Click to vertically zoom in. Shift-click to zoom out. Drag to specify a zoom region."

would be replaced with two shorter messages.  (Drag works the same, shift or no.)

"Click to vertically zoom in. Drag to specify a zoom region."

"Click to zoom out. Drag to specify a zoom region."

What about mouse wheel actions?  These messages are incomplete without them!  But because there are several mouse wheel actions dependent on modifier key combinations, mentioning them all would really be tl;dr. this supports the notion that you only see the one message appropriate for the key combination that is down.

So a concise message with Shift down could be:

"Click to zoom out. Drag to zoom region. Rotate to scroll."

Which is more complete, for the case of Shift, while still briefer than the original.

Other messages would be appropriate for no key (no scrolling), for Ctrl (scroll to magnify), and (in Waveform dB) for Shift+Ctrl (scroll to change dB scale -- actually two ways, depending on the y coordinate also), covering the various scroll wheel possibilities.

What about right-click actions?  (The last example is still incomplete, as shift+right click to zoom out maximally is not mentioned.)

I would rather reserve right click actions for context menus, and one small reason in favor of that, is that you can't anticipate which button will go down in the status bar message (unless on Mac with the Control modifier key, but that's only Mac), so you have to make longer messages if you want completeness.  But, that ship has sailed for now.  At least for 2.2.0 we will not change what right button does anywhere.  With perhaps the following exception... :

Addendum:

I note these small inconsistencies about Note tracks, which are getting more love in this release:
  1. To mute/unmute a channel, you left-click its button; to solo/unsolo it, you right click.  But should solo/unsolo be a shift-click?  That is somewhat analogous to the Solo buttons, for which Shift makes the difference between exclusive and nonexclusive.
  2. The status bar message for the Stretch tool hides when it is unsafe to do because playback is in progress.  This is not consistent with other messages, which don't hide.  Fix that?  (There is consistency in the cursor change to "disallowed" while playing.)
PRL



------------------------------------------------------------------------------
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: Status bar messages, modifier keys, brevity, and completeness

Paul Licameli


On Fri, Jul 14, 2017 at 9:38 AM, Cliff Scott <[hidden email]> wrote:
Regarding the length of the status messages, to me the length isn't an issue.
I actually rarely look at the status unless I am trying to figure out something at which time the longer message is helpful as it has more information and saves me looking something up in the help. Guess it's a lazy way of doing things. It's hard to assume the user has seen the similar behavior in other software so can figure it out here. There is such a wide experience level out there it's really hard to know. We seem to be thinking of the new user in things like Append Record so maybe that is what should rule here as well. Give the more information and the experienced user can just ignore it.

Cliff


I want to duplicate more status messages as tooltips, which is done already when you hover over tooltip buttons.  So too-long messages getting repeatedly in your face might change your mind about that.  I thought they would better be shorter and sweeter.

PRL
 
 
On Jul 13, 2017, at 10:25 PM, Paul Licameli <[hidden email]> wrote:

I raise this rather late, because it occurred to me late, but maybe we want to decide to do something in a hurry before there is a string freeze.

Should status bar messages be shorter and more numerous, changing appropriately with the modifier keys, and not mentioning them?  That is, should we assume a user would be acquainted enough with other programs, to try out modifier keys as part of exploration of Audacity, without our cluing them?

The advantage is overcoming the tl;dr effect.

So for instance this message for the wave track vertical ruler,
"Click to vertically zoom in. Shift-click to zoom out. Drag to specify a zoom region."

would be replaced with two shorter messages.  (Drag works the same, shift or no.)

"Click to vertically zoom in. Drag to specify a zoom region."

"Click to zoom out. Drag to specify a zoom region."

What about mouse wheel actions?  These messages are incomplete without them!  But because there are several mouse wheel actions dependent on modifier key combinations, mentioning them all would really be tl;dr. this supports the notion that you only see the one message appropriate for the key combination that is down.

So a concise message with Shift down could be:

"Click to zoom out. Drag to zoom region. Rotate to scroll."

Which is more complete, for the case of Shift, while still briefer than the original.

Other messages would be appropriate for no key (no scrolling), for Ctrl (scroll to magnify), and (in Waveform dB) for Shift+Ctrl (scroll to change dB scale -- actually two ways, depending on the y coordinate also), covering the various scroll wheel possibilities.

What about right-click actions?  (The last example is still incomplete, as shift+right click to zoom out maximally is not mentioned.)

I would rather reserve right click actions for context menus, and one small reason in favor of that, is that you can't anticipate which button will go down in the status bar message (unless on Mac with the Control modifier key, but that's only Mac), so you have to make longer messages if you want completeness.  But, that ship has sailed for now.  At least for 2.2.0 we will not change what right button does anywhere.  With perhaps the following exception... :

Addendum:

I note these small inconsistencies about Note tracks, which are getting more love in this release:
  1. To mute/unmute a channel, you left-click its button; to solo/unsolo it, you right click.  But should solo/unsolo be a shift-click?  That is somewhat analogous to the Solo buttons, for which Shift makes the difference between exclusive and nonexclusive.
  2. The status bar message for the Stretch tool hides when it is unsafe to do because playback is in progress.  This is not consistent with other messages, which don't hide.  Fix that?  (There is consistency in the cursor change to "disallowed" while playing.)
PRL



------------------------------------------------------------------------------
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: Status bar messages, modifier keys, brevity, and completeness

Cliff Scott

On Jul 14, 2017, at 8:55 AM, Paul Licameli <[hidden email]> wrote:



On Fri, Jul 14, 2017 at 9:38 AM, Cliff Scott <[hidden email]> wrote:
Regarding the length of the status messages, to me the length isn't an issue.
I actually rarely look at the status unless I am trying to figure out something at which time the longer message is helpful as it has more information and saves me looking something up in the help. Guess it's a lazy way of doing things. It's hard to assume the user has seen the similar behavior in other software so can figure it out here. There is such a wide experience level out there it's really hard to know. We seem to be thinking of the new user in things like Append Record so maybe that is what should rule here as well. Give the more information and the experienced user can just ignore it.

Cliff


I want to duplicate more status messages as tooltips, which is done already when you hover over tooltip buttons.  So too-long messages getting repeatedly in your face might change your mind about that.  I thought they would better be shorter and sweeter.

When you put them in ToolTips then I agree, you don't want long messages. I was thinking of just the status bar for the longer messages, but if you want to move them to ToolTips then I guess there isn't much choice, but to make them "shorter and sweeter".

Cliff


PRL
 
 
On Jul 13, 2017, at 10:25 PM, Paul Licameli <[hidden email]> wrote:

I raise this rather late, because it occurred to me late, but maybe we want to decide to do something in a hurry before there is a string freeze.

Should status bar messages be shorter and more numerous, changing appropriately with the modifier keys, and not mentioning them?  That is, should we assume a user would be acquainted enough with other programs, to try out modifier keys as part of exploration of Audacity, without our cluing them?

The advantage is overcoming the tl;dr effect.

So for instance this message for the wave track vertical ruler,
"Click to vertically zoom in. Shift-click to zoom out. Drag to specify a zoom region."

would be replaced with two shorter messages.  (Drag works the same, shift or no.)

"Click to vertically zoom in. Drag to specify a zoom region."

"Click to zoom out. Drag to specify a zoom region."

What about mouse wheel actions?  These messages are incomplete without them!  But because there are several mouse wheel actions dependent on modifier key combinations, mentioning them all would really be tl;dr. this supports the notion that you only see the one message appropriate for the key combination that is down.

So a concise message with Shift down could be:

"Click to zoom out. Drag to zoom region. Rotate to scroll."

Which is more complete, for the case of Shift, while still briefer than the original.

Other messages would be appropriate for no key (no scrolling), for Ctrl (scroll to magnify), and (in Waveform dB) for Shift+Ctrl (scroll to change dB scale -- actually two ways, depending on the y coordinate also), covering the various scroll wheel possibilities.

What about right-click actions?  (The last example is still incomplete, as shift+right click to zoom out maximally is not mentioned.)

I would rather reserve right click actions for context menus, and one small reason in favor of that, is that you can't anticipate which button will go down in the status bar message (unless on Mac with the Control modifier key, but that's only Mac), so you have to make longer messages if you want completeness.  But, that ship has sailed for now.  At least for 2.2.0 we will not change what right button does anywhere.  With perhaps the following exception... :

Addendum:

I note these small inconsistencies about Note tracks, which are getting more love in this release:
  1. To mute/unmute a channel, you left-click its button; to solo/unsolo it, you right click.  But should solo/unsolo be a shift-click?  That is somewhat analogous to the Solo buttons, for which Shift makes the difference between exclusive and nonexclusive.
  2. The status bar message for the Stretch tool hides when it is unsafe to do because playback is in progress.  This is not consistent with other messages, which don't hide.  Fix that?  (There is consistency in the cursor change to "disallowed" while playing.)
PRL



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


------------------------------------------------------------------------------
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: Status bar messages, modifier keys, brevity, and completeness

Paul Licameli


On Fri, Jul 14, 2017 at 10:35 AM, Cliff Scott <[hidden email]> wrote:

On Jul 14, 2017, at 8:55 AM, Paul Licameli <[hidden email]> wrote:



On Fri, Jul 14, 2017 at 9:38 AM, Cliff Scott <[hidden email]> wrote:
Regarding the length of the status messages, to me the length isn't an issue.
I actually rarely look at the status unless I am trying to figure out something at which time the longer message is helpful as it has more information and saves me looking something up in the help. Guess it's a lazy way of doing things. It's hard to assume the user has seen the similar behavior in other software so can figure it out here. There is such a wide experience level out there it's really hard to know. We seem to be thinking of the new user in things like Append Record so maybe that is what should rule here as well. Give the more information and the experienced user can just ignore it.

Cliff


I want to duplicate more status messages as tooltips, which is done already when you hover over tooltip buttons.  So too-long messages getting repeatedly in your face might change your mind about that.  I thought they would better be shorter and sweeter.

When you put them in ToolTips then I agree, you don't want long messages. I was thinking of just the status bar for the longer messages, but if you want to move them to ToolTips then I guess there isn't much choice, but to make them "shorter and sweeter".

Cliff


But as I said, also to make them more complete, mentioning what scroll wheel does.  Yet, to keep it short, mention only what is fitting for the modifier key combination, because there are many modified scroll wheel actions.  Change the message as modifier keys go up and down.  (The means to do that is implemented already.  Only the selection of messages needs to change.)

PRL

 

PRL
 
 
On Jul 13, 2017, at 10:25 PM, Paul Licameli <[hidden email]> wrote:

I raise this rather late, because it occurred to me late, but maybe we want to decide to do something in a hurry before there is a string freeze.

Should status bar messages be shorter and more numerous, changing appropriately with the modifier keys, and not mentioning them?  That is, should we assume a user would be acquainted enough with other programs, to try out modifier keys as part of exploration of Audacity, without our cluing them?

The advantage is overcoming the tl;dr effect.

So for instance this message for the wave track vertical ruler,
"Click to vertically zoom in. Shift-click to zoom out. Drag to specify a zoom region."

would be replaced with two shorter messages.  (Drag works the same, shift or no.)

"Click to vertically zoom in. Drag to specify a zoom region."

"Click to zoom out. Drag to specify a zoom region."

What about mouse wheel actions?  These messages are incomplete without them!  But because there are several mouse wheel actions dependent on modifier key combinations, mentioning them all would really be tl;dr. this supports the notion that you only see the one message appropriate for the key combination that is down.

So a concise message with Shift down could be:

"Click to zoom out. Drag to zoom region. Rotate to scroll."

Which is more complete, for the case of Shift, while still briefer than the original.

Other messages would be appropriate for no key (no scrolling), for Ctrl (scroll to magnify), and (in Waveform dB) for Shift+Ctrl (scroll to change dB scale -- actually two ways, depending on the y coordinate also), covering the various scroll wheel possibilities.

What about right-click actions?  (The last example is still incomplete, as shift+right click to zoom out maximally is not mentioned.)

I would rather reserve right click actions for context menus, and one small reason in favor of that, is that you can't anticipate which button will go down in the status bar message (unless on Mac with the Control modifier key, but that's only Mac), so you have to make longer messages if you want completeness.  But, that ship has sailed for now.  At least for 2.2.0 we will not change what right button does anywhere.  With perhaps the following exception... :

Addendum:

I note these small inconsistencies about Note tracks, which are getting more love in this release:
  1. To mute/unmute a channel, you left-click its button; to solo/unsolo it, you right click.  But should solo/unsolo be a shift-click?  That is somewhat analogous to the Solo buttons, for which Shift makes the difference between exclusive and nonexclusive.
  2. The status bar message for the Stretch tool hides when it is unsafe to do because playback is in progress.  This is not consistent with other messages, which don't hide.  Fix that?  (There is consistency in the cursor change to "disallowed" while playing.)
PRL



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


------------------------------------------------------------------------------
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: Status bar messages, modifier keys, brevity, and completeness

Cliff Scott

On Jul 14, 2017, at 10:22 AM, Paul Licameli <[hidden email]> wrote:



On Fri, Jul 14, 2017 at 10:35 AM, Cliff Scott <[hidden email]> wrote:

On Jul 14, 2017, at 8:55 AM, Paul Licameli <[hidden email]> wrote:



On Fri, Jul 14, 2017 at 9:38 AM, Cliff Scott <[hidden email]> wrote:
Regarding the length of the status messages, to me the length isn't an issue.
I actually rarely look at the status unless I am trying to figure out something at which time the longer message is helpful as it has more information and saves me looking something up in the help. Guess it's a lazy way of doing things. It's hard to assume the user has seen the similar behavior in other software so can figure it out here. There is such a wide experience level out there it's really hard to know. We seem to be thinking of the new user in things like Append Record so maybe that is what should rule here as well. Give the more information and the experienced user can just ignore it.

Cliff


I want to duplicate more status messages as tooltips, which is done already when you hover over tooltip buttons.  So too-long messages getting repeatedly in your face might change your mind about that.  I thought they would better be shorter and sweeter.

When you put them in ToolTips then I agree, you don't want long messages. I was thinking of just the status bar for the longer messages, but if you want to move them to ToolTips then I guess there isn't much choice, but to make them "shorter and sweeter".

Cliff


But as I said, also to make them more complete, mentioning what scroll wheel does.  Yet, to keep it short, mention only what is fitting for the modifier key combination, because there are many modified scroll wheel actions.  Change the message as modifier keys go up and down.  (The means to do that is implemented already.  Only the selection of messages needs to change.)

PRL

Understand. I had been thinking of  the status bar messages as a more general help as one may not know what key does what. In this case one would need to "experiment" by trying the modifier keys to see what they do rather than in the status bar have it explained for different keys. Guess that is one way to do it. As has been pointed out before many people never look at the status bar so they may miss the help info there as well so maybe to use the tooltips is a better way to give them the help. Hard to know without trying it.

Cliff


 

PRL
 
 
On Jul 13, 2017, at 10:25 PM, Paul Licameli <[hidden email]> wrote:

I raise this rather late, because it occurred to me late, but maybe we want to decide to do something in a hurry before there is a string freeze.

Should status bar messages be shorter and more numerous, changing appropriately with the modifier keys, and not mentioning them?  That is, should we assume a user would be acquainted enough with other programs, to try out modifier keys as part of exploration of Audacity, without our cluing them?

The advantage is overcoming the tl;dr effect.

So for instance this message for the wave track vertical ruler,
"Click to vertically zoom in. Shift-click to zoom out. Drag to specify a zoom region."

would be replaced with two shorter messages.  (Drag works the same, shift or no.)

"Click to vertically zoom in. Drag to specify a zoom region."

"Click to zoom out. Drag to specify a zoom region."

What about mouse wheel actions?  These messages are incomplete without them!  But because there are several mouse wheel actions dependent on modifier key combinations, mentioning them all would really be tl;dr. this supports the notion that you only see the one message appropriate for the key combination that is down.

So a concise message with Shift down could be:

"Click to zoom out. Drag to zoom region. Rotate to scroll."

Which is more complete, for the case of Shift, while still briefer than the original.

Other messages would be appropriate for no key (no scrolling), for Ctrl (scroll to magnify), and (in Waveform dB) for Shift+Ctrl (scroll to change dB scale -- actually two ways, depending on the y coordinate also), covering the various scroll wheel possibilities.

What about right-click actions?  (The last example is still incomplete, as shift+right click to zoom out maximally is not mentioned.)

I would rather reserve right click actions for context menus, and one small reason in favor of that, is that you can't anticipate which button will go down in the status bar message (unless on Mac with the Control modifier key, but that's only Mac), so you have to make longer messages if you want completeness.  But, that ship has sailed for now.  At least for 2.2.0 we will not change what right button does anywhere.  With perhaps the following exception... :

Addendum:

I note these small inconsistencies about Note tracks, which are getting more love in this release:
  1. To mute/unmute a channel, you left-click its button; to solo/unsolo it, you right click.  But should solo/unsolo be a shift-click?  That is somewhat analogous to the Solo buttons, for which Shift makes the difference between exclusive and nonexclusive.
  2. The status bar message for the Stretch tool hides when it is unsafe to do because playback is in progress.  This is not consistent with other messages, which don't hide.  Fix that?  (There is consistency in the cursor change to "disallowed" while playing.)
PRL



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


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