improvement for screen readers when removing a track

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

improvement for screen readers when removing a track

David Bailes-3
The following commit is hopefully an improvement. I would be grateful for feedback from Robert and David.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: improvement for screen readers when removing a track

Robert Hänggi
Seems to work fine.
No problems with stereo or mono tracks.

There is one thing I wonder about:
When commands act on a focused track then the undo action won't take
that into account and the focus lands on the first track selected.

So, if the tenth track is selected and I remove the forth track (which
has focus), followed by an undo, the focus will be on the 10th track
and not on the re-inserted forth track.
Same for e.g. a name change. If I made a typo and undo the name
change, the focus will land far away in the worst case.

I think it would be worthwhile to save the focus along with
focus-specific commands on the undo stack.
This includes the context menu commands and also Pan/Gain.

What do you think?

Robert

On 04/07/2017, David Bailes <[hidden email]> wrote:
> The following commit is hopefully an improvement. I would be grateful for
> feedback from Robert and David.
> https://github.com/audacity/audacity/commit/4de3264d602683e5bed2b3277283465ffb72e3a7
>
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: improvement for screen readers when removing a track

David Bailes-3
On Wed, Jul 5, 2017 at 10:25 AM, Robert Hänggi <[hidden email]> wrote:
Seems to work fine.
No problems with stereo or mono tracks.

thanks for checking.
 

There is one thing I wonder about:
When commands act on a focused track then the undo action won't take
that into account and the focus lands on the first track selected.

So, if the tenth track is selected and I remove the forth track (which
has focus), followed by an undo, the focus will be on the 10th track
and not on the re-inserted forth track.
Same for e.g. a name change. If I made a typo and undo the name
change, the focus will land far away in the worst case.

I think it would be worthwhile to save the focus along with
focus-specific commands on the undo stack.
This includes the context menu commands and also Pan/Gain.

What do you think?

I agree that the current behaviour of how undo can affect the focus isn't right, and in fact there's an open bug on this issue:

David.

Robert

On 04/07/2017, David Bailes <[hidden email]> wrote:
> The following commit is hopefully an improvement. I would be grateful for
> feedback from Robert and David.
> https://github.com/audacity/audacity/commit/4de3264d602683e5bed2b3277283465ffb72e3a7
>
> 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
[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: improvement for screen readers when removing a track

Robert Hänggi
Hi David

Thanks for providing the bug ID.
It's a bit confusing since some of the issues are obviously fixed.
It might need a descendent bug with focus on focus...

Here's a somewhat related issue to doubled stereo track announcement
involving clips:

Scenario: Two audio tracks, both stereo.
When nothing is selected and I navigate by clips, something like
"Vocals, Clip 1 of 2" will be spoken (i.e. is the temporary track
name).
However, it is spoken twice because of the stereo track.

It is worse if the tracks have no name but the default.
For track 1 it speaks "Track 1 Clip 1 of 2, Track 2 Clip 1 of two"
For track 2 it speaks "Track 3 Clip 1 of 2, Track 4 Clip 1 of two"
The cause might be the track panel refactoring.

I think that the double output should be avoided if the clips have the
same times in both channels.
Otherwise, the right iterator count and the panning should be spoken
(Left/Right or L/R).
However, I don't know how you want to solve the problem with different
length clips in a stereo track. It is not much of an issue for
navigation by previous/next clip boundary but it is certainly for
navigating by whole clips.

Robert

On 06/07/2017, David Bailes <[hidden email]> wrote:

> On Wed, Jul 5, 2017 at 10:25 AM, Robert Hänggi <[hidden email]>
> wrote:
>
>> Seems to work fine.
>> No problems with stereo or mono tracks.
>>
>
> thanks for checking.
>
>
>>
>> There is one thing I wonder about:
>> When commands act on a focused track then the undo action won't take
>> that into account and the focus lands on the first track selected.
>>
>> So, if the tenth track is selected and I remove the forth track (which
>> has focus), followed by an undo, the focus will be on the 10th track
>> and not on the re-inserted forth track.
>> Same for e.g. a name change. If I made a typo and undo the name
>> change, the focus will land far away in the worst case.
>>
>> I think it would be worthwhile to save the focus along with
>> focus-specific commands on the undo stack.
>> This includes the context menu commands and also Pan/Gain.
>>
>> What do you think?
>>
>
> I agree that the current behaviour of how undo can affect the focus isn't
> right, and in fact there's an open bug on this issue:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=510
>
> David.
>
>>
>> Robert
>>
>> On 04/07/2017, David Bailes <[hidden email]> wrote:
>> > The following commit is hopefully an improvement. I would be grateful
>> > for
>> > feedback from Robert and David.
>> > https://github.com/audacity/audacity/commit/
>> 4de3264d602683e5bed2b3277283465ffb72e3a7
>> >
>> > 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
>> [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: improvement for screen readers when removing a track

David Bailes-3
On Sun, Jul 9, 2017 at 2:12 PM, Robert Hänggi <[hidden email]> wrote:
Hi David

Thanks for providing the bug ID.
It's a bit confusing since some of the issues are obviously fixed.
It might need a descendent bug with focus on focus... 

Here's a somewhat related issue to doubled stereo track announcement
involving clips:

Scenario: Two audio tracks, both stereo.
When nothing is selected and I navigate by clips, something like
"Vocals, Clip 1 of 2" will be spoken (i.e. is the temporary track
name).
However, it is spoken twice because of the stereo track.

It is worse if the tracks have no name but the default.
For track 1 it speaks "Track 1 Clip 1 of 2, Track 2 Clip 1 of two"
For track 2 it speaks "Track 3 Clip 1 of 2, Track 4 Clip 1 of two"
The cause might be the track panel refactoring.

It's my mistake, forgot to test on stereo tracks. Sigh. 

I think that the double output should be avoided if the clips have the
same times in both channels.
Otherwise, the right iterator count and the panning should be spoken
(Left/Right or L/R).
However, I don't know how you want to solve the problem with different
length clips in a stereo track. It is not much of an issue for
navigation by previous/next clip boundary but it is certainly for
navigating by whole clips.

If the clips are different in the different channels, then when selecting next/previous clip,
if it said something like:
"Vocals, right, 1 of 2 clips", would that be ok?

When you say "I don't know how you want to solve the problem with different length clips in a stereo track", what was the problem that you were referring to?

thanks,
David.


Robert

On 06/07/2017, David Bailes <[hidden email]> wrote:
> On Wed, Jul 5, 2017 at 10:25 AM, Robert Hänggi <[hidden email]>
> wrote:
>
>> Seems to work fine.
>> No problems with stereo or mono tracks.
>>
>
> thanks for checking.
>
>
>>
>> There is one thing I wonder about:
>> When commands act on a focused track then the undo action won't take
>> that into account and the focus lands on the first track selected.
>>
>> So, if the tenth track is selected and I remove the forth track (which
>> has focus), followed by an undo, the focus will be on the 10th track
>> and not on the re-inserted forth track.
>> Same for e.g. a name change. If I made a typo and undo the name
>> change, the focus will land far away in the worst case.
>>
>> I think it would be worthwhile to save the focus along with
>> focus-specific commands on the undo stack.
>> This includes the context menu commands and also Pan/Gain.
>>
>> What do you think?
>>
>
> I agree that the current behaviour of how undo can affect the focus isn't
> right, and in fact there's an open bug on this issue:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=510
>
> David.
>
>>
>> Robert
>>
>> On 04/07/2017, David Bailes <[hidden email]> wrote:
>> > The following commit is hopefully an improvement. I would be grateful
>> > for
>> > feedback from Robert and David.
>> > https://github.com/audacity/audacity/commit/
>> 4de3264d602683e5bed2b3277283465ffb72e3a7
>> >
>> > 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
>> [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: improvement for screen readers when removing a track

Robert Hänggi
On 10/07/2017, David Bailes <[hidden email]> wrote:

> On Sun, Jul 9, 2017 at 2:12 PM, Robert Hänggi <[hidden email]>
> wrote:
>
>> Hi David
>>
>> Thanks for providing the bug ID.
>> It's a bit confusing since some of the issues are obviously fixed.
>> It might need a descendent bug with focus on focus...
>
>
>> Here's a somewhat related issue to doubled stereo track announcement
>> involving clips:
>>
>> Scenario: Two audio tracks, both stereo.
>> When nothing is selected and I navigate by clips, something like
>> "Vocals, Clip 1 of 2" will be spoken (i.e. is the temporary track
>> name).
>> However, it is spoken twice because of the stereo track.
>>
>> It is worse if the tracks have no name but the default.
>> For track 1 it speaks "Track 1 Clip 1 of 2, Track 2 Clip 1 of two"
>> For track 2 it speaks "Track 3 Clip 1 of 2, Track 4 Clip 1 of two"
>> The cause might be the track panel refactoring.
>>
>
> It's my mistake, forgot to test on stereo tracks. Sigh.
>
>>
>> I think that the double output should be avoided if the clips have the
>> same times in both channels.
>> Otherwise, the right iterator count and the panning should be spoken
>> (Left/Right or L/R).
>> However, I don't know how you want to solve the problem with different
>> length clips in a stereo track. It is not much of an issue for
>> navigation by previous/next clip boundary but it is certainly for
>> navigating by whole clips.
>>
>
> If the clips are different in the different channels, then when selecting
> next/previous clip,
> if it said something like:
> "Vocals, right, 1 of 2 clips", would that be ok?

Yes, I think so.

I would reconsider the order of the info though.

Currently, I have the following output:
'Track 1 1 of 1 clip ,   2 of 2' in Nvda

Firstly, the clip section is the most important part since it will
change more frequent than the track name part (especially with only
one track selected).
Secondly, if the position of a list item is enabled in NVDA, it will
append the track's position at the end.

Therefore, it would be more logical to say
'1 of 1 clip, Track 1    2 of 2'
or even
'1 of 1 clip on Track 1    2 of 2'
and the panning added somewhere in between, if necessary:
'1 of 1 clip, left on Track 1    2 of 2'

I think JAWS says the position info only if the track is defined as a
list item, rather than a table row.

(BTW, I've just discovered how to prevent JAWS from saying "Table" in
front of each track. It would be nice if you added a section to your
JAWS guide about setting up JAWS subjectively best.)


>
> When you say "I don't know how you want to solve the problem with different
> length clips in a stereo track", what was the problem that you were
> referring to?

I mean what the object depth should be within stereo tracks. Mouse
users have several options to move clips in a stereo track. Thus, the
problem is how you want to enable selecting only one clip in only one
channel of a stereo track.
The obvious way is to do it not at all since the stereo track can
always be exploded (split stereo track) and to move clips
independently afterwards.
So the question is what defines a movable unit in a stereo track with
odd length clips?

Robert

>
> thanks,
> David.
>
>
>> Robert
>>
>> On 06/07/2017, David Bailes <[hidden email]> wrote:
>> > On Wed, Jul 5, 2017 at 10:25 AM, Robert Hänggi
>> > <[hidden email]>
>> > wrote:
>> >
>> >> Seems to work fine.
>> >> No problems with stereo or mono tracks.
>> >>
>> >
>> > thanks for checking.
>> >
>> >
>> >>
>> >> There is one thing I wonder about:
>> >> When commands act on a focused track then the undo action won't take
>> >> that into account and the focus lands on the first track selected.
>> >>
>> >> So, if the tenth track is selected and I remove the forth track (which
>> >> has focus), followed by an undo, the focus will be on the 10th track
>> >> and not on the re-inserted forth track.
>> >> Same for e.g. a name change. If I made a typo and undo the name
>> >> change, the focus will land far away in the worst case.
>> >>
>> >> I think it would be worthwhile to save the focus along with
>> >> focus-specific commands on the undo stack.
>> >> This includes the context menu commands and also Pan/Gain.
>> >>
>> >> What do you think?
>> >>
>> >
>> > I agree that the current behaviour of how undo can affect the focus
>> > isn't
>> > right, and in fact there's an open bug on this issue:
>> > http://bugzilla.audacityteam.org/show_bug.cgi?id=510
>> >
>> > David.
>> >
>> >>
>> >> Robert
>> >>
>> >> On 04/07/2017, David Bailes <[hidden email]> wrote:
>> >> > The following commit is hopefully an improvement. I would be
>> >> > grateful
>> >> > for
>> >> > feedback from Robert and David.
>> >> > https://github.com/audacity/audacity/commit/
>> >> 4de3264d602683e5bed2b3277283465ffb72e3a7
>> >> >
>> >> > 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
>> >> [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: improvement for screen readers when removing a track

David Bailes-3
On Mon, Jul 10, 2017 at 2:04 PM, Robert Hänggi <[hidden email]> wrote:
On 10/07/2017, David Bailes <[hidden email]> wrote:
> On Sun, Jul 9, 2017 at 2:12 PM, Robert Hänggi <[hidden email]>
> wrote:
>
>> Hi David
>>
>> Thanks for providing the bug ID.
>> It's a bit confusing since some of the issues are obviously fixed.
>> It might need a descendent bug with focus on focus...
>
>
>> Here's a somewhat related issue to doubled stereo track announcement
>> involving clips:
>>
>> Scenario: Two audio tracks, both stereo.
>> When nothing is selected and I navigate by clips, something like
>> "Vocals, Clip 1 of 2" will be spoken (i.e. is the temporary track
>> name).
>> However, it is spoken twice because of the stereo track.
>>
>> It is worse if the tracks have no name but the default.
>> For track 1 it speaks "Track 1 Clip 1 of 2, Track 2 Clip 1 of two"
>> For track 2 it speaks "Track 3 Clip 1 of 2, Track 4 Clip 1 of two"
>> The cause might be the track panel refactoring.
>>
>
> It's my mistake, forgot to test on stereo tracks. Sigh.
>
>>
>> I think that the double output should be avoided if the clips have the
>> same times in both channels.
>> Otherwise, the right iterator count and the panning should be spoken
>> (Left/Right or L/R).
>> However, I don't know how you want to solve the problem with different
>> length clips in a stereo track. It is not much of an issue for
>> navigation by previous/next clip boundary but it is certainly for
>> navigating by whole clips.
>>
>
> If the clips are different in the different channels, then when selecting
> next/previous clip,
> if it said something like:
> "Vocals, right, 1 of 2 clips", would that be ok?

Yes, I think so.

I would reconsider the order of the info though.

Currently, I have the following output:
'Track 1 1 of 1 clip ,   2 of 2' in Nvda

Firstly, the clip section is the most important part since it will
change more frequent than the track name part (especially with only
one track selected)
Secondly, if the position of a list item is enabled in NVDA, it will
append the track's position at the end.

Therefore, it would be more logical to say
'1 of 1 clip, Track 1    2 of 2'
or even
'1 of 1 clip on Track 1    2 of 2'
and the panning added somewhere in between, if necessary:
'1 of 1 clip, left on Track 1    2 of 2'

I think JAWS says the position info only if the track is defined as a
list item, rather than a table row.

I presume that the 2 of 2 bit is coming from your script. And yes, by default Jaws doesn't say the position info. 

Currently, when only one track is selected, the track name is omitted (at least for mono tracks). When I've got my code to say the correct info, it will be easy to change the order around.
 

(BTW, I've just discovered how to prevent JAWS from saying "Table" in
front of each track. It would be nice if you added a section to your
JAWS guide about setting up JAWS subjectively best.) 


>
> When you say "I don't know how you want to solve the problem with different
> length clips in a stereo track", what was the problem that you were
> referring to?

I mean what the object depth should be within stereo tracks. Mouse
users have several options to move clips in a stereo track. Thus, the
problem is how you want to enable selecting only one clip in only one
channel of a stereo track.
The obvious way is to do it not at all since the stereo track can
always be exploded (split stereo track) and to move clips
independently afterwards.
So the question is what defines a movable unit in a stereo track with
odd length clips? 

Even using the mouse, it's not sure the current behaviour is what a user might expect, and my current code for moving clips doesn't do the same as the mouse when the clips are different. But as you say, it may well be simpler just to spit it, move stuff, and then reassemble,

David. 

Robert

>
> thanks,
> David.
>
>
>> Robert
>>
>> On 06/07/2017, David Bailes <[hidden email]> wrote:
>> > On Wed, Jul 5, 2017 at 10:25 AM, Robert Hänggi
>> > <[hidden email]>
>> > wrote:
>> >
>> >> Seems to work fine.
>> >> No problems with stereo or mono tracks.
>> >>
>> >
>> > thanks for checking.
>> >
>> >
>> >>
>> >> There is one thing I wonder about:
>> >> When commands act on a focused track then the undo action won't take
>> >> that into account and the focus lands on the first track selected.
>> >>
>> >> So, if the tenth track is selected and I remove the forth track (which
>> >> has focus), followed by an undo, the focus will be on the 10th track
>> >> and not on the re-inserted forth track.
>> >> Same for e.g. a name change. If I made a typo and undo the name
>> >> change, the focus will land far away in the worst case.
>> >>
>> >> I think it would be worthwhile to save the focus along with
>> >> focus-specific commands on the undo stack.
>> >> This includes the context menu commands and also Pan/Gain.
>> >>
>> >> What do you think?
>> >>
>> >
>> > I agree that the current behaviour of how undo can affect the focus
>> > isn't
>> > right, and in fact there's an open bug on this issue:
>> > http://bugzilla.audacityteam.org/show_bug.cgi?id=510
>> >
>> > David.
>> >
>> >>
>> >> Robert
>> >>
>> >> On 04/07/2017, David Bailes <[hidden email]> wrote:
>> >> > The following commit is hopefully an improvement. I would be
>> >> > grateful
>> >> > for
>> >> > feedback from Robert and David.
>> >> > https://github.com/audacity/audacity/commit/
>> >> 4de3264d602683e5bed2b3277283465ffb72e3a7
>> >> >
>> >> > 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
>> >> [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: improvement for screen readers when removing a track

Robert Hänggi
On 10/07/2017, David Bailes <[hidden email]> wrote:

> On Mon, Jul 10, 2017 at 2:04 PM, Robert Hänggi <[hidden email]>
> wrote:
>
>> On 10/07/2017, David Bailes <[hidden email]> wrote:
>> > On Sun, Jul 9, 2017 at 2:12 PM, Robert Hänggi <[hidden email]>
>> > wrote:
>> >
>> >> Hi David
>> >>
>> >> Thanks for providing the bug ID.
>> >> It's a bit confusing since some of the issues are obviously fixed.
>> >> It might need a descendent bug with focus on focus...
>> >
>> >
>> >> Here's a somewhat related issue to doubled stereo track announcement
>> >> involving clips:
>> >>
>> >> Scenario: Two audio tracks, both stereo.
>> >> When nothing is selected and I navigate by clips, something like
>> >> "Vocals, Clip 1 of 2" will be spoken (i.e. is the temporary track
>> >> name).
>> >> However, it is spoken twice because of the stereo track.
>> >>
>> >> It is worse if the tracks have no name but the default.
>> >> For track 1 it speaks "Track 1 Clip 1 of 2, Track 2 Clip 1 of two"
>> >> For track 2 it speaks "Track 3 Clip 1 of 2, Track 4 Clip 1 of two"
>> >> The cause might be the track panel refactoring.
>> >>
>> >
>> > It's my mistake, forgot to test on stereo tracks. Sigh.
>> >
>> >>
>> >> I think that the double output should be avoided if the clips have the
>> >> same times in both channels.
>> >> Otherwise, the right iterator count and the panning should be spoken
>> >> (Left/Right or L/R).
>> >> However, I don't know how you want to solve the problem with different
>> >> length clips in a stereo track. It is not much of an issue for
>> >> navigation by previous/next clip boundary but it is certainly for
>> >> navigating by whole clips.
>> >>
>> >
>> > If the clips are different in the different channels, then when
>> > selecting
>> > next/previous clip,
>> > if it said something like:
>> > "Vocals, right, 1 of 2 clips", would that be ok?
>>
>> Yes, I think so.
>>
>> I would reconsider the order of the info though.
>>
>> Currently, I have the following output:
>> 'Track 1 1 of 1 clip ,   2 of 2' in Nvda
>
>
>> Firstly, the clip section is the most important part since it will
>> change more frequent than the track name part (especially with only
>> one track selected)
>
> Secondly, if the position of a list item is enabled in NVDA, it will
>> append the track's position at the end.
>
>
>> Therefore, it would be more logical to say
>> '1 of 1 clip, Track 1    2 of 2'
>> or even
>> '1 of 1 clip on Track 1    2 of 2'
>> and the panning added somewhere in between, if necessary:
>> '1 of 1 clip, left on Track 1    2 of 2'
>>
>> I think JAWS says the position info only if the track is defined as a
>> list item, rather than a table row.
>>
>
> I presume that the 2 of 2 bit is coming from your script. And yes, by
> default Jaws doesn't say the position info.

This info is independent from my script.
You can enable it within the object presentation dialog (NVDA+Control+O).
You have to check all boxes that have "Object" in them (apart from
"shortcut") in order to make it work.
I find it extremely useful for navigating the track list, especially
if you have multiple tracks with the same name, for instance after
duplicating.

>
> Currently, when only one track is selected, the track name is omitted (at
> least for mono tracks).

I've noticed it and the output with position info enabled is somewhat worse. ;)
However, if you really switch the order around, there won't be the
need for this exception and the track name could be added as well for
one selected track.
Not mandatory though.

Robert

> When I've got my code to say the correct info, it
> will be easy to change the order around.
>
>
>>
>> (BTW, I've just discovered how to prevent JAWS from saying "Table" in
>> front of each track. It would be nice if you added a section to your
>> JAWS guide about setting up JAWS subjectively best.)
>
>
>>
>> >
>> > When you say "I don't know how you want to solve the problem with
>> different
>> > length clips in a stereo track", what was the problem that you were
>> > referring to?
>>
>> I mean what the object depth should be within stereo tracks. Mouse
>> users have several options to move clips in a stereo track. Thus, the
>> problem is how you want to enable selecting only one clip in only one
>> channel of a stereo track.
>> The obvious way is to do it not at all since the stereo track can
>> always be exploded (split stereo track) and to move clips
>> independently afterwards.
>> So the question is what defines a movable unit in a stereo track with
>> odd length clips?
>
>
> Even using the mouse, it's not sure the current behaviour is what a user
> might expect, and my current code for moving clips doesn't do the same as
> the mouse when the clips are different. But as you say, it may well be
> simpler just to spit it, move stuff, and then reassemble,
>
> David.
>
>>
>> Robert
>>
>> >
>> > thanks,
>> > David.
>> >
>> >
>> >> Robert
>> >>
>> >> On 06/07/2017, David Bailes <[hidden email]> wrote:
>> >> > On Wed, Jul 5, 2017 at 10:25 AM, Robert Hänggi
>> >> > <[hidden email]>
>> >> > wrote:
>> >> >
>> >> >> Seems to work fine.
>> >> >> No problems with stereo or mono tracks.
>> >> >>
>> >> >
>> >> > thanks for checking.
>> >> >
>> >> >
>> >> >>
>> >> >> There is one thing I wonder about:
>> >> >> When commands act on a focused track then the undo action won't
>> >> >> take
>> >> >> that into account and the focus lands on the first track selected.
>> >> >>
>> >> >> So, if the tenth track is selected and I remove the forth track
>> (which
>> >> >> has focus), followed by an undo, the focus will be on the 10th
>> >> >> track
>> >> >> and not on the re-inserted forth track.
>> >> >> Same for e.g. a name change. If I made a typo and undo the name
>> >> >> change, the focus will land far away in the worst case.
>> >> >>
>> >> >> I think it would be worthwhile to save the focus along with
>> >> >> focus-specific commands on the undo stack.
>> >> >> This includes the context menu commands and also Pan/Gain.
>> >> >>
>> >> >> What do you think?
>> >> >>
>> >> >
>> >> > I agree that the current behaviour of how undo can affect the focus
>> >> > isn't
>> >> > right, and in fact there's an open bug on this issue:
>> >> > http://bugzilla.audacityteam.org/show_bug.cgi?id=510
>> >> >
>> >> > David.
>> >> >
>> >> >>
>> >> >> Robert
>> >> >>
>> >> >> On 04/07/2017, David Bailes <[hidden email]> wrote:
>> >> >> > The following commit is hopefully an improvement. I would be
>> >> >> > grateful
>> >> >> > for
>> >> >> > feedback from Robert and David.
>> >> >> > https://github.com/audacity/audacity/commit/
>> >> >> 4de3264d602683e5bed2b3277283465ffb72e3a7
>> >> >> >
>> >> >> > 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
>> >> >> [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: improvement for screen readers when removing a track

David Bailes-3
On Mon, Jul 10, 2017 at 3:05 PM, Robert Hänggi <[hidden email]> wrote:
On 10/07/2017, David Bailes <[hidden email]> wrote:
> On Mon, Jul 10, 2017 at 2:04 PM, Robert Hänggi <[hidden email]>
> wrote:
>
>> On 10/07/2017, David Bailes <[hidden email]> wrote:
>> > On Sun, Jul 9, 2017 at 2:12 PM, Robert Hänggi <[hidden email]>
>> > wrote:
>> >
>> >> Hi David
>> >>
>> >> Thanks for providing the bug ID.
>> >> It's a bit confusing since some of the issues are obviously fixed.
>> >> It might need a descendent bug with focus on focus...
>> >
>> >
>> >> Here's a somewhat related issue to doubled stereo track announcement
>> >> involving clips:
>> >>
>> >> Scenario: Two audio tracks, both stereo.
>> >> When nothing is selected and I navigate by clips, something like
>> >> "Vocals, Clip 1 of 2" will be spoken (i.e. is the temporary track
>> >> name).
>> >> However, it is spoken twice because of the stereo track.
>> >>
>> >> It is worse if the tracks have no name but the default.
>> >> For track 1 it speaks "Track 1 Clip 1 of 2, Track 2 Clip 1 of two"
>> >> For track 2 it speaks "Track 3 Clip 1 of 2, Track 4 Clip 1 of two"
>> >> The cause might be the track panel refactoring.
>> >>
>> >
>> > It's my mistake, forgot to test on stereo tracks. Sigh.
>> >
>> >>
>> >> I think that the double output should be avoided if the clips have the
>> >> same times in both channels.
>> >> Otherwise, the right iterator count and the panning should be spoken
>> >> (Left/Right or L/R).
>> >> However, I don't know how you want to solve the problem with different
>> >> length clips in a stereo track. It is not much of an issue for
>> >> navigation by previous/next clip boundary but it is certainly for
>> >> navigating by whole clips.
>> >>
>> >
>> > If the clips are different in the different channels, then when
>> > selecting
>> > next/previous clip,
>> > if it said something like:
>> > "Vocals, right, 1 of 2 clips", would that be ok?
>>
>> Yes, I think so.
>>
>> I would reconsider the order of the info though.
>>
>> Currently, I have the following output:
>> 'Track 1 1 of 1 clip ,   2 of 2' in Nvda
>
>
>> Firstly, the clip section is the most important part since it will
>> change more frequent than the track name part (especially with only
>> one track selected)
>
> Secondly, if the position of a list item is enabled in NVDA, it will
>> append the track's position at the end.
>
>
>> Therefore, it would be more logical to say
>> '1 of 1 clip, Track 1    2 of 2'
>> or even
>> '1 of 1 clip on Track 1    2 of 2'
>> and the panning added somewhere in between, if necessary:
>> '1 of 1 clip, left on Track 1    2 of 2'
>>
>> I think JAWS says the position info only if the track is defined as a
>> list item, rather than a table row.
>>
>
> I presume that the 2 of 2 bit is coming from your script. And yes, by
> default Jaws doesn't say the position info.

This info is independent from my script.
You can enable it within the object presentation dialog (NVDA+Control+O).
You have to check all boxes that have "Object" in them (apart from
"shortcut") in order to make it work.
I find it extremely useful for navigating the track list, especially
if you have multiple tracks with the same name, for instance after
duplicating.

Thanks for the info, I wasn't aware of this. 

>
> Currently, when only one track is selected, the track name is omitted (at
> least for mono tracks).

I've noticed it and the output with position info enabled is somewhat worse. ;)
However, if you really switch the order around, there won't be the
need for this exception and the track name could be added as well for
one selected track.
Not mandatory though.

I've sorted out the stereo track stuff:

Is that OK?
I've still got to sort out stereo tracks for the command to move/select clip boundaries,

David.
 

Robert

> When I've got my code to say the correct info, it
> will be easy to change the order around.
>
>
>>
>> (BTW, I've just discovered how to prevent JAWS from saying "Table" in
>> front of each track. It would be nice if you added a section to your
>> JAWS guide about setting up JAWS subjectively best.)
>
>
>>
>> >
>> > When you say "I don't know how you want to solve the problem with
>> different
>> > length clips in a stereo track", what was the problem that you were
>> > referring to?
>>
>> I mean what the object depth should be within stereo tracks. Mouse
>> users have several options to move clips in a stereo track. Thus, the
>> problem is how you want to enable selecting only one clip in only one
>> channel of a stereo track.
>> The obvious way is to do it not at all since the stereo track can
>> always be exploded (split stereo track) and to move clips
>> independently afterwards.
>> So the question is what defines a movable unit in a stereo track with
>> odd length clips?
>
>
> Even using the mouse, it's not sure the current behaviour is what a user
> might expect, and my current code for moving clips doesn't do the same as
> the mouse when the clips are different. But as you say, it may well be
> simpler just to spit it, move stuff, and then reassemble,
>
> David.
>
>>
>> Robert
>>
>> >
>> > thanks,
>> > David.
>> >
>> >
>> >> Robert
>> >>
>> >> On 06/07/2017, David Bailes <[hidden email]> wrote:
>> >> > On Wed, Jul 5, 2017 at 10:25 AM, Robert Hänggi
>> >> > <[hidden email]>
>> >> > wrote:
>> >> >
>> >> >> Seems to work fine.
>> >> >> No problems with stereo or mono tracks.
>> >> >>
>> >> >
>> >> > thanks for checking.
>> >> >
>> >> >
>> >> >>
>> >> >> There is one thing I wonder about:
>> >> >> When commands act on a focused track then the undo action won't
>> >> >> take
>> >> >> that into account and the focus lands on the first track selected.
>> >> >>
>> >> >> So, if the tenth track is selected and I remove the forth track
>> (which
>> >> >> has focus), followed by an undo, the focus will be on the 10th
>> >> >> track
>> >> >> and not on the re-inserted forth track.
>> >> >> Same for e.g. a name change. If I made a typo and undo the name
>> >> >> change, the focus will land far away in the worst case.
>> >> >>
>> >> >> I think it would be worthwhile to save the focus along with
>> >> >> focus-specific commands on the undo stack.
>> >> >> This includes the context menu commands and also Pan/Gain.
>> >> >>
>> >> >> What do you think?
>> >> >>
>> >> >
>> >> > I agree that the current behaviour of how undo can affect the focus
>> >> > isn't
>> >> > right, and in fact there's an open bug on this issue:
>> >> > http://bugzilla.audacityteam.org/show_bug.cgi?id=510
>> >> >
>> >> > David.
>> >> >
>> >> >>
>> >> >> Robert
>> >> >>
>> >> >> On 04/07/2017, David Bailes <[hidden email]> wrote:
>> >> >> > The following commit is hopefully an improvement. I would be
>> >> >> > grateful
>> >> >> > for
>> >> >> > feedback from Robert and David.
>> >> >> > https://github.com/audacity/audacity/commit/
>> >> >> 4de3264d602683e5bed2b3277283465ffb72e3a7
>> >> >> >
>> >> >> > 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
>> >> >> [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: improvement for screen readers when removing a track

David Bailes-3
On Tue, Jul 11, 2017 at 11:42 AM, David Bailes <[hidden email]> wrote:
On Mon, Jul 10, 2017 at 3:05 PM, Robert Hänggi <[hidden email]> wrote:
On 10/07/2017, David Bailes <[hidden email]> wrote:
> On Mon, Jul 10, 2017 at 2:04 PM, Robert Hänggi <[hidden email]>
> wrote:
>
>> On 10/07/2017, David Bailes <[hidden email]> wrote:
>> > On Sun, Jul 9, 2017 at 2:12 PM, Robert Hänggi <[hidden email]>
>> > wrote:
>> >
>> >> Hi David
>> >>
>> >> Thanks for providing the bug ID.
>> >> It's a bit confusing since some of the issues are obviously fixed.
>> >> It might need a descendent bug with focus on focus...
>> >
>> >
>> >> Here's a somewhat related issue to doubled stereo track announcement
>> >> involving clips:
>> >>
>> >> Scenario: Two audio tracks, both stereo.
>> >> When nothing is selected and I navigate by clips, something like
>> >> "Vocals, Clip 1 of 2" will be spoken (i.e. is the temporary track
>> >> name).
>> >> However, it is spoken twice because of the stereo track.
>> >>
>> >> It is worse if the tracks have no name but the default.
>> >> For track 1 it speaks "Track 1 Clip 1 of 2, Track 2 Clip 1 of two"
>> >> For track 2 it speaks "Track 3 Clip 1 of 2, Track 4 Clip 1 of two"
>> >> The cause might be the track panel refactoring.
>> >>
>> >
>> > It's my mistake, forgot to test on stereo tracks. Sigh.
>> >
>> >>
>> >> I think that the double output should be avoided if the clips have the
>> >> same times in both channels.
>> >> Otherwise, the right iterator count and the panning should be spoken
>> >> (Left/Right or L/R).
>> >> However, I don't know how you want to solve the problem with different
>> >> length clips in a stereo track. It is not much of an issue for
>> >> navigation by previous/next clip boundary but it is certainly for
>> >> navigating by whole clips.
>> >>
>> >
>> > If the clips are different in the different channels, then when
>> > selecting
>> > next/previous clip,
>> > if it said something like:
>> > "Vocals, right, 1 of 2 clips", would that be ok?
>>
>> Yes, I think so.
>>
>> I would reconsider the order of the info though.
>>
>> Currently, I have the following output:
>> 'Track 1 1 of 1 clip ,   2 of 2' in Nvda
>
>
>> Firstly, the clip section is the most important part since it will
>> change more frequent than the track name part (especially with only
>> one track selected)
>
> Secondly, if the position of a list item is enabled in NVDA, it will
>> append the track's position at the end.
>
>
>> Therefore, it would be more logical to say
>> '1 of 1 clip, Track 1    2 of 2'
>> or even
>> '1 of 1 clip on Track 1    2 of 2'
>> and the panning added somewhere in between, if necessary:
>> '1 of 1 clip, left on Track 1    2 of 2'
>>
>> I think JAWS says the position info only if the track is defined as a
>> list item, rather than a table row.
>>
>
> I presume that the 2 of 2 bit is coming from your script. And yes, by
> default Jaws doesn't say the position info.

This info is independent from my script.
You can enable it within the object presentation dialog (NVDA+Control+O).
You have to check all boxes that have "Object" in them (apart from
"shortcut") in order to make it work.
I find it extremely useful for navigating the track list, especially
if you have multiple tracks with the same name, for instance after
duplicating.

Thanks for the info, I wasn't aware of this. 

>
> Currently, when only one track is selected, the track name is omitted (at
> least for mono tracks).

I've noticed it and the output with position info enabled is somewhat worse. ;)
However, if you really switch the order around, there won't be the
need for this exception and the track name could be added as well for
one selected track.
Not mandatory though.

I've sorted out the stereo track stuff:

Is that OK?
I've still got to sort out stereo tracks for the command to move/select clip boundaries,

I've also sorted out the clip boundary commands:

David.
 

David.
 

Robert

> When I've got my code to say the correct info, it
> will be easy to change the order around.
>
>
>>
>> (BTW, I've just discovered how to prevent JAWS from saying "Table" in
>> front of each track. It would be nice if you added a section to your
>> JAWS guide about setting up JAWS subjectively best.)
>
>
>>
>> >
>> > When you say "I don't know how you want to solve the problem with
>> different
>> > length clips in a stereo track", what was the problem that you were
>> > referring to?
>>
>> I mean what the object depth should be within stereo tracks. Mouse
>> users have several options to move clips in a stereo track. Thus, the
>> problem is how you want to enable selecting only one clip in only one
>> channel of a stereo track.
>> The obvious way is to do it not at all since the stereo track can
>> always be exploded (split stereo track) and to move clips
>> independently afterwards.
>> So the question is what defines a movable unit in a stereo track with
>> odd length clips?
>
>
> Even using the mouse, it's not sure the current behaviour is what a user
> might expect, and my current code for moving clips doesn't do the same as
> the mouse when the clips are different. But as you say, it may well be
> simpler just to spit it, move stuff, and then reassemble,
>
> David.
>
>>
>> Robert
>>
>> >
>> > thanks,
>> > David.
>> >
>> >
>> >> Robert
>> >>
>> >> On 06/07/2017, David Bailes <[hidden email]> wrote:
>> >> > On Wed, Jul 5, 2017 at 10:25 AM, Robert Hänggi
>> >> > <[hidden email]>
>> >> > wrote:
>> >> >
>> >> >> Seems to work fine.
>> >> >> No problems with stereo or mono tracks.
>> >> >>
>> >> >
>> >> > thanks for checking.
>> >> >
>> >> >
>> >> >>
>> >> >> There is one thing I wonder about:
>> >> >> When commands act on a focused track then the undo action won't
>> >> >> take
>> >> >> that into account and the focus lands on the first track selected.
>> >> >>
>> >> >> So, if the tenth track is selected and I remove the forth track
>> (which
>> >> >> has focus), followed by an undo, the focus will be on the 10th
>> >> >> track
>> >> >> and not on the re-inserted forth track.
>> >> >> Same for e.g. a name change. If I made a typo and undo the name
>> >> >> change, the focus will land far away in the worst case.
>> >> >>
>> >> >> I think it would be worthwhile to save the focus along with
>> >> >> focus-specific commands on the undo stack.
>> >> >> This includes the context menu commands and also Pan/Gain.
>> >> >>
>> >> >> What do you think?
>> >> >>
>> >> >
>> >> > I agree that the current behaviour of how undo can affect the focus
>> >> > isn't
>> >> > right, and in fact there's an open bug on this issue:
>> >> > http://bugzilla.audacityteam.org/show_bug.cgi?id=510
>> >> >
>> >> > David.
>> >> >
>> >> >>
>> >> >> Robert
>> >> >>
>> >> >> On 04/07/2017, David Bailes <[hidden email]> wrote:
>> >> >> > The following commit is hopefully an improvement. I would be
>> >> >> > grateful
>> >> >> > for
>> >> >> > feedback from Robert and David.
>> >> >> > https://github.com/audacity/audacity/commit/
>> >> >> 4de3264d602683e5bed2b3277283465ffb72e3a7
>> >> >> >
>> >> >> > 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
>> >> >> [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: improvement for screen readers when removing a track

Robert Hänggi
Thanks David

I will look at it.
I did not build lately due to the many crashes/failures  and thought
to wait a bit...

Best
Robert

On 11/07/2017, David Bailes <[hidden email]> wrote:

> On Tue, Jul 11, 2017 at 11:42 AM, David Bailes <[hidden email]> wrote:
>
>> On Mon, Jul 10, 2017 at 3:05 PM, Robert Hänggi <[hidden email]>
>> wrote:
>>
>>> On 10/07/2017, David Bailes <[hidden email]> wrote:
>>> > On Mon, Jul 10, 2017 at 2:04 PM, Robert Hänggi
>>> > <[hidden email]
>>> >
>>> > wrote:
>>> >
>>> >> On 10/07/2017, David Bailes <[hidden email]> wrote:
>>> >> > On Sun, Jul 9, 2017 at 2:12 PM, Robert Hänggi <
>>> [hidden email]>
>>> >> > wrote:
>>> >> >
>>> >> >> Hi David
>>> >> >>
>>> >> >> Thanks for providing the bug ID.
>>> >> >> It's a bit confusing since some of the issues are obviously fixed.
>>> >> >> It might need a descendent bug with focus on focus...
>>> >> >
>>> >> >
>>> >> >> Here's a somewhat related issue to doubled stereo track
>>> >> >> announcement
>>> >> >> involving clips:
>>> >> >>
>>> >> >> Scenario: Two audio tracks, both stereo.
>>> >> >> When nothing is selected and I navigate by clips, something like
>>> >> >> "Vocals, Clip 1 of 2" will be spoken (i.e. is the temporary track
>>> >> >> name).
>>> >> >> However, it is spoken twice because of the stereo track.
>>> >> >>
>>> >> >> It is worse if the tracks have no name but the default.
>>> >> >> For track 1 it speaks "Track 1 Clip 1 of 2, Track 2 Clip 1 of two"
>>> >> >> For track 2 it speaks "Track 3 Clip 1 of 2, Track 4 Clip 1 of two"
>>> >> >> The cause might be the track panel refactoring.
>>> >> >>
>>> >> >
>>> >> > It's my mistake, forgot to test on stereo tracks. Sigh.
>>> >> >
>>> >> >>
>>> >> >> I think that the double output should be avoided if the clips have
>>> the
>>> >> >> same times in both channels.
>>> >> >> Otherwise, the right iterator count and the panning should be
>>> >> >> spoken
>>> >> >> (Left/Right or L/R).
>>> >> >> However, I don't know how you want to solve the problem with
>>> different
>>> >> >> length clips in a stereo track. It is not much of an issue for
>>> >> >> navigation by previous/next clip boundary but it is certainly for
>>> >> >> navigating by whole clips.
>>> >> >>
>>> >> >
>>> >> > If the clips are different in the different channels, then when
>>> >> > selecting
>>> >> > next/previous clip,
>>> >> > if it said something like:
>>> >> > "Vocals, right, 1 of 2 clips", would that be ok?
>>> >>
>>> >> Yes, I think so.
>>> >>
>>> >> I would reconsider the order of the info though.
>>> >>
>>> >> Currently, I have the following output:
>>> >> 'Track 1 1 of 1 clip ,   2 of 2' in Nvda
>>> >
>>> >
>>> >> Firstly, the clip section is the most important part since it will
>>> >> change more frequent than the track name part (especially with only
>>> >> one track selected)
>>> >
>>> > Secondly, if the position of a list item is enabled in NVDA, it will
>>> >> append the track's position at the end.
>>> >
>>> >
>>> >> Therefore, it would be more logical to say
>>> >> '1 of 1 clip, Track 1    2 of 2'
>>> >> or even
>>> >> '1 of 1 clip on Track 1    2 of 2'
>>> >> and the panning added somewhere in between, if necessary:
>>> >> '1 of 1 clip, left on Track 1    2 of 2'
>>> >>
>>> >> I think JAWS says the position info only if the track is defined as a
>>> >> list item, rather than a table row.
>>> >>
>>> >
>>> > I presume that the 2 of 2 bit is coming from your script. And yes, by
>>> > default Jaws doesn't say the position info.
>>>
>>> This info is independent from my script.
>>> You can enable it within the object presentation dialog
>>> (NVDA+Control+O).
>>> You have to check all boxes that have "Object" in them (apart from
>>> "shortcut") in order to make it work.
>>> I find it extremely useful for navigating the track list, especially
>>> if you have multiple tracks with the same name, for instance after
>>> duplicating.
>>>
>>
>> Thanks for the info, I wasn't aware of this.
>>
>>>
>>> >
>>> > Currently, when only one track is selected, the track name is omitted
>>> (at
>>> > least for mono tracks).
>>>
>>> I've noticed it and the output with position info enabled is somewhat
>>> worse. ;)
>>> However, if you really switch the order around, there won't be the
>>> need for this exception and the track name could be added as well for
>>> one selected track.
>>> Not mandatory though.
>>>
>>
>> I've sorted out the stereo track stuff:
>> https://github.com/audacity/audacity/commit/71a75fc28dc9f07a5fda90028f4ffa
>> 4b31e770b1
>>
>> Is that OK?
>> I've still got to sort out stereo tracks for the command to move/select
>> clip boundaries,
>>
>
> I've also sorted out the clip boundary commands:
> https://github.com/audacity/audacity/commit/71ac4bb2f5d66be1e51d55936647cfc88c6c7f99
>
> David.
>
>
>>
>> David.
>>
>>
>>>
>>> Robert
>>>
>>> > When I've got my code to say the correct info, it
>>> > will be easy to change the order around.
>>> >
>>> >
>>> >>
>>> >> (BTW, I've just discovered how to prevent JAWS from saying "Table" in
>>> >> front of each track. It would be nice if you added a section to your
>>> >> JAWS guide about setting up JAWS subjectively best.)
>>> >
>>> >
>>> >>
>>> >> >
>>> >> > When you say "I don't know how you want to solve the problem with
>>> >> different
>>> >> > length clips in a stereo track", what was the problem that you were
>>> >> > referring to?
>>> >>
>>> >> I mean what the object depth should be within stereo tracks. Mouse
>>> >> users have several options to move clips in a stereo track. Thus, the
>>> >> problem is how you want to enable selecting only one clip in only one
>>> >> channel of a stereo track.
>>> >> The obvious way is to do it not at all since the stereo track can
>>> >> always be exploded (split stereo track) and to move clips
>>> >> independently afterwards.
>>> >> So the question is what defines a movable unit in a stereo track with
>>> >> odd length clips?
>>> >
>>> >
>>> > Even using the mouse, it's not sure the current behaviour is what a
>>> > user
>>> > might expect, and my current code for moving clips doesn't do the same
>>> as
>>> > the mouse when the clips are different. But as you say, it may well be
>>> > simpler just to spit it, move stuff, and then reassemble,
>>> >
>>> > David.
>>> >
>>> >>
>>> >> Robert
>>> >>
>>> >> >
>>> >> > thanks,
>>> >> > David.
>>> >> >
>>> >> >
>>> >> >> Robert
>>> >> >>
>>> >> >> On 06/07/2017, David Bailes <[hidden email]> wrote:
>>> >> >> > On Wed, Jul 5, 2017 at 10:25 AM, Robert Hänggi
>>> >> >> > <[hidden email]>
>>> >> >> > wrote:
>>> >> >> >
>>> >> >> >> Seems to work fine.
>>> >> >> >> No problems with stereo or mono tracks.
>>> >> >> >>
>>> >> >> >
>>> >> >> > thanks for checking.
>>> >> >> >
>>> >> >> >
>>> >> >> >>
>>> >> >> >> There is one thing I wonder about:
>>> >> >> >> When commands act on a focused track then the undo action won't
>>> >> >> >> take
>>> >> >> >> that into account and the focus lands on the first track
>>> selected.
>>> >> >> >>
>>> >> >> >> So, if the tenth track is selected and I remove the forth track
>>> >> (which
>>> >> >> >> has focus), followed by an undo, the focus will be on the 10th
>>> >> >> >> track
>>> >> >> >> and not on the re-inserted forth track.
>>> >> >> >> Same for e.g. a name change. If I made a typo and undo the name
>>> >> >> >> change, the focus will land far away in the worst case.
>>> >> >> >>
>>> >> >> >> I think it would be worthwhile to save the focus along with
>>> >> >> >> focus-specific commands on the undo stack.
>>> >> >> >> This includes the context menu commands and also Pan/Gain.
>>> >> >> >>
>>> >> >> >> What do you think?
>>> >> >> >>
>>> >> >> >
>>> >> >> > I agree that the current behaviour of how undo can affect the
>>> focus
>>> >> >> > isn't
>>> >> >> > right, and in fact there's an open bug on this issue:
>>> >> >> > http://bugzilla.audacityteam.org/show_bug.cgi?id=510
>>> >> >> >
>>> >> >> > David.
>>> >> >> >
>>> >> >> >>
>>> >> >> >> Robert
>>> >> >> >>
>>> >> >> >> On 04/07/2017, David Bailes <[hidden email]> wrote:
>>> >> >> >> > The following commit is hopefully an improvement. I would be
>>> >> >> >> > grateful
>>> >> >> >> > for
>>> >> >> >> > feedback from Robert and David.
>>> >> >> >> > https://github.com/audacity/audacity/commit/
>>> >> >> >> 4de3264d602683e5bed2b3277283465ffb72e3a7
>>> >> >> >> >
>>> >> >> >> > 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
>>> >> >> >> [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...