Tab or scroll wheel?

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

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



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tab or scroll wheel?

Paul Licameli


On Sat, Jul 15, 2017 at 3:46 PM, Paul Licameli <[hidden email]> wrote:
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

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tab or scroll wheel?

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


On 15/07/2017, Paul Licameli <[hidden email]> wrote:

> On Sat, Jul 15, 2017 at 3:46 PM, Paul Licameli <[hidden email]>
> wrote:
>
>> 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
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...