Audacity

On 21 May 2013 10:03, David Bailes <drbailes@...> wrote:
> On Sun, May 19, 2013 at 12:05 PM, Gale Andrews <gale@...>
> wrote:
>>
>>
>>
>> David wrote
>>  >> (In passing, for keyboard users, a greater problem than the number of
>> > >> items, is that shortcuts can't be assigned to these commands. So for
>> > >> align
>> > >> with cursor you have to press alt, t, a, c, rather than a more
>> > >> convenient
>> > >> shortcut. Unfortunately the code doesn't create commands that then
>> > >> appear
>> > >> in the keyboard shortcuts.)
>>
>> Is the true of all the "Align Tracks" and "Align and Move Cursor"
>> sub-items?
>>
>> Any other menu groups affected?
>
>
> Hi Gale, I appear to be loosing my marbles. I misunderstood your reply to
> robbie on the audacity4blind mailing list in march 2012 when he was asking
> whether "align with cursor" was available in the exported xml file for
> keyboard shortcuts. It isn't, but all the align commands can be set in the
> keyboard category of preferences - I hadn't realised this. One minor problem
> is that the two sets of commands (with or without moving the cursor) have
> the same names, which is confusing.

They both use the same sub-menu ("Align Together" is excluded from the
"and Move Cursor" menu).

If we changed this then the "and Move" menu would need its own sub
menu rather than reusing the "Align Tracks" sub menu which makes the
code a bit bulkier, is more to maintain, but the biggest issue is that
different names would need to be given to the functions.

I'm not very keen on
"Align Start to Selection Start or Cursor"
as the name of a menu item due to its length, but
"Align Start and Move Cursor to Selection Start or Cursor"
is imo unacceptably long.

When I'm looking for an item in a menu, I want  to be able to quickly
scan down a list of short but meaningful command names and pick out
the appropriate one. I don't want to read a functional description of
each option. If I'm unsure exactly what a function does then I can
either try it out and discover for myself, or look it up in the
manual.

Looking in other applications it is unusual to have menu commands that
have names that are more than 3 words. Firefox has two menu commands
that have 4 words and all of the other command names of 3 or less
words (mostly one or two words). kDevelop is a complex program with a
very extensive menu system, but even that program has only 2 menu
commands with 5 words - all the rest are shorter and the vast majority
have two words. In contrast, Audacity, with its fairly modest number
of menu items (not including plug-ins) currently has 25 menu commands
with 4 or more words.

Good design should be concise. Imo overly long names are ugly,
confusing, look complicated, make it harder to find the command that
you are looking for, and are a nightmare for anyone that has dyslexia
(or even mild reading difficulty).

Steve


>
> I presume this means that some of these commands could have pre-assigned
> shortcuts - align to selection start / cursor is probably the most important
> one. This would be really useful. May take some time to decide on a shortcut
> though...
>
> The only other commands which I'm aware of which really can't be assigned
> shortcuts and have been mentioned on the audacity4blind list are for moving
> tracks up and down.
>
> David.

| From Steve the Fiddle <stevethefiddle@...> 
| Tue, 21 May 2013 19:53:03 +0100
| Subject: [Audacity-quality] Align Tracks Together (with labels)
> On 21 May 2013 10:03, David Bailes <drbailes@...> wrote:
> > On Sun, May 19, 2013 at 12:05 PM, Gale Andrews <gale@...>
> > wrote:
[...]

> I'm not very keen on
> "Align Start to Selection Start or Cursor"
> as the name of a menu item due to its length

Adding the word "Start" barely increases the overall width
of the sub-menu, given the other items. 


> "Align Start and Move Cursor to Selection Start or Cursor"
> is imo unacceptably long.

I agree, but I wasn't asking for that. I assume the "Align and
Move Cursor" sub-menu commands would be identical to the 
"Align Tracks" sub-menu commands, as now. 

But I think the second menu item could be called "Align Tracks 
and Move Cursor" for clarity. 

 
> When I'm looking for an item in a menu, I want  to be able to quickly
> scan down a list of short but meaningful command names and pick out
> the appropriate one. I don't want to read a functional description of
> each option. If I'm unsure exactly what a function does then I can
> either try it out and discover for myself, or look it up in the
> manual.

Yes but normal users probably don't try things out and certainly
don't read the Manual. How many times do we point users to
those Align commands and they say, yes they are useful, but 
they did not understand them so did not try them?

It's always a balance of brevity and clarity. I'm quite sure "Align
to" is not ideally clear, though I think it's just about acceptable.

"From" is not acceptable IMO. It's confusing, and it's a name 
change (for the worse) when the functionality has not changed. 

 
> Looking in other applications it is unusual to have menu commands that
> have names that are more than 3 words. Firefox has two menu commands
> that have 4 words and all of the other command names of 3 or less
> words (mostly one or two words). kDevelop is a complex program with a
> very extensive menu system, but even that program has only 2 menu
> commands with 5 words - all the rest are shorter and the vast majority
> have two words. In contrast, Audacity, with its fairly modest number
> of menu items (not including plug-ins) currently has 25 menu commands
> with 4 or more words.

I suggest kDevelop is irrelevant to our discussions - it's not an
app for normal users.


> Good design should be concise. Imo overly long names are ugly,
> confusing, look complicated, make it harder to find the command that
> you are looking for, and are a nightmare for anyone that has dyslexia
> (or even mild reading difficulty). 

I agree in principle, but these align commands are not easy to 
understand and are trying to push a lot of commands into the  
sub-menu.  There are no menu items of comparable complexity 
in Firefox.

If you don't repeat the word from the menu item in the 
sub-menu items, then when you have a sub menu with eight or 
more items the greater danger is losing the plot of what the 
commands do by the time you get to the bottom of the list.

And then if you have a menu item underneath that does the 
same (align) and one thing extra (move cursor), it gets 
really unclear if you don't have "Align" in that submenu.   

"Or" is only one character more then "/".

And "to" is less characters than "from". 



Gale

On 21 May 2013 21:08, Gale Andrews <gale@...> wrote:
>
> | From Steve the Fiddle <stevethefiddle@...>
> | Tue, 21 May 2013 19:53:03 +0100
> | Subject: [Audacity-quality] Align Tracks Together (with labels)
>> On 21 May 2013 10:03, David Bailes <drbailes@...> wrote:
>> > On Sun, May 19, 2013 at 12:05 PM, Gale Andrews <gale@...>
>> > wrote:
> [...]
>
>> I'm not very keen on
>> "Align Start to Selection Start or Cursor"
>> as the name of a menu item due to its length
>
> Adding the word "Start" barely increases the overall width
> of the sub-menu, given the other items.
>
>
>> "Align Start and Move Cursor to Selection Start or Cursor"
>> is imo unacceptably long.
>
> I agree, but I wasn't asking for that. I assume the "Align and
> Move Cursor" sub-menu commands would be identical to the
> "Align Tracks" sub-menu commands, as now.

David was complaining that the command names were the same, so it is
difficult to distinguish in the keyboard preferences whether a command
is part of the "Align Tracks" sub menu or the "Align and Move" sub
menu. To resolve that problem the names in "Align and Move" would need
to be distinctly different to the names in "Align Tracks".


>
> But I think the second menu item could be called "Align Tracks
> and Move Cursor" for clarity.
>
>
>> When I'm looking for an item in a menu, I want  to be able to quickly
>> scan down a list of short but meaningful command names and pick out
>> the appropriate one. I don't want to read a functional description of
>> each option. If I'm unsure exactly what a function does then I can
>> either try it out and discover for myself, or look it up in the
>> manual.
>
> Yes but normal users probably don't try things out and certainly
> don't read the Manual. How many times do we point users to
> those Align commands and they say, yes they are useful, but
> they did not understand them so did not try them?
>
> It's always a balance of brevity and clarity. I'm quite sure "Align
> to" is not ideally clear, though I think it's just about acceptable.
>
> "From" is not acceptable IMO. It's confusing, and it's a name
> change (for the worse) when the functionality has not changed.

Perhaps it a regional dialect thing, but to me "from" indicates a
starting point ("where have you come from?") and "to" indicates a
detination ("where are you going to?").

The ".... zero" alignment starts at zero.
"From only $1.99" means that the starting price is $1.99.

I don't see the confusion - to me it seems a lot more clear than
aligning "with", which in itself gives no indication whether the
alignment goes up to the alignment point or proceeds from the
alignment point, thus requiring additional words to specify which is
meant.



>
>
>> Looking in other applications it is unusual to have menu commands that
>> have names that are more than 3 words. Firefox has two menu commands
>> that have 4 words and all of the other command names of 3 or less
>> words (mostly one or two words). kDevelop is a complex program with a
>> very extensive menu system, but even that program has only 2 menu
>> commands with 5 words - all the rest are shorter and the vast majority
>> have two words. In contrast, Audacity, with its fairly modest number
>> of menu items (not including plug-ins) currently has 25 menu commands
>> with 4 or more words.
>
> I suggest kDevelop is irrelevant to our discussions - it's not an
> app for normal users.

It was a "random" example that happened to be in front of my nose.
Other examples:
* Gimp: the longest menu item is 4 words,
* Internet Explorer 8 has one occurrence of a 6 word item ("What's New
in Internet Explorer 8") and the next longest is 4 words,
* Foobar2000 has one 5 word item, one 4 word item and the rest are 3
words or less.

Audacity is conspicuously more verbose than other programs.

Steve

>
>
>> Good design should be concise. Imo overly long names are ugly,
>> confusing, look complicated, make it harder to find the command that
>> you are looking for, and are a nightmare for anyone that has dyslexia
>> (or even mild reading difficulty).
>
> I agree in principle, but these align commands are not easy to
> understand and are trying to push a lot of commands into the
> sub-menu.  There are no menu items of comparable complexity
> in Firefox.
>
> If you don't repeat the word from the menu item in the
> sub-menu items, then when you have a sub menu with eight or
> more items the greater danger is losing the plot of what the
> commands do by the time you get to the bottom of the list.
>
> And then if you have a menu item underneath that does the
> same (align) and one thing extra (move cursor), it gets
> really unclear if you don't have "Align" in that submenu.
>
> "Or" is only one character more then "/".
>
> And "to" is less characters than "from".
>
>
>
> Gale
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Audacity-quality mailing list
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

On 5/21/2013 2:10 PM, Steve the Fiddle wrote:
> On 21 May 2013 21:08, Gale Andrews <gale@...> wrote:
>>
>> | From Steve the Fiddle <stevethefiddle@...>
>> | Tue, 21 May 2013 19:53:03 +0100
>> | Subject: [Audacity-quality] Align Tracks Together (with labels)
>>> On 21 May 2013 10:03, David Bailes <drbailes@...> wrote:
>>>> On Sun, May 19, 2013 at 12:05 PM, Gale Andrews <gale@...>
>>>> wrote:
>> [...]
>>
>>> I'm not very keen on
>>> "Align Start to Selection Start or Cursor"
>>> as the name of a menu item due to its length
>>
>> Adding the word "Start" barely increases the overall width
>> of the sub-menu, given the other items.

There's agreement on "Align End...", right? So having "Start" is more 
clearly paired with that, even though I would assume align is referring 
to the start.


>>...
>>> Looking in other applications it is unusual to have menu commands that
>>> have names that are more than 3 words. Firefox has two menu commands
>>> that have 4 words and all of the other command names of 3 or less
>>> words (mostly one or two words). kDevelop is a complex program with a
>>> very extensive menu system, but even that program has only 2 menu
>>> commands with 5 words - all the rest are shorter and the vast majority
>>> have two words. In contrast, Audacity, with its fairly modest number
>>> of menu items (not including plug-ins) currently has 25 menu commands
>>> with 4 or more words.
>>
>> I suggest kDevelop is irrelevant to our discussions - it's not an
>> app for normal users.
>
> It was a "random" example that happened to be in front of my nose.
> Other examples:
> * Gimp: the longest menu item is 4 words,
> * Internet Explorer 8 has one occurrence of a 6 word item ("What's New
> in Internet Explorer 8") and the next longest is 4 words,
> * Foobar2000 has one 5 word item, one 4 word item and the rest are 3
> words or less.

Other counts of menu items.

* Thunderbird has 4, 5, and 6-word menu items. With Lightning, it even 
has a 3-word menu title.

* iTunes has several 4-word.

* OpenOffice Calc has several 4-word.

* Filezilla has several 5-word.

* Windows Media Player has several 6-word.


>
> Audacity is conspicuously more verbose than other programs.
>

I don't think you've proven that by citing 5 apps. I overall agree with 
you, but I think there's justification for it when we're offering lots 
of editing commands that have subtle differences.

This argument about one word in a menu item, sure is verbose, to say 
nothing of the whole thread, which doesn't really seem to be coming to 
resolution. :-(

- V

On Tue, May 21, 2013 at 7:53 PM, Steve the Fiddle
<stevethefiddle@...:

> On 21 May 2013 10:03, David Bailes <drbailes@...> wrote:
>
> >
> > Hi Gale, I appear to be loosing my marbles. I misunderstood your reply to
> > robbie on the audacity4blind mailing list in march 2012 when he was
> asking
> > whether "align with cursor" was available in the exported xml file for
> > keyboard shortcuts. It isn't, but all the align commands can be set in
> the
> > keyboard category of preferences - I hadn't realised this. One minor
> problem
> > is that the two sets of commands (with or without moving the cursor) have
> > the same names, which is confusing.
>
> They both use the same sub-menu ("Align Together" is excluded from the
> "and Move Cursor" menu).
>
> If we changed this then the "and Move" menu would need its own sub
> menu rather than reusing the "Align Tracks" sub menu which makes the
> code a bit bulkier, is more to maintain, but the biggest issue is that
> different names would need to be given to the functions.
>

I think that it's ok for the commands in the two sub-menus to have the same
labels. I think that the confusion in the keyboad prefs should be sorted
out there (at some point).

Also, if on the align tracks menu, both align to/with/from(!) cursor and
align end to end both had predefined shortcuts, then not many people would
need to assign these in keyboard prefs anyway.

There seems to be a couple of issues about shortcuts in the align tracks
sub-menu:

1. If I assign a keyboard shortcut in preferences, the shortcut works, but
doesn't show up after the command in the sub-menu. Assigning a shortcut for
a command in the effects menu shows up in the menu, but I don't know why.

2. I'm not sure what code is needed to set up predefined shortcuts in the
align tracks sub-menu. I had a go using SetKeyFromName, using the name
"Align:Align with &Cursor" for the command (this is without your patch
applied) and had no joy.

David.

On 22 May 2013 12:58, David Bailes <drbailes@...> wrote:
> On Tue, May 21, 2013 at 7:53 PM, Steve the Fiddle <stevethefiddle@...>
> wrote:
>>
>> On 21 May 2013 10:03, David Bailes <drbailes@...> wrote:
>>
>> >
>> > Hi Gale, I appear to be loosing my marbles. I misunderstood your reply
>> > to
>> > robbie on the audacity4blind mailing list in march 2012 when he was
>> > asking
>> > whether "align with cursor" was available in the exported xml file for
>> > keyboard shortcuts. It isn't, but all the align commands can be set in
>> > the
>> > keyboard category of preferences - I hadn't realised this. One minor
>> > problem
>> > is that the two sets of commands (with or without moving the cursor)
>> > have
>> > the same names, which is confusing.
>>
>> They both use the same sub-menu ("Align Together" is excluded from the
>> "and Move Cursor" menu).
>>
>> If we changed this then the "and Move" menu would need its own sub
>> menu rather than reusing the "Align Tracks" sub menu which makes the
>> code a bit bulkier, is more to maintain, but the biggest issue is that
>> different names would need to be given to the functions.
>
>
> I think that it's ok for the commands in the two sub-menus to have the same
> labels. I think that the confusion in the keyboad prefs should be sorted out
> there (at some point).
>
> Also, if on the align tracks menu, both align to/with/from(!) cursor and
> align end to end both had predefined shortcuts, then not many people would
> need to assign these in keyboard prefs anyway.
>
> There seems to be a couple of issues about shortcuts in the align tracks
> sub-menu:
>
> 1. If I assign a keyboard shortcut in preferences, the shortcut works, but
> doesn't show up after the command in the sub-menu. Assigning a shortcut for
> a command in the effects menu shows up in the menu, but I don't know why.

The problem is that it's because "alignLabels" is a list of commands
that is shared by two sub-menus ("Align Tracks" and "Align Move"), so
when an access key is allocated to one of the list items, the menu
does not know which occurrence of that item in the menu should have
the shortcut assigned to it. In other words, the menu list needs to be
unique to one menu item.

This problem can be fixed by creating a separate menu list for the
"Align/Move" sub-menu so that it is not sharing the same list as
"Align Tracks". This can also fix the problem in the keyboard
preferences as the menu items can then have unique names. The question
then is: what names.

The best that I've come up with is:
"Tracks > Align Tracks > Align Start to ...."
"Tracks > Align and Move Cursor > Move Start to ...."

Assuming that I've not missed errors in my code, this patch solves
multiple problems, adds a very useful new feature, and I can live with
the command names.

I think this patch will benefit translation hints. I'm not familiar
with translation hints so could someone else do that?

Steve


>
> 2. I'm not sure what code is needed to set up predefined shortcuts in the
> align tracks sub-menu. I had a go using SetKeyFromName, using the name
> "Align:Align with &Cursor" for the command (this is without your patch
> applied) and had no joy.
>
> David.

On Wed, May 22, 2013 at 2:40 PM, Steve the Fiddle
<stevethefiddle@...:

> On 22 May 2013 12:58, David Bailes <drbailes@...> wrote:
> > On Tue, May 21, 2013 at 7:53 PM, Steve the Fiddle <
> stevethefiddle@...>
> > wrote:
> >>
> >> On 21 May 2013 10:03, David Bailes <drbailes@...> wrote:
>
> > I think that it's ok for the commands in the two sub-menus to have the
> same
> > labels. I think that the confusion in the keyboad prefs should be sorted
> out
> > there (at some point).
> >
> > Also, if on the align tracks menu, both align to/with/from(!) cursor and
> > align end to end both had predefined shortcuts, then not many people
> would
> > need to assign these in keyboard prefs anyway.
> >
> > There seems to be a couple of issues about shortcuts in the align tracks
> > sub-menu:
> >
> > 1. If I assign a keyboard shortcut in preferences, the shortcut works,
> but
> > doesn't show up after the command in the sub-menu. Assigning a shortcut
> for
> > a command in the effects menu shows up in the menu, but I don't know why.
>
> The problem is that it's because "alignLabels" is a list of commands
> that is shared by two sub-menus ("Align Tracks" and "Align Move"), so
> when an access key is allocated to one of the list items, the menu
> does not know which occurrence of that item in the menu should have
> the shortcut assigned to it. In other words, the menu list needs to be
> unique to one menu item.
>

thanks for the patch. It does appear to work, though I'm still confused -
though that's normal. Commands have both a name and a label (which is shown
on the menus). I'm pretty sure that the name of Align Start to Cursor in
the align tracks sub-menu would be Align:Align Start to &Cursor, and so
would be unique.

Any ideas on how to set up a predefined shortcut for Align Start to Cursor?
You seem to be having better luck at this than me.

David.

On Wed, May 22, 2013 at 3:03 PM, David Bailes <drbailes@...:

>
>>
> Any ideas on how to set up a predefined shortcut for Align Start to
> Cursor? You seem to be having better luck at this than me.
>
> David.
>

ps.
There is another minor issue here.
Gale has suggested some modifier+[ for align start to cursor, which seems
like a reasonable suggestion. However, for non us/uk keyboards, it would be
helpful to provide another shortcut as well, eg some modifier+g. However
with the current structure of the code, I dont' think it will be possible
to create another command which does the same thing (well not without copy
and paste), and assign that to the alternative shortcut.

David.

David Bailes wrote:
> Commands have both a name and a label (which is shown on the menus).

That depends on how the menu is created.
The Align menu is created as a menu list. In this case the command
name and command label are one and the same thing.

I'm very conscious of the fact that  what started out as adding a
relatively simple new feature is turning into a full-blown reworking
of the "Tracks > Align" feature.

On 22 May 2013 15:19, David Bailes <drbailes@...> wrote:
> On Wed, May 22, 2013 at 3:03 PM, David Bailes <drbailes@...>
> wrote:
>>>
>>>
>>
>> Any ideas on how to set up a predefined shortcut for Align Start to
>> Cursor? You seem to be having better luck at this than me.

Yes, the "Align Tracks" and "Align and Move Cursor" menus would need
to be rewritten using:
c->AddItem (for all 12 menu items)
rather than:
c->AddItemList (one list for each menu).

I'd rather not do that now.
I'd prefer that we add the "Align End to End" feature now, and then decide:

1a) Do we want a pre-defined default keyboard assignment for Align commands?
1b) If so, then which commands and which keys?
2a) Do we want the command names to be different from the command labels?
2b) If so, what names/labels do we want?
3a) Do we want any other changes to the Align commands menus or behaviours?
3b) If so, what?

and then I think that I can write the code to do it (which will save
me having to write dozens of different versions against a hazy idea of
what we may or may not actually want).

Is there anything in the current (version 6) patch that *must" be
changed *now*, or can we live with this enhancement while we decide
what other enhancements we may/may not want?

Steve



>>
>> David.
>
>
> ps.
> There is another minor issue here.
> Gale has suggested some modifier+[ for align start to cursor, which seems
> like a reasonable suggestion. However, for non us/uk keyboards, it would be
> helpful to provide another shortcut as well, eg some modifier+g. However
> with the current structure of the code, I dont' think it will be possible to
> create another command which does the same thing (well not without copy and
> paste), and assign that to the alternative shortcut.
>
> David.
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Audacity-quality mailing list
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

On Wed, May 22, 2013 at 3:59 PM, Steve the Fiddle
<stevethefiddle@...:

> David Bailes wrote:
> > Commands have both a name and a label (which is shown on the menus).
>
> That depends on how the menu is created.
> The Align menu is created as a menu list. In this case the command
> name and command label are one and the same thing.
>

I don't think this is the case, what appears to happen is:
1. AddItemList is called with a name, followed by an array of labels. For
the first sub-menu the name in the patched code is "AlignLocked".
2. AddItemList calls NewIdentifier also with the name and array of labels.
3.In NewIdentifier, there is the line to create the name for the command:
name= wxString::Format( wxT("%s:%s"), name.c_str(), label.c_str() );

So for example, the Align Start to &Cursor command should have the name
AlignLocked:Align Start to &Cursor

I was hoping that I could set a shortcut using this name and the SetKeyFromName
method of commandmanager. Unfortunately I couldn't get it to work, and
there are no examples of the use of this method in the code for ideas why
it might not be working.

>
> I'm very conscious of the fact that  what started out as adding a
> relatively simple new feature is turning into a full-blown reworking
> of the "Tracks > Align" feature.
>
> On 22 May 2013 15:19, David Bailes <drbailes@...> wrote:
> > On Wed, May 22, 2013 at 3:03 PM, David Bailes <drbailes@...>
> > wrote:
> >>>
> >>>
> >>
> >> Any ideas on how to set up a predefined shortcut for Align Start to
> >> Cursor? You seem to be having better luck at this than me.
>
> Yes, the "Align Tracks" and "Align and Move Cursor" menus would need
> to be rewritten using:
> c->AddItem (for all 12 menu items)
> rather than:
> c->AddItemList (one list for each menu).
>

I was hoping that using SetKeyFromName that a shortcut could be set using
the present structure.


>
> Is there anything in the current (version 6) patch that *must" be
> changed *now*, or can we live with this enhancement while we decide
> what other enhancements we may/may not want?
>

No, it will be really useful.

David.

| From Steve the Fiddle <stevethefiddle@...> 
| Wed, 22 May 2013 14:40:02 +0100
| Subject: [Audacity-quality] Align Tracks Together (with labels)
> On 22 May 2013 12:58, David Bailes <drbailes@...> wrote:
> > On Tue, May 21, 2013 at 7:53 PM, Steve the Fiddle <stevethefiddle@...>
> > wrote:
> >>
> >> On 21 May 2013 10:03, David Bailes <drbailes@...> wrote:
> >>
> >> >
> >> > Hi Gale, I appear to be loosing my marbles. I misunderstood your reply
> >> > to
> >> > robbie on the audacity4blind mailing list in march 2012 when he was
> >> > asking
> >> > whether "align with cursor" was available in the exported xml file for
> >> > keyboard shortcuts. It isn't, but all the align commands can be set in
> >> > the
> >> > keyboard category of preferences - I hadn't realised this. One minor
> >> > problem
> >> > is that the two sets of commands (with or without moving the cursor)
> >> > have
> >> > the same names, which is confusing.
> >>
> >> They both use the same sub-menu ("Align Together" is excluded from the
> >> "and Move Cursor" menu).
> >>
> >> If we changed this then the "and Move" menu would need its own sub
> >> menu rather than reusing the "Align Tracks" sub menu which makes the
> >> code a bit bulkier, is more to maintain, but the biggest issue is that
> >> different names would need to be given to the functions.
> >
> >
> > I think that it's ok for the commands in the two sub-menus to have the same
> > labels. I think that the confusion in the keyboad prefs should be sorted out
> > there (at some point). 

ATM I feel too that the commands in the two sub-menus should 
be the same and that the issue is in the Keyboard Prefs. 

Namely even if the "Align and Move Cursor" sub-menu items have 
unique text, that text doesn't necessarily make much sense on its
own in the Keyboard Prefs (from which you cannot access the 
menus to look at them).  There is the same issue with all the 
cascading menus to some extent or another.     

But rewording "Align and Move Cursor" to "Align Tracks and Move 
Cursor" would be better for that menu item if we want to spend
another word on it (especially if we keep identically named 
commands for "Align Tracks" and "Align and Move Cursor").


> > Also, if on the align tracks menu, both align to/with/from(!) cursor and
> > align end to end both had predefined shortcuts, then not many people would
> > need to assign these in keyboard prefs anyway.
> >
> > There seems to be a couple of issues about shortcuts in the align tracks
> > sub-menu:
> >
> > 1. If I assign a keyboard shortcut in preferences, the shortcut works, but
> > doesn't show up after the command in the sub-menu. Assigning a shortcut for
> > a command in the effects menu shows up in the menu, but I don't know why.
> 
> The problem is that it's because "alignLabels" is a list of commands
> that is shared by two sub-menus ("Align Tracks" and "Align Move"), so
> when an access key is allocated to one of the list items, the menu
> does not know which occurrence of that item in the menu should have
> the shortcut assigned to it. In other words, the menu list needs to be
> unique to one menu item. 

That sounds logical, but here on Win 7 (HEAD with no patch) I
used Keyboard Preferences "All" category to assign CTRL + 8 
to Align Tracks > Align with Zero and CTRL + 9 to Align and 
Move Cursor > Align with Zero.

Using the "Tracks" Category I assigned SHIFT + Y to Align Tracks >
Align to Selection Start and Y to Align and Move Cursor > Align 
to Selection Start.

All four commands are visible in the menu and work correctly. 
I only thought this was not so because I created an assignment
for the wrong item in Keyboard Prefs. 

So I am certainly confused as to whether the patch is even  
needed to solve the above. 

However the issue that these added assignments are not in the 
exported XML does exist in HEAD.  

Before I spend time on this patch, does it address the XML issue?



Gale 

 
> This problem can be fixed by creating a separate menu list for the
> "Align/Move" sub-menu so that it is not sharing the same list as
> "Align Tracks". This can also fix the problem in the keyboard
> preferences as the menu items can then have unique names. The question
> then is: what names.
> 
> The best that I've come up with is:
> "Tracks > Align Tracks > Align Start to ...."
> "Tracks > Align and Move Cursor > Move Start to ...."
> 
> Assuming that I've not missed errors in my code, this patch solves
> multiple problems, adds a very useful new feature, and I can live with
> the command names.
> 
> I think this patch will benefit translation hints. I'm not familiar
> with translation hints so could someone else do that?
> 
> 
> Steve
> 
> 
> >
> > 2. I'm not sure what code is needed to set up predefined shortcuts in the
> > align tracks sub-menu. I had a go using SetKeyFromName, using the name
> > "Align:Align with &Cursor" for the command (this is without your patch
> > applied) and had no joy.
> >
> > David.

On 23 May 2013 02:38, Gale Andrews <gale@...> wrote:
>
> | From Steve the Fiddle <stevethefiddle@...>
> | Wed, 22 May 2013 14:40:02 +0100
> | Subject: [Audacity-quality] Align Tracks Together (with labels)
>> On 22 May 2013 12:58, David Bailes <drbailes@...> wrote:
>> > On Tue, May 21, 2013 at 7:53 PM, Steve the Fiddle <stevethefiddle@...>
>> > wrote:
>> >>
>> >> On 21 May 2013 10:03, David Bailes <drbailes@...> wrote:
>> >>
>> >> >
>> >> > Hi Gale, I appear to be loosing my marbles. I misunderstood your reply
>> >> > to
>> >> > robbie on the audacity4blind mailing list in march 2012 when he was
>> >> > asking
>> >> > whether "align with cursor" was available in the exported xml file for
>> >> > keyboard shortcuts. It isn't, but all the align commands can be set in
>> >> > the
>> >> > keyboard category of preferences - I hadn't realised this. One minor
>> >> > problem
>> >> > is that the two sets of commands (with or without moving the cursor)
>> >> > have
>> >> > the same names, which is confusing.
>> >>
>> >> They both use the same sub-menu ("Align Together" is excluded from the
>> >> "and Move Cursor" menu).
>> >>
>> >> If we changed this then the "and Move" menu would need its own sub
>> >> menu rather than reusing the "Align Tracks" sub menu which makes the
>> >> code a bit bulkier, is more to maintain, but the biggest issue is that
>> >> different names would need to be given to the functions.
>> >
>> >
>> > I think that it's ok for the commands in the two sub-menus to have the same
>> > labels. I think that the confusion in the keyboad prefs should be sorted out
>> > there (at some point).
>
> ATM I feel too that the commands in the two sub-menus should
> be the same and that the issue is in the Keyboard Prefs.
>
> Namely even if the "Align and Move Cursor" sub-menu items have
> unique text, that text doesn't necessarily make much sense on its
> own in the Keyboard Prefs (from which you cannot access the
> menus to look at them).

Presumably if a user goes into Preferences to set or change a key
binding, they would know which menu command they want to change?

> There is the same issue with all the
> cascading menus to some extent or another.
>
> But rewording "Align and Move Cursor" to "Align Tracks and Move
> Cursor" would be better for that menu item if we want to spend
> another word on it (especially if we keep identically named
> commands for "Align Tracks" and "Align and Move Cursor").

A problem with having identically named commands is that you can't
tell them apart in Keyboard Preferences. Perhaps that does not need to
be solved now, but as the Align Tracks menu is having a new item added
it seems like a good idea to reduce this confusion while we are here.

>
>
>> > Also, if on the align tracks menu, both align to/with/from(!) cursor and
>> > align end to end both had predefined shortcuts, then not many people would
>> > need to assign these in keyboard prefs anyway.
>> >
>> > There seems to be a couple of issues about shortcuts in the align tracks
>> > sub-menu:
>> >
>> > 1. If I assign a keyboard shortcut in preferences, the shortcut works, but
>> > doesn't show up after the command in the sub-menu. Assigning a shortcut for
>> > a command in the effects menu shows up in the menu, but I don't know why.
>>
>> The problem is that it's because "alignLabels" is a list of commands
>> that is shared by two sub-menus ("Align Tracks" and "Align Move"), so
>> when an access key is allocated to one of the list items, the menu
>> does not know which occurrence of that item in the menu should have
>> the shortcut assigned to it. In other words, the menu list needs to be
>> unique to one menu item.
>
> That sounds logical, but here on Win 7 (HEAD with no patch) I
> used Keyboard Preferences "All" category to assign CTRL + 8
> to Align Tracks > Align with Zero and CTRL + 9 to Align and
> Move Cursor > Align with Zero.
>
> Using the "Tracks" Category I assigned SHIFT + Y to Align Tracks >
> Align to Selection Start and Y to Align and Move Cursor > Align
> to Selection Start.
>
> All four commands are visible in the menu and work correctly.
> I only thought this was not so because I created an assignment
> for the wrong item in Keyboard Prefs.
>
> So I am certainly confused as to whether the patch is even
> needed to solve the above.

I'm confused too.
When this issue was raised, I tried setting access keys and, as David
described, they did not show in the menus. I try it again today with a
freshly patched svn checkout and I'm able to set access keys (aided by
the fact that I can now see which ones belong to the "Align Tracks"
menu and which belong to the "Align and Move Cursor" menu), and the
access keys do show up in the menus !

>
> However the issue that these added assignments are not in the
> exported XML does exist in HEAD.
>
> Before I spend time on this patch, does it address the XML issue?

No, I've not even looked at that XML issue, I've been looking at
adding an option to align tracks end to end.

Steve


>
>
>
> Gale
>
>
>> This problem can be fixed by creating a separate menu list for the
>> "Align/Move" sub-menu so that it is not sharing the same list as
>> "Align Tracks". This can also fix the problem in the keyboard
>> preferences as the menu items can then have unique names. The question
>> then is: what names.
>>
>> The best that I've come up with is:
>> "Tracks > Align Tracks > Align Start to ...."
>> "Tracks > Align and Move Cursor > Move Start to ...."
>>
>> Assuming that I've not missed errors in my code, this patch solves
>> multiple problems, adds a very useful new feature, and I can live with
>> the command names.
>>
>> I think this patch will benefit translation hints. I'm not familiar
>> with translation hints so could someone else do that?
>>
>>
>> Steve
>>
>>
>> >
>> > 2. I'm not sure what code is needed to set up predefined shortcuts in the
>> > align tracks sub-menu. I had a go using SetKeyFromName, using the name
>> > "Align:Align with &Cursor" for the command (this is without your patch
>> > applied) and had no joy.
>> >
>> > David.

On Wed, May 22, 2013 at 3:59 PM, Steve the Fiddle
<stevethefiddle@...:

>
>
> I'd rather not do that now.
> I'd prefer that we add the "Align End to End" feature now, and then decide:
>
> 1a) Do we want a pre-defined default keyboard assignment for Align
> commands?
> 1b) If so, then which commands and which keys?
>

My suggestion is to have two pre-defined shortcuts. There are a limited
number of free shortcuts for Audacity, so I think it's best to use them
sparingly.
The two commands with shortcuts are both on the Align Tracks sub-menu.
1. Align start to cursor. If it's possible to have two shortcuts, then
ctrl+shift+[ and ctrl+shift+g, the latter for users of non us/uk keyboards.
If there's only one shortcut, ctrl+shift+g.
2. Align end to end. Ctrl+Shift+D.

David.

On 23 May 2013 09:02, David Bailes <drbailes@...> wrote:
> On Wed, May 22, 2013 at 3:59 PM, Steve the Fiddle <stevethefiddle@...>
> wrote:
>>
>>
>>
>> I'd rather not do that now.
>> I'd prefer that we add the "Align End to End" feature now, and then
>> decide:
>>
>> 1a) Do we want a pre-defined default keyboard assignment for Align
>> commands?
>> 1b) If so, then which commands and which keys?
>
>
> My suggestion is to have two pre-defined shortcuts. There are a limited
> number of free shortcuts for Audacity, so I think it's best to use them
> sparingly.

+1 for using sparingly.

As an aside, perhaps we should reserve special keys that vary on non
uk/us keyboards for user's custom key bindings. That would save us a
lot of problems and provide users with some easy to find, available
key combinations. I'm not suggesting that we change any of the current
key bindings.

> The two commands with shortcuts are both on the Align Tracks sub-menu.
> 1. Align start to cursor. If it's possible to have two shortcuts, then
> ctrl+shift+[ and ctrl+shift+g, the latter for users of non us/uk keyboards.
> If there's only one shortcut, ctrl+shift+g.
> 2. Align end to end. Ctrl+Shift+D.

I can see why you have picked out those two.

How about:
Align Start to Zero: Alt+Ctrl+Z
Align Start to Cursor: Alt+Ctrl+C
Align End to End: Alt+Ctrl+N

In each case the letter is the same as the letter used for the access key.

Steve


>
> David.
>

Steve wrote:
>As an aside, perhaps we should reserve special keys that vary on non
>uk/us keyboards for user's custom key bindings. That would save us a
>lot of problems and provide users with some easy to find, available
>key combinations.
 
+1 
 
Much more than an "aside" - a great idea.
 
A handy group of 4 that I found when searching for a group I could 
use are:
 
ALT+UP,  ALT+DOWN,  ALT+RIGHT,  ALT+LEFT
 
I have also recommended the availability of this group to several users
on the form - so I would vote strongly for reserving at least these four.
 
I can see the sense of reserving a few more - "The Magical Number Seven, 
Plus or Minus Two" springs to mind - see: 
http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
 
Another advantage of having reserved bindings for user's use is that we
can document these in the manual for readers.
 
Thanks,
Peter.
 
Peter Sampson
Tel: +44 (0)1625 524 780
Mob: +44 (0)7732 278 299
 

________________________________
 From: Steve the Fiddle <stevethefiddle@...>
To: audacity-quality <audacity-quality@...> 
Sent: Thursday, May 23, 2013 1:51 PM
Subject: Re: [Audacity-quality] Align Tracks Together (with labels)
  

On 23 May 2013 09:02, David Bailes <drbailes@...> wrote:
> On Wed, May 22, 2013 at 3:59 PM, Steve the Fiddle <stevethefiddle@...>
> wrote:
>>
>>
>>
>> I'd rather not do that now.
>> I'd prefer that we add the "Align End to End" feature now, and then
>> decide:
>>
>> 1a) Do we want a pre-defined default keyboard assignment for Align
>> commands?
>> 1b) If so, then which commands and which keys?
>
>
> My suggestion is to have two pre-defined shortcuts. There are a limited
> number of free shortcuts for Audacity, so I think it's best to use them
> sparingly.

+1 for using sparingly.

As an aside, perhaps we should reserve special keys that vary on non
uk/us keyboards for user's custom key bindings. That would save us a
lot of problems and provide users with some easy to find, available
key combinations. I'm not suggesting that we change any of the current
key bindings.

> The two commands with shortcuts are both on the Align Tracks sub-menu.
> 1. Align start to cursor. If it's possible to have two shortcuts, then
> ctrl+shift+[ and ctrl+shift+g, the latter for users of non us/uk keyboards.
> If there's only one shortcut, ctrl+shift+g.
> 2. Align end to end. Ctrl+Shift+D.

I can see why you have picked out those two.

How about:
Align Start to Zero: Alt+Ctrl+Z
Align Start to Cursor: Alt+Ctrl+C
Align End to End: Alt+Ctrl+N

In each case the letter is the same as the letter used for the access key.

Steve


>
> David.
>

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Audacity-quality mailing list
Audacity-quality@...
https://lists.sourceforge.net/lists/listinfo/audacity-quality

On Thu, May 23, 2013 at 5:08 AM, Steve the Fiddle
<stevethefiddle@...:

> On 23 May 2013 02:38, Gale Andrews <gale@...> wrote:
> >
> > | From Steve the Fiddle <stevethefiddle@...>
> > | Wed, 22 May 2013 14:40:02 +0100
> > | Subject: [Audacity-quality] Align Tracks Together (with labels)
> >> On 22 May 2013 12:58, David Bailes <drbailes@...> wrote:
> >> > On Tue, May 21, 2013 at 7:53 PM, Steve the Fiddle <
> stevethefiddle@...>
> >> > wrote:
> >> >>
> >> >> On 21 May 2013 10:03, David Bailes <drbailes@...> wrote:
> >> >>
> >> >> >
> >> >> > Hi Gale, I appear to be loosing my marbles. I misunderstood your
> reply
> >> >> > to
> >> >> > robbie on the audacity4blind mailing list in march 2012 when he was
> >> >> > asking
> >> >> > whether "align with cursor" was available in the exported xml file
> for
> >> >> > keyboard shortcuts. It isn't, but all the align commands can be
> set in
> >> >> > the
> >> >> > keyboard category of preferences - I hadn't realised this. One
> minor
> >> >> > problem
> >> >> > is that the two sets of commands (with or without moving the
> cursor)
> >> >> > have
> >> >> > the same names, which is confusing.
> >> >>
> >> >> They both use the same sub-menu ("Align Together" is excluded from
> the
> >> >> "and Move Cursor" menu).
> >> >>
> >> >> If we changed this then the "and Move" menu would need its own sub
> >> >> menu rather than reusing the "Align Tracks" sub menu which makes the
> >> >> code a bit bulkier, is more to maintain, but the biggest issue is
> that
> >> >> different names would need to be given to the functions.
> >> >
> >> >
> >> > I think that it's ok for the commands in the two sub-menus to have
> the same
> >> > labels. I think that the confusion in the keyboad prefs should be
> sorted out
> >> > there (at some point).
> >
> > ATM I feel too that the commands in the two sub-menus should
> > be the same and that the issue is in the Keyboard Prefs.
> >
> > Namely even if the "Align and Move Cursor" sub-menu items have
> > unique text, that text doesn't necessarily make much sense on its
> > own in the Keyboard Prefs (from which you cannot access the
> > menus to look at them).
>
> Presumably if a user goes into Preferences to set or change a key
> binding, they would know which menu command they want to change?
>

Yes, but try it when you are confronted with a partial wording (the
sub-menu without the preceding menu item) and you are also disorientated by
a long list without the subdivisions (dividers) that you can remember (but
not see) in the menu.


> > There is the same issue with all the
> > cascading menus to some extent or another.
> >
> > But rewording "Align and Move Cursor" to "Align Tracks and Move
> > Cursor" would be better for that menu item if we want to spend
> > another word on it (especially if we keep identically named
> > commands for "Align Tracks" and "Align and Move Cursor").
>
> A problem with having identically named commands is that you can't
> tell them apart in Keyboard Preferences. Perhaps that does not need to
> be solved now, but as the Align Tracks menu is having a new item added
> it seems like a good idea to reduce this confusion while we are here.
>

I think there may be much more benefit in having identically named commands
than not (assuming display in the Preferences is improved in the future).

E.g. compare Align Start to Cursor and Move Start to Cursor. By definition
"Start" means the start of the track and exactly the same movement is
happening to the start of the track in both commands, but we call that
movement "Align" in one case and "Move" in the other, giving an impression
that the track movement is not the same.

> I tried setting access keys and, as David
> described, they did not show in the menus. I try it again today with a
> freshly patched svn checkout and I'm able to set access keys (aided by
> the fact that I can now see which ones belong to the "Align Tracks"
> menu and which belong to the "Align and Move Cursor" menu), and the
> access keys do show up in the menus !

Unless you actually chose the wrong set in Preferences. It is very easily
done.

> However the issue that these added assignments are not in the
> exported XML does exist in HEAD.
>
> Before I spend time on this patch, does it address the XML issue?

No, I've not even looked at that XML issue, I've been looking at
> adding an option to align tracks end to end.
>
> OK. Custom align shortcuts are still not exported with your latest patch,
so separate menu items in itself does not fix that.


Thanks


Gale

On Tue, May 21, 2013 at 8:06 PM, Steve the Fiddle
<stevethefiddle@...:

>
> I don't expect that I'll come to an agreement with Gale or David about
> the use of long phrases for menu commands,


Just for the record, I prefer short phrases for menu commands, and probably
most users of screen readers do as well.

thanks,
David.

| From Steve the Fiddle <stevethefiddle@...> 
| Tue, 21 May 2013 20:06:05 +0100
| Subject: [Audacity-quality] Concatenate files / Append Import
> I'm persuaded that aligning  end to end starting from the first track
> can be more useful in some user cases with little or no detriment to
> other user cases.

Good. Thanks for listening (though I would have no objection
to a second "End to End" align that moved the first selected 
track to zero).   

 
> I don't expect that I'll come to an agreement with Gale or David about
> the use of long phrases for menu commands, so I've used my preferred
> choice of command names. If there is consensus for using different
> names then I'm sure that someone will be able to change them.

As I said, even I see the benefit of short names, but I gave 
reasons why these menus may be something of a special case. 

In your latest patch, I think it's probably a mistake to remove
"Align" from the sub-menus. It's fine to do that for the "Align 
Tracks" sub-menu items but the problem is the "Align and
Move Cursor" items. 

For example, "Align and Move Cursor > End to Cursor" is really 
confusing IMO. If we must remove "Align" then I think the menu 
item should be "Align Tracks and Move Cursor" (and probably 
should be anyway, because currently it can be read as "Align 
Cursor and Move Cursor").     

I still think "from" is a significant mistake, and I think it's plain  
wrong that the history items ("start to") are named differently
to the equivalent menu items ("from").    

I hope we can reach some agreement on this, because otherwise
this patch seems a very important advance. Thanks for working 
on it.  



Gale

On 21 May 2013 21:46, Gale Andrews <gale@...> wrote:
>
> | From Steve the Fiddle <stevethefiddle@...>
> | Tue, 21 May 2013 20:06:05 +0100
> | Subject: [Audacity-quality] Concatenate files / Append Import
>> I'm persuaded that aligning  end to end starting from the first track
>> can be more useful in some user cases with little or no detriment to
>> other user cases.
>
> Good. Thanks for listening (though I would have no objection
> to a second "End to End" align that moved the first selected
> track to zero).
>
>
>> I don't expect that I'll come to an agreement with Gale or David about
>> the use of long phrases for menu commands, so I've used my preferred
>> choice of command names. If there is consensus for using different
>> names then I'm sure that someone will be able to change them.
>
> As I said, even I see the benefit of short names, but I gave
> reasons why these menus may be something of a special case.
>
> In your latest patch, I think it's probably a mistake to remove
> "Align" from the sub-menus. It's fine to do that for the "Align
> Tracks" sub-menu items but the problem is the "Align and
> Move Cursor" items.
>
> For example, "Align and Move Cursor > End to Cursor" is really
> confusing IMO. If we must remove "Align" then I think the menu
> item should be "Align Tracks and Move Cursor" (and probably
> should be anyway, because currently it can be read as "Align
> Cursor and Move Cursor").
>
> I still think "from" is a significant mistake, and I think it's plain
> wrong that the history items ("start to") are named differently
> to the equivalent menu items ("from").

I thought that I'd fixed that but I clearly forgot to update it.
Yes, of course the history needs to match whatever names are finally used.


>
> I hope we can reach some agreement on this, because otherwise
> this patch seems a very important advance. Thanks for working
> on it.

Try me with the shortest names that you find acceptable :-)

Steve


>
>
>
> Gale
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Audacity-quality mailing list
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

On 5/21/2013 12:06 PM, Steve the Fiddle wrote:
> ...
> I don't expect that I'll come to an agreement with Gale or David about
> the use of long phrases for menu commands, so I've used my preferred
> choice of command names. If there is consensus for using different
> names then I'm sure that someone will be able to change them.

Right on! Down with interminable discussions! :-)

- V

On 5/21/2013 12:57 PM, David Bailes wrote:
> ...
> Just for the record, I prefer short phrases for menu commands, and
> probably most users of screen readers do as well.

It's a widely accepted general principle in UI design. But if a short 
command is confusing, sometimes the only was to clarify is more words.

- V

typo: I meant "...only way..."

On 5/21/2013 4:25 PM, Vaughan Johnson wrote:
> On 5/21/2013 12:57 PM, David Bailes wrote:
>> ...
>> Just for the record, I prefer short phrases for menu commands, and
>> probably most users of screen readers do as well.
>
> It's a widely accepted general principle in UI design. But if a short
> command is confusing, sometimes the only was to clarify is more words.
>
> - V
>