Re: [Audacity-quality] Possible new commands for moving cursor/selection to next/previous label

[David B. <drb...@gm...>]

On Fri, Oct 21, 2016 at 1:46 PM, Steve the Fiddle <ste...@gm...>
wrote:

> On 21 October 2016 at 12:33, David Bailes <drb...@gm...> wrote:
> > On Thu, Oct 20, 2016 at 6:55 PM, Steve the Fiddle <
> ste...@gm...>
> > wrote:
> >>
> >> On 20 October 2016 at 14:56, David Bailes <drb...@gm...> wrote:
> >> > On Tue, Oct 18, 2016 at 6:01 PM, Gale Andrews <ga...@au...>
> >> > wrote:
> >> >>
> >> >> Thanks, David. I tried it on Windows and don't have any issues with
> it
> >> >> as far as it goes, or with the choice of shortcuts, which seem to be
> >> >> available on Mac and Linux too.
> >> >>
> >> >> I was assuming the usefulness was to navigate to a label without
> >> >> opening it for editing. If you want to play a label's audio using
> >> >> SPACE, this saves having to switch focus to the label track (which is
> >> >> required with TAB and  SHIFT + TAB) and then having to ENTER to close
> >> >> the label.
> >> >
> >> >
> >> > Yes, it can save a lot of keystrokes.
> >> >>
> >> >>
> >> >> >From past discussions though I think Robert prefers one pair of
> >> >> shortcuts to navigate labels in the focused label track, and a
> >> >> shortcut (with Label Track button) that toggles label editing.
> >> >
> >> >
> >> > I'm hoping that Robert will comment about all of this at some stage.
> >> >>
> >> >>
> >> >> We could I think do with a pair of shortcuts to navigate clips, so
> >> >> perhaps there is some case for not adding David's shortcuts.
> >> >
> >> >
> >> > On Tue, Oct 18, 2016 at 4:56 PM, Paul Licameli <
> pau...@gm...>
> >> > wrote:
> >> >>
> >> >> You are aware that this is partly redundant with TAB or Shift+TAB to
> >> >> navigate labels.  I do not understand why we need the alternative.
> Can
> >> >> the
> >> >> behavior of TAB be improved instead?
> >> >
> >> >
> >> > My motivation for the new commands included: being able to move to
> >> > next/previous label without either having to move to the label track
> or
> >> > open
> >> > the label editor would result in fewer keystrokes being needed; there
> >> > have
> >> > been a number of discussions over the years about improving the
> keyboard
> >> > navigation of the label tracks, but there still remain the issues
> >> > detailed
> >> > below.
> >> >>
> >> >>
> >> >
> >> >
> >> > Hi Gale and Paul,
> >> > thanks for your feedback.
> >> >
> >> > Issues with the keyboard navigation of label tracks:
> >> >
> >> > 1. Currently tab and shift+tab are used, and they open automatically
> >> > open
> >> > the name of the label for editing. To be able to press space to play,
> >> > you
> >> > first have to press enter to close the edit. This is very
> inconvenient,
> >>
> >> On the other hand, it is convenient if you do want to edit the label
> >> text (continued below ...)
> >>
> >> > and
> >> > it's just too easy to end up adding extra characters to the name of
> the
> >> > label.
> >> > Possible ways of improving this:
> >> >
> >> > a. Change the behaviour of tab and shift+tab so that they just select
> a
> >> > label, without automatically opening the name for editing. (Note that
> it
> >> > could be argued that tab and shift+tab would no longer really be
> >> > appropriate
> >> > keystrokes, as the focus is not changed.)
> >> >
> >> > b. Have a setting with the options that tab and shift+tab either have
> >> > their
> >> > current behaviour, or they just select a label, without automatically
> >> > opening the name for editing.
> >> >
> >> > c. Leave tab and shift+tab with their current behaviour, and introduce
> >> > two
> >> > new keystrokes that just select a label.
> >> >
> >> > 2. It's too easy to accidentally create a new label. If the focus is a
> >> > label
> >> > track, and the cursor is at a position where there isn't an existing
> >> > label,
> >> > then pressing an alphanumeric character creates a new label. Possible
> >> > ways
> >> > of improving this:
> >>
> >> (... continued...) On the other hand, it is convenient if you do want
> >> to create a label.
> >>
> >> If I recall correctly, the ability to type directly into a label track
> >> (and thus 'automatically' create a label, was added specifically to
> >> provide this convenience (for users that type lots of labels).
> >>
> >> In both 1) and 2), what is convenient in some cases is inconvenient in
> >> others.
> >>
> >> I don't think this is a case of "for some users ..., while for other
> >> users ...".
> >
> >
> > I would be surprised if any screen reader user would ever want the
> behaviour
> > of automatically creating a label.
>
> Sorry, I wasn't very clear. I meant that I don't think this is 'only'
> a case of ...
> In other words, some (probably many) users will want to switch between
> behaviours depending on what they are doing at the time (I'm certainly
> in that camp and I doubt that I'm alone). For that reason I think it
> needs to be an option that can be easily toggled rather than buried in
> Preferences.
>

Just to clarify: although you've suggested having a single option that
controls both whether a label is created when an alphanumeric key is
pressed, and whether the name of the label is opened for editing when you
move to the next label, the other possibilities are:

1. If different commands are used to moving to the next/previous label
without opening the name for editing, then there doesn't need to be an
option, a user can do either without having to change any setting. The
aspect of having different commands which is of most interest to me is that
they could be designed so that the user didn't have to move to the label
track to use them, as I've implemented in my nextlabel branch. I'm hoping
to get feedback from Robert about how useful he thinks this is, and I'll
probably consult on the Audacity4Blind list at some stage. (In Reaper,
there aren't label tracks, just markers, and it's easy to move between the
markers - no changing tracks needed.)

2. There are two separate options.

I agree that any option(s) shouldn't be available only in preferences - I
think if they were on a menu (possibly a Label menu as you suggest below)
that would be fine.


> >
> >>
> >> When using Audacity, I sometimes find the current
> >> behaviour (of automatically opening for editing) convenient, while at
> >> other times I find it inconvenient, so I don't think that a
> >> "preference" is appropriate here (my 'preferred' behaviour changes
> >> depending on what I'm doing), but rather an 'option' that can easily
> >> be toggled on or off as required.
> >>
> >> For audio tracks we can easily and conveniently toggle mute/un-mute,
> >> either via the "Mute" button, or by a keyboard shortcut (Shift+U).
> >> We could do a similar thing for label tracks - have a button and
> >> keyboard shortcut for "direct label edit" (or whatever we want to call
> >> it).
> >
> >
> > A button on a label track implies that it only affects that track. Would
> a
> > user ever want different settings for different label tracks?
>
> Good point. I very rarely use more than one label track so I missed that.
>
> > I think it would be simpler and less potentially confusing to have a
> setting
> > which controls the behaviour of all label tracks,  and this wouldn't
> > therefore belong on an individual track. This setting could appear as an
> > option on one of the menus, and if necessary a button somewhere in the
> main
> > window.
>
> It's been discussed before, and personally I'd not be averse to having
> a top level "Labels" menu. We've already got 12 sub-menu items for
> labels (not including the Nyquist "Analyze" plug-ins), and it would be
> useful to have a few more (such as merging label regions and
> collapsing region labels to point labels). If there was such a top
> level menu, then that would be the obvious place for this option.
>
> > In addition, from a keyboard users perspective, if the control was on a
> > label track, they would have to remember the shortcut to activate the
> > button, rather than having the option of just browsing to the option in a
> > menu.
>
> but as you said, screen reader users would probably never need to use
> the button, (assuming that direct editing was off by default).
>

If the default settings of the button(s) were appropriate for users of
screen readers, I guess that would be ok, but I still question whether per
track settings would be helpful for users. To me it seems over the top.

>
> >>
> >>
> >> When the button is down:
> >> Typing into a label track automatically adds a label.
> >> Tabbing from one label to the next opens the label text for editing.
> >> To close the label text after editing, press "Enter".
> >>
> >> When the button is up:
> >> Typing a letter does not create a label (you need to add a label
> >> first, and then type into it).
> >> Tabbing from one label to the next does not open the label text for
> >> editing (it just moves to the label position).
> >> To close the label text after editing, press "Enter". To open a
> >> selected label for editing, press shift+Enter.
> >>
> >>
> >> > a. Have a setting with one option being the current behaviour, and the
> >> > other
> >> > that a new label can only be created by pressing ctrl+b.
> >> >
> >> > 3. The number of keystrokes needed to move to the next/previous label.
> >> > If
> >> > you are editing an audio track, and it's the focus, and you want to
> move
> >> > to
> >> > a label, then there are currently two options. First, arrow your way
> to
> >> > a
> >> > label track, move to the label you want, and then you'll probably want
> >> > to
> >> > arrow your back to the audio track (The use of ctrl+home/end may
> reduce
> >> > the
> >> > keystrokes). Second, open the label editor, move to a label, and close
> >> > the
> >> > editor. Possible ways of improving this:
> >> > a. Have commands (and keystrokes) to move to the next or previous
> label
> >> > which use the first label track starting at the track which is the
> >> > focus.
> >> >
> >> > Additional issues for users of screen readers:
> >> >
> >> > 1. The edit box used for label names is not a real edit box, and it's
> >> > difficult to make this accessible for screen readers.
> >>
> >> Does "difficult" mean "impossible"?
> >
> >
> > I don't know whether it's impossible, and I don't know how much work
> would
> > be required to find that out.
> >
> >>
> >> What exactly is the problem?
> >
> >
> > There are two problems.
> > Due to changes in keyboard handling in 2.1.2 (I think), there was the
> > unexpected side effect that when using nvda, when you type characters
> into
> > the "edit" box for a label name on the label track, nvda does not echo
> the
> > characters you type in.
>
> Possibly a Wx3 change?
>

No, Leland completely changed the keyboard input handling.

>
> > I've had a look at this problem and haven't a clue how to solve it, apart
> > from using a script for nvda, which Robert may have already done.
> However,
> > it would be preferable for something like this to work out of the box.
> >
> > The second issue affects all screen readers. If the focus is the edit
> box,
> > then there is no feedback given by the screen reader when you move the
> text
> > cursor, delete characters etc. Ways of fixing this include: 1. Create an
> > accessible object for the "edit" box. Without going into too many
> details,
> > this does not appear to be straightforward, and I don't know how long it
> > would take to find out if it could be done.
>
> Selection of label text has a history of being flaky (at least that's
> my experience on Linux), though for me it now works much better than
> in older versions (but I don't use a screen reader).
>

I've noticed that sometimes when tabbing to a label, some of the characters
are already selected. Is this the sort of thing you're referring to?

>
> > In addition, the same would have
> > to be done for the mac accessibility. The second option would be to
> insert
> > calls to a message function in the Audacity code which handles this
> editing,
> > and  this message function would get the screen reader to read out the
> > appropriate characters as the cursor was moved around etc. It wouldn't be
> > possible/easy to do this for every editing action, but probably be
> enough to
> > be usable.
>
> So you're saying that editing via a "proper" text input dialog window
> would be your preferred solution?
>

The main issue is when creating a new label. When editing a label, the
label editor dialog can be used. For creating a label, having a text input
dialog window would be my preferred solution, or at least for there to be
an option for this to be the case.

>
> One other thing for the pot - I've noticed that when there are a lot
> (many hundreds) of labels, everything in Audacity becomes very
> sluggish. I've not looked at the code but I'm guessing that it's
> because we don't cache the graphics but calculate label positions on
> the fly. it would be nice if we could improve that, but more
> importantly we would not want to make it worse.
>
> Steve
>
> >
> >>
> >> > Possible ways of improving this:
> >> > a. When creating a new label by pressing ctrl+b, open a dialog to
> enter
> >> > the
> >> > name. There could be a setting for this to be an option.
> >>
> >> Would my suggestion above provide a solution?
> >
> >
> > I don't understand this question!
> >
> > thanks for your feedback,
> > David.
> >
> >>
> >>
> >> Steve
> >>
> >> >
> >> > 2. When moving to next/previous label, the name of the label is not
> read
> >> > by
> >> > screen readers. This is comparatively easy to fix, and my nextlabel
> >> > branch
> >> > does this one way, though others are possible.
> >> >
> >> > David.
> >> >
> >> >>
> >> >>
> >> >> Gale
> >> >>
> >> >>
> >> >> On 18 October 2016 at 16:56, Paul Licameli <pau...@gm...>
> >> >> wrote:
> >> >> > You are aware that this is partly redundant with TAB or Shift+TAB
> to
> >> >> > navigate labels.  I do not understand why we need the alternative.
> >> >> > Can
> >> >> > the
> >> >> > behavior of TAB be improved instead?
> >> >> >
> >> >> > PRL
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Tue, Oct 18, 2016 at 11:12 AM, David Bailes <drb...@gm...
> >
> >> >> > wrote:
> >> >> >>
> >> >> >> The motivation for these possible two new commands is for users of
> >> >> >> screen
> >> >> >> readers, so they can move the cursor/selection to labels without
> >> >> >> needing to
> >> >> >> use the label editor.
> >> >> >>
> >> >> >> The two commands are "selection to next label" and "selection to
> >> >> >> previous
> >> >> >> label", and they work independently of tabbing in a label track.
> >> >> >> I've
> >> >> >> given
> >> >> >> them default keystrokes of alt+right and alt+left, but others may
> >> >> >> well
> >> >> >> be
> >> >> >> preferable.
> >> >> >>
> >> >> >> They use the labels in the first label track, if any, starting at
> >> >> >> the
> >> >> >> focused track. I think it's more convenient if the label track
> >> >> >> doesn't
> >> >> >> have
> >> >> >> to be the focus to use these commands.
> >> >> >>
> >> >> >> For screen readers, the name of the label, if any, if read,
> followed
> >> >> >> by
> >> >> >> label number "of" number of labels. The accessibility name of the
> >> >> >> track
> >> >> >> is
> >> >> >> overwritten by this message. To read the name of the track again,
> >> >> >> you
> >> >> >> can
> >> >> >> press enter twice. I am aware of one case where nvda now says
> >> >> >> selected
> >> >> >> when
> >> >> >> it shouldn't.
> >> >> >>
> >> >> >> These commands are available in the branch nextlabel in my fork of
> >> >> >> audacity, if anyone wants to have a play, and see if they think
> they
> >> >> >> may be
> >> >> >> useful.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> https://github.com/DavidBailes/audacity/commit/
> b04a98e6c8bd17dc2a593e56d1bbc699415bea8f
> >> >> >>
> >> >> >> David.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> ------------------------------------------------------------
> ------------------
> >> >> >> 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
> >> >> >> Aud...@li...
> >> >> >> 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
> >> >> > Aud...@li...
> >> >> > 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
> >> >> Aud...@li...
> >> >> 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
> >> > Aud...@li...
> >> > 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
> >> Aud...@li...
> >> 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
> > Aud...@li...
> > 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
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>