Talk:Completed Proposal Select Track button in TCP

From Audacity Wiki
Revision as of 08:48, 25 March 2019 by PeterSampson (talk | contribs) (Click Behaviour: {{ednote|'''Peter 25Mar:''' this is already achievable by holding down the {{key|Ctrl}} key while clicking in the "white space" or now in the {{button|Select}} button }})
Jump to: navigation, search

Size

  • James 18Mar19: I propose that the collapse button be reduced to a square, and the select button be made wider - and that that be the default display. Why? You've had to use a smaller font already. In translation 'select' may be wider, and we already have problem with width of mute and solo in translation. Also I'd have the choice for buttons in the bottom row in a track be set via preferences.
    • Steve (talk) 07:08, 21 March 2019 (EDT): I agree that a larger "Select" button is a good idea.
    • Peter 24Mar19: I'd be very happy to see a smaller, square, collapse/expand button and a larger Select button.


Click Behaviour

Optional Extra: "Select" button is an up/down button to unselect/select the whole track.
Peter 25Mar: this is already achievable by holding down the Ctrl key while clicking in the "white space" or now in the Select button
IF we have this optional extra feature, we need to decide exactly how it will behave. I'm assuming that the default behaviour will be to select the entire track.
  • If a "Select button" is pressed on an addition track, is that track selected "as well" or "instead of" the first selected track? In other words, does this button support selecting multiple tracks?
    • If it is selected "as well" as the first track, is the length of the selection the maximum of the two track lengths, or the length of the original selection?
    • In short, is this a direct replacement of the complex current "empty track info panel" click (including modifier key behaviours), or are we simplifying the behavior?
  • James 21Mar19: I'd see the new button's behaviour as needing to be exactly the same as 'empty track info panel' clicking. There are two reasons:
    • Ease of implementation. We are then reusing the exact same logic. Coming up with new 'improved' logic will take time, new code, experiment, and discussion. This way we are just making existing behaviour more discoverable.
      • Peter 24Mar19: +1
    • With the button, the old zone for clicking (which would be maintained) becomes LESS discoverable. It does not make sense to have some functionality that we already found is useful be effectively lost to many users, which it would be if this button behaved differently.
      • Peter 24Mar19: +1
    • Steve (talk) 11:31, 24 March 2019 (EDT): I'm happy with James' suggestion for now, and agree with James' reasoning. I think we could improve the behaviour at some time in the future, but "discovery" is by far the most important issue.