On 22-Sep-10, at 4:20 AM, Gale Andrews wrote:
> Posting on top the gist of this:
> 1) Can we agree we don't need separate commands for [ and ] when the
> track is static?
Yes, I can agree on that.
> 2) If so, can we decide on the "Select" or "Move" cascade?
> Then we can sort out a wording.
> I'm still for the "Move" cascade (with a fuller wording to make it
> but I could be persuaded otherwise. See below for my attempt at
> logically about this.
If we decide on the "Move" cascade then I think the fuller wording is
necessary. There are many use cases, and the commands *appear* to
behave differently depending on the situation, but they actually
behave logically and one can infer the rules from the behaviour. The
fuller wording at least *hints* at this behaviour. The upshot is that
some compromise is needed, and the best I can come up with is that the
menu items repeat the dialog title.
Or we could cut the Gordian Knot and remove the commands from the Edit
menu entirely, leaving them as key bindings similar to "1", "B" and
"C". This may not be as radical as it sounds. When using the commands
during playback, going to the Edit menu to select them is likely to be
awkward and not very useful as the point is to hit the keys when you
hear the edit points go by. For Gale's "mouse-avoidance" case there's
no downside to not having menu items, aside from "discoverability".
> | From David Bailes <drbailes@...>
> | Tue, 21 Sep 2010 10:22:54 +0100
> | Subject: [Audacity-quality] Edit > Select > Left/Right at Playback
>> On Tue, Sep 21, 2010 at 7:50 AM, Gale Andrews
>> <gale@...> wrote:
>>> | From Bill Wharrie <billwh@...>
>>> | Mon, 20 Sep 2010 23:54:50 -0400
>>> | Subject: [Audacity-quality] Edit > Select > Left/Right at
>>> Playback Position
>>>> On 20-Sep-10, at 11:15 PM, Gale Andrews wrote:
>>>>> | From David Bailes <drbailes@...>
>>>>> | Mon, 20 Sep 2010 18:35:22 +0100
>>>>> | Subject: [Audacity-quality] Edit > Select > Left/Right at
>>>>> | Position
>>>>>> On Mon, Sep 20, 2010 at 6:25 PM, Bill Wharrie <billwh@...>
>>>> ... Given the current names of the commands it seems logical to
>>>> that their primary intended use was during playback and
>>>> recording. For
>>>> that they're very handy, as you can mark a spot as you hear it go
>>>> then when stopped go back and fine tune the selection. It seems
>>>> to me
>>>> that the behaviour when stopped was kind of tacked on (although I
>>>> it's been there since 1.3.0).
>>>> Personally, I can see no useful purpose to them when stopped. I
>>>> want to set the cursor by time; I want to set it by sound.
>>> Clearly people do want to set by time or we wouldn't have Selection
>>> Toolbar. I just think it's way easier to set it on a static track
>>> by [ or ]
>>> which you can do without further use of the mouse or further
>>> Compare that with Selection Toolbar (CTRL + F6, no guarantee you
>>> land on the control you wanted, and even if you do so land, the last
>>> non-zero digit isn't conveniently highlighted as it is in Set
>> Just to point out that with no playback, if you use [ to change the
>> cursor position, then this is equivalent to using selection start on
>> the toolbar with the end/length radio buttons set to end. Starting
>> form no selection present, decrementing the counter causes a
>> to be created, rather than moving the cursor. So for vi users, this
>> isn't a useful way of moving the cursor by time. It's better to use
>> the selection start control on the toolbar, with the end/length radio
>> buttons set to length, which allows you to move the cursor either
>> forwards for backwards without the danger of accidentally creating a
> Hi David,
> I'm as much concerned with sighted people not having to move around
> the interface un-necessarily, but I personally still find it far
> to move the cursor left/ right in a static track with the [ and ]
> For example, from the cursor at 15s in a 30s track:
> * To move cursor left to 10s, ] and choose 10s in the TimeText control
> * To move cursor right to 20s, [ and choose 20s in the TimeText
> I agree using ] to move left and vice-versa isn't that intuitive
> until you
> think about it, but I would much rather document this than remove it.
>>>> If we want to split the commands I'd say keep [ and ] for playback/
>>>> recording and the shifted versions for stop. That said I'm
>>>> leaning to
>>>> not splitting the commands and just properly documenting what
>>>> they do,
>>>> as well as figuring out the best place and wording in the menu.
>>> I think the disbenefit from user needing different commands
>>> any benefit from reduced confusion, so I'd agree there.
>> my suggestion was to have two pairs of commands but the same
> OK, I didn't read it like that, but is it a good idea/good practice,
> and how
> does it work in the Keyboard preferences? Do we group them there, so
> you can only change the binding for the pair e.g.
> "Set Left Boundary/Select Left at Playback Position" [ ?
> Is there anyone else who wants a separate pair of commands for the
> Boundary" action on a static track (with or without shared
> shortcuts)? I
> think it's cruft we don't have space (or access keys) for in the
> current Edit
>>>> When the team decides what to do, I'll document it.
>>> Thanks. If the length of "Mo&ve Cursor or Selection Boundary" in the
>>> menu is a problem, and we object to the grammatical problem of
>>> moving a "Set", we could just accept that "setting" the selection
>>> boundary will usually move it (otherwise, what's the purpose?).
>>> So, "Mo&ve" >
>>> Cursor to Selection Start
>>> Cursor to Selection End
>>> Cursor to Track Start
>>> Cursor to Track End
>>> Left Selection Boundary
>>> Right Selection Boundary
>>> Then change the title of "Set Left Selection Boundary" and "Set
>>> Selection Boundary" to "Move Left Selection Boundary" and Move Right
>>> Selection Boundary". All commands stop in the Edit menu, as there
>>> likely to be a consensus to move them.
>>> I think that (or some variant of it) will probably get a
>>> consensus. I slightly
>>> prefer the full "Mo&ve Cursor or Selection Boundary" (it doesn't
>>> make the
>>> Edit menu spread wider than the File menu); and to leave the
>>> wording in
>>> Edit menu and dialogue as Set Left/Right Selection Boundary.
>> I think that the text of the current commands in the select sub menu
>> are good descriptions for what happens during playback.
> I wouldn't even agree there. Quite a few users misinterpret "Right at
> Playback Position" as moving the cursor somewhere rightwards from
> the playback position (just as "Left at Playback Position" appears to
> move it leftwards). I've never been happy with that wording. I think
> aren't selecting anything per se. We are setting the left or right
> of a selection at the playback position. In the case of ], this
> happens to
> draw a selection. "[" (which I suspect is more commonly used than "]")
> doesn't draw a selection, which confused me for ages.
> Hence the suggestion to explicitly rename this command to "Set" which
> is always correct whether the track is static or not. On the
> we don't want an extra item in the Edit menu, we then have to choose
> put it in the "Select" cascade or the "Move Cursor" (as currently
> The rationale for not putting it in the Select cascade is that this is
> (possibly) more intuitive for the user, given "setting" is a quite
> to "moving". My problem with renaming "Move Cursor" to "Set"
> (apart from access keys) is that it probably isn't descriptive enough
> on its own (nor really is "Move" as you point out below). I think
> "Move Cursor or Selection Boundary" is reasonable, especially given
> there may already be a selection.
> The rationale for putting it in the Select cascade (if properly
> would be that we are setting a selection boundary. The user has to
> understand that this does not always draw a selection of itself. I'm
> (almost) equally happy with that, but my vote is still with "Move
> Cursor or Selection Boundary". Or, "Move Cursor/Set Selection Edge"
> (slightly shorter).
>> Having the word playback seems helpful to me.
> It disguises that these commands can be used on a static track,
>> Also these commands are mainly for selection - definitely not moving
>> (suggests moving data?)
> See above. Even as an effect of what they do, only half their cases
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> Audacity-quality mailing list