And note that we can’t do this for 2.3.0 as we are now semi-freddo in “string freeze”.
Peter.
Yes we do, and we even have inconsistency within the context of the track info box, with the Mute and Solo buttons “latching” down, and the “Collapse / Expand” button non-latching. However, as we can have multiple tracks selected, I think it makes more visual sense for the Select button to reflect the track state, as the Solo and Mute buttons do.
Doing this would give the following behaviours, and I have highlighted the combinations that I think could be contentious:
-
Left Click:
- No tracks selected => Select the track that the button belongs to (button latches down).
-
This track only selected => Deselect the track (button pops back up).
I think it would be silly to require the Ctrl button to be held down to deselect this track, and requiring Ctrl would create a “stuck in state” issue. It is not a “radio button”, so user’s are not likely to expect it to behave like a radio button. - Other track(s) only selected => Select this track, other tracks are deselected.
- Other track(s) and this track selected =>
EITHER: Deselect this track, Other tracks retain their existing selectedness.
OR: Select this track only.
-
Shift + Click:
- No tracks selected => Same as Left click
- This track only selected => Same as Left click
- Other track(s) only selected => TO BE DECIDED: Three possible cases:
- Other tracks above this track
- Other tracks below this track
- Other tracks above and below this track.
- Other track(s) and this track selected => TO BE DECIDED: Three possible cases:
- Other tracks above this track
- Other tracks below this track
- Other tracks above and below this track.
-
Ctrl + Click:
- Toggles selectedness of this track. Other tracks retain current state.
The reason I am asking about all of the details is that “someone” has to decide on the details. If we don’t specify the details, then we have no say. If we want a say, then we need to decide before passing it over to a developer. Of course, the developer may still decide to overrule any details that we specify.
-
I agree with your left click scenario
-
I agree with your Ctrl+click scenario (this is similar to the Windows Explorer paradign)
I need to think more about the Shift modifier stuff.
I seem to recall long discussions with Gale re the Ctrl & Shift modified behaviors …
Peter.
With Shift+click Microsoft Windows Explorer mostly seems to pick above - but I don’t spot an underlying consistency - but I’m sure thate must be one (it is programmed after all).
Audacity currently seems to favour downwards (removing selection fro the upper tracks)
And with a selection present Shift+click in a track modifies the selection in Audacity currently
:-/
Peter.
But basically we need to ape the current behavior that we have when clickiing and modified clicking in the TCP “white space”.
The compolication is that with a pukka button it can
a) stay down on depression - requiring second depression to pop it up
b) pop up immediately after depression action
I tend to favor b) as that is the less complicated of the two allows just to mimic existing “white space” TCP behavior.
Peter.
A subtle difference with a “button” is that it is like a “switch”, it is either “latching” (like a light switch), or “non-latching” (like a doorbell).
Whichever type it is, it is generally assumed that if you can switch something on with the switch, then you can also switch it off with the same switch. That is not currently the case with “click in any free space to select”, but with a switch / button, I think the expectation is different. If clicking the button selects the track, then clicking it again must deselect the track.
Audacity mostly selects from the “most recent previously clicked” track, to the current “Shift + Click” track.
but I notice exceptions to this rule (“bug”?):
- Take a project with 3 tracks
- Click the 1st track
- Shift + Click the 3rd track
- Shift + Click the 2nd track
On step 4, the selection is from the 1st track to the 2nd track, even though the 3rd track was clicked after the 1st track.
You may say: “Yebut, the click on the first track was an unmodified click, so that’s the one that counts”.
OK, so try this:
- Take a project with 3 tracks
- Click the 1st track
- Ctrl + Click the 3rd track
- Shift + Click the 2nd track
On step 4, the selection is from the 3rd track to the 2nd track, even though the 3rd track has not received an unmodified click.
and to verify that we have inconsistent behaviour in the fringes: - Take a project with 3 tracks
- Click the 1st track
- Ctrl + Click the 3rd track
- Ctrl + Click the 1st track (1st track is deselected, leaving only the 3rd track selected)
- Shift + Click on the 2nd track
On step 4, the selection is from the 1st track to the 2nd track
I’m not convinced that the controlling logic is completely correct.
The track sticks selected, but the button has no personality.
I select multiple tracks by Shift-Clicking. De-select one track with Command Click (Mac) or Control Click (whatever is Windows normal).
De-select everything but the hero track by just clicking.
We’re making formal the “click in a dead place” process.
Koz
I did notice the odd behavior if you select out of order. It’s been that way forever?
Koz
It changed a couple of years ago.
If I recall correctly, prior to that there was only Click and Shift+Click (no “Ctrl + Click”). The behavior was consistent, but one of the developers decided it should mimic the behavior in Windows File Explorer. So it was “improved” by adding Ctrl + Click and rapidly went through a long series of different inconsistent behaviors, eventually being “fixed” by another developer as we have it now.
Full disclosure: I don’t personally like the “history based model” in which the actual tracks selected may depend on which track you clicked 2 hours ago. Too often I find that when I shift+click, I get different tracks selected from what I expected or intended.
Personally I think that it should be possible to reliably predict which tracks will be selected, just from looking at the current state and applying simple, logical rules.
Gale closed the previous bugzilla entry regarding this, with the comment:
I think three of us were prepared to try the history-based method or did not outright oppose it, so that is what we have, at least for now.
If the method of track selection is to be changed (using buttons), then I would like to see it work in a logical and predictable manner that does not require remembering which track you clicked on last, and which modifier key you used when you clicked it.
I don’t agree that track selection has to follow the same pattern as Windows File Explorer.
You could obviate the distinction between a latching button and a momentary switch by using a non-latching button whose label changed between “Select” and “Deselect” (or “Unselect”).
I strongly agree with the concept of adding this button!
I like Steve’s image example of a TCP with more controls. I also think it’s very important to open all of these controls to control via keyboard shortcut.
Without actually having something to try out, I’m not sure how to comment on Right-Click/Shift-Click/Control-Click/Left-Click, but…
Right-Click is obvious - open a context menu.
Left-Click should toggle the selectedness of the button’s track deselecting all other selected tracks.
Shift-Click & Control-Click with no other tracks selected should act just like a Left-Click (i.e. toggling selectedness).
Control-Click with other track(s) selected should toggle the selectedness of the button’s track leaving all other tracks as-is.
Shift-Click with other track(s) selected is the only real outlier; the paradigm is “extend the selection”. There are 3 possible situations: only selected tracks above; only selected tracks below; selected tracks both above and below. In the 2 “only” situations it seems reasonable that the selection should be extended thusly:
track 1 selected
track 2 unselected
track 3 selected
track 4 unselected
track 5 unselected
track 6 Shift-Clicked while currently unselected
should result in tracks 1, 3, 4, 5 & 6 selected leaving 2 unselected. Similarly:
track 1 Shift-Clicked while currently unselected
track 2 unselected
track 3 selected
track 4 unselected
track 5 selected
should result in tracks 1, 2, 3 & 5 selected leaving 4 unselected.
In the “outlier” situation my preference would be to combine the 2 above situations:
track 1 selected
track 2 unselected
track 3 selected
track 4 unselected
track 5 unselected
track 6 Shift-Clicked while currently unselected
track 7 unselected
track 8 selected
track 9 unselected
might result in tracks 1, 3, 4, 5, 6, 7, & 8 selected leaving 2 & 9 unselected. This is contrary to the common “extended in only one direction” typically seen in Windows applications which offer Shift-Click selection functionality. Without giving the user a method to control the direction of an extended Shift-Click selection (my preference - a radio button in Preferences: “up”, “down”, “both” power to the people) it’s hard to pick one of the 3 possibilities.
OK so what Bug number was that ?
Hi Ed, long time no see …
Sounds good to me
+1 for TCP controls to be open to having keyboard shortcys assigned (we had a request for just that on the Forum earlier today)
Peter.
Thanks for the comments Ed. I think we’re all pretty much on the same page down to “Shift + Click”.
I’ve also been thinking about “shift + click” = “extend”, and NOT restricting to one direction.
I think I prefer your scheme to the current scheme, though you have so far only described cases where the “shift+clicked” track starts off as unselected.
I expect we can readily agree that there are several reasonable approaches, and none that will suit everyone all of the time.
One thing that I like a lot about the scheme you describe, is that it allows discontinuous “blocks” of tracks to be selected quickly and easily. For example, if you start with 9 non-selected tracks and you want to end up with tracks 1,2,3 and 7,8,9 selected:
Key:
C = Click
SC = Shift + Click
CC = Control + Click
X = Selected
0 = Not Selected
= “leads to”
—> = a non-click change filled in by a Shift+Click
1 0 > C > X
2 0
3 0
4 0
5 0
6 0
7 0
8 0
9 0
1 X
2 0 —> X
3 0 > SC > X
4 0
5 0
6 0
7 0
8 0
9 0
1 X
2 X
3 X
4 0
5 0
6 0
7 0 > CC > X
8 0
9 0
1 X
2 X
3 X
4 0
5 0
6 0
7 X
8 —> X
9 > SC > X
Done
bug 1484 (bug 320 also involved).
One thing that we have now, is that if you get the track clicking order right, you can also deselect multiple tracks without deselecting all tracks.
Example:
- 4 track project
- Click track 1
- Shift click track 4
Tracks selected: 1, 2, 3, 4 - Shift Click track 2
Tracks selected: 1, 2.
This ability to “deselect multiple tracks but not all” can be useful, though it relies on track 1 being the “historic anchor”.
This leads to the question: how does Shift+Click behave if the track is already selected?
Having given this some thought, I’m thinking that it should deselect the current “block” of sequential selected tracks.
Example. with 9 tracks:
1 X
2 X
3 X
4 0
5 0
6 0
7 X
8 X
9 X
To deselect tracks 1,2 and 3, Shift+click on any of the tracks in that block. Example:
1 X > SC > 0
2 X —> 0
3 X —> 0
4 0
5 0
6 0
7 X
8 X
9 X