Difference between revisions of "Proposal Focus And Multiselect"

From Audacity Wiki
Jump to: navigation, search
(stop gap.)
m (Developer/QA/User Backing: add my name)
Line 28: Line 28:
==Use Cases==
==Use Cases==

Latest revision as of 17:42, 10 February 2020

Proposal pages help us get from feature requests into actual plans. This page is a proposal to modify focus behaviour, with a view to better multi-selecting.
Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.

  • Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.

The Problem

The yellow track focus box is ugly, and it is confusing as to exactly how it operates.

  • There may also be confusion as to interaction between focus, cursor and selectedness.

Proposed Feature

We should be guided by how you make a multiple selection of files in a files browser using just the keyboard.

  • Ctrl+Arrow and Ctrl+Space used to move a blue focus thing and select/deselect. We should use the same key combinations.
  • Ditch the yellow. Use a well designed blue focus (but possibly still yellow in Hi-Contrast mode).
  • Keyboard based multi-select for labels, so multi-select a subset of labels (yes, that means making discontinuous selections).

This proposal needs more discussion. For example we want to be able to easily mute/unmute selected tracks, and remember/recall past selections easily. There are also conflicting pulls. One possible design principle is that NOTHING acts directly on focus track, only on selections, and that focus is used simply to add/remove from selections.

One option is to have a dedicated focus dialog, and keep the complexity of 'focus' out of the main part of the interface.

Stop Gap

Waiting for the ideal solution can 'take forever', especially as what the ideal solution actually is needs discussion. A small improvement right now would be to make the 'cursor' behave just like a selected range. In particular, moving the focus should have no effect on the cursor. Currently moving the focus to a new track can cause the cursor to extend to the new track too.

Developer/QA/User Backing




Use Cases


Implementation and Design Considerations

Bug Reports

GUI Examples


Related Proposals and Feature Requests