[Audacity-devel] Tab or scroll wheel?

[Paul Licameli]

As discussed elsewhere, I want a simple uniform convention for cycling
among multiple hit test candidates at one mouse position, surely in 2.1.1.

I had been using the Tab key. That caused problems with interference with
its previous meaning in a focused label track, and on Linux, you can move
the mouse a little to where there is only one hit target, and then Tab does
a very different change of keyboard focus.

Suppose instead I make rotation among targets tied to the scroll wheel,
without modifier keys. I am starting to like this idea.

1. Dependent only on pointer position. No conflict over keyboard
focus. So, available even in label tracks, regardless of focus.
2. It does conflict with unmodified scroll wheel to move tracks
vertically. Personally, I find that the least useful of the previously
existing scroll wheel actions, so I don't feel a great loss. That old
action could still happen when there is only one hit target.
3. If it is a preference, I would default it on.
4. I think it could be more quickly discovered, even accidentally.
5. I had floated the idea of making rotation work one-handed, but using
the thumb buttons of fancy mice only. This makes it available even on
inexpensive mice.
6. It is consistent with usage of scroll wheel to choose among discrete
lists of things in other applications. Drop-down menus often work this way.

One present use of tab that would not work so well is the change between
snapping and non-snapping state during selection drag. But another idea
suggested itself here, that Esc be overloaded instead.

PRL

[Paul Licameli]

Post by Paul Licameli
As discussed elsewhere, I want a simple uniform convention for cycling
among multiple hit test candidates at one mouse position, surely in 2.1.1.
I had been using the Tab key. That caused problems with interference with
its previous meaning in a focused label track, and on Linux, you can move
the mouse a little to where there is only one hit target, and then Tab does
a very different change of keyboard focus.
Suppose instead I make rotation among targets tied to the scroll wheel,
without modifier keys. I am starting to like this idea.
1. Dependent only on pointer position. No conflict over keyboard
focus. So, available even in label tracks, regardless of focus.
2. It does conflict with unmodified scroll wheel to move tracks
vertically. Personally, I find that the least useful of the previously
existing scroll wheel actions, so I don't feel a great loss. That old
action could still happen when there is only one hit target.
3. If it is a preference, I would default it on.
4. I think it could be more quickly discovered, even accidentally.
5. I had floated the idea of making rotation work one-handed, but
using the thumb buttons of fancy mice only. This makes it available even
on inexpensive mice.
6. It is consistent with usage of scroll wheel to choose among
discrete lists of things in other applications. Drop-down menus often work
this way.
One present use of tab that would not work so well is the change between
snapping and non-snapping state during selection drag. But another idea
suggested itself here, that Esc be overloaded instead.
PRL

My answer to the title line is now "Neither!" At least for now. I have
talked myself into liking Esc key after all, for 2.1.0.

Esc key has already gained capabilities in 2.2.0 -- all drag actions in
TrackPanel can be escaped now. That got little comment from the team, but
it was not a small effort.

So if I "own" the Esc key by default, I'll enhance it a bit more.

Now I think it also makes sense that Esc more generally takes you away from
"prominent" things that "pop up" like the special cursor for cutlines or
split lines. It also makes sense as escaping from a yellow snap line
before or during selection drag.

Esc will work one-way only, not cyclically and reversibly as (shift+) tab
does in present head. That is more in keeping with other Esc key
conventions. If you want to see the snap line again, you will have to move
the mouse a little bit away, then back.

The status bar can have

(Esc to cancel)


appended when that makes sense, as a discoverability clue, but otherwise I
don't feel the motivation now to keep the tooltips (at least those not over
the vertical ruler or TCP), which, I agree, may only become a nuisance
instead.

I like this compromise. It gives me the enhancement of multiple hit
targets that I want, in what I think is a less objectionable way to
everyone, and it even gives a decent resolution for
http://bugzilla.audacityteam.org/show_bug.cgi?id=800.

Tab or wheel cycles might still make sense if ever there are multiple
targets that in some sense peers, not logically foreground and background
-- like multiple clip boundaries close by -- but leave that idea to the
future.

PRL

[Robert Hänggi]

Hi Paul

I like your newest ideas and that you're going away from the tab key.
It could have caused problems for those using the keyboard only,
especially if you don't see where the mouse pointer is.

However, I would keep the tab key and it's rotation function in mind
when reorganizing general keyboard usage.

Let's say that you are on an audio track.
The tab key would give us the possibility to switch between different
modes and thus free a lot of keyboard shortcuts.

Time Selection mode would be the default.
pressing Tab brings you to e.g.
Clip Selection mode:
A non-modified arrow key would not jump by a certain amount of time
but between clip boundaries. The modifiers would extend and contract
as already known.
Next mode could be
Label Selection mode (currently done with the Alt+Arrow keys but not
extendable):
Same functionality.

Then some related modes that do not select but alter the content, e.g.
Clip Trim mode or Label Adjust mode, those that can be performed by
handles but are not yet available for keyboard.

This makes it pretty easy to include modes for editing envelope points
as well, or other thinks like peaks, transients, MIDI events and so
on.

***

BTW, here's another application for the escape key:
Remove time selection.
This is taken from Reaper which has of course an independent edit
cursor (which we will hopefully have at some point too).
Currently, performing any cursor action (arrow key, j, k, home etc)
does the same, namely deselect the time range.
However, doing it with the escape key has the advantage that an Undo
point can be set and it will certainly be necessary in future when you
want to implement punch-in properly.

Robert

Post by Paul Licameli

Post by Paul Licameli
As discussed elsewhere, I want a simple uniform convention for cycling
among multiple hit test candidates at one mouse position, surely in 2.1.1.
I had been using the Tab key. That caused problems with interference with
its previous meaning in a focused label track, and on Linux, you can move
the mouse a little to where there is only one hit target, and then Tab does
a very different change of keyboard focus.
Suppose instead I make rotation among targets tied to the scroll wheel,
without modifier keys. I am starting to like this idea.
1. Dependent only on pointer position. No conflict over keyboard
focus. So, available even in label tracks, regardless of focus.
2. It does conflict with unmodified scroll wheel to move tracks
vertically. Personally, I find that the least useful of the previously
existing scroll wheel actions, so I don't feel a great loss. That old
action could still happen when there is only one hit target.
3. If it is a preference, I would default it on.
4. I think it could be more quickly discovered, even accidentally.
5. I had floated the idea of making rotation work one-handed, but
using the thumb buttons of fancy mice only. This makes it available even
on inexpensive mice.
6. It is consistent with usage of scroll wheel to choose among
discrete lists of things in other applications. Drop-down menus often work
this way.
One present use of tab that would not work so well is the change between
snapping and non-snapping state during selection drag. But another idea
suggested itself here, that Esc be overloaded instead.
PRL

My answer to the title line is now "Neither!" At least for now. I have
talked myself into liking Esc key after all, for 2.1.0.
Esc key has already gained capabilities in 2.2.0 -- all drag actions in
TrackPanel can be escaped now. That got little comment from the team, but
it was not a small effort.
So if I "own" the Esc key by default, I'll enhance it a bit more.
Now I think it also makes sense that Esc more generally takes you away from
"prominent" things that "pop up" like the special cursor for cutlines or
split lines. It also makes sense as escaping from a yellow snap line
before or during selection drag.
Esc will work one-way only, not cyclically and reversibly as (shift+) tab
does in present head. That is more in keeping with other Esc key
conventions. If you want to see the snap line again, you will have to move
the mouse a little bit away, then back.
The status bar can have
(Esc to cancel)
appended when that makes sense, as a discoverability clue, but otherwise I
don't feel the motivation now to keep the tooltips (at least those not over
the vertical ruler or TCP), which, I agree, may only become a nuisance
instead.
I like this compromise. It gives me the enhancement of multiple hit
targets that I want, in what I think is a less objectionable way to
everyone, and it even gives a decent resolution for
http://bugzilla.audacityteam.org/show_bug.cgi?id=800.
Tab or wheel cycles might still make sense if ever there are multiple
targets that in some sense peers, not logically foreground and background
-- like multiple clip boundaries close by -- but leave that idea to the
future.
PRL