Difference between revisions of "Talk:Completed Proposal Select Track button in TCP"
From Audacity Wiki
PeterSampson (talk | contribs) m (PeterSampson moved page Talk:Proposal Select Track button in TCP to Talk:Completed Proposal Select Track button in TCP: Dine for 2.3.2) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 9: | Line 9: | ||
*[[User:Stevethefiddle|Steve]] ([[User talk:Stevethefiddle|talk]]) 07:08, 21 March 2019 (EDT): | *[[User:Stevethefiddle|Steve]] ([[User talk:Stevethefiddle|talk]]) 07:08, 21 March 2019 (EDT): | ||
:'''''Optional Extra:''' "Select" button is an up/down button to unselect/select the whole track.'' | :'''''Optional Extra:''' "Select" button is an up/down button to unselect/select the whole track.'' | ||
| + | {{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 }} | ||
: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 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 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? | ||
Latest revision as of 08:48, 19 June 2019
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.
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 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?
- 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?
- 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.
- 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.
