Bugzilla – Bug 815
Enh: Clicking Play-at-Speed Toolbar Play button pushes down Transport Play button
Last modified: 2021-12-30 15:30:31 UTC
My project for improved icons for the two play buttons (making both of them change images for shift and for ctrl) left this behavior, that several on the mailing lists dislike: If you press either the play or the transcription toolbar button (or hit a shortcut key that invokes either), then both buttons have pushed appearance for the duration of play. What should be the correct behavior? 1) Transport play button only is pressed, regardless whether play is at normal speed. 2) The button that was clicked, only, is pressed.
Created attachment 537 [details] Fix it the first, easy way. This patch causes transport button only to be pressed during playback, even if the user clicked on the transcription button. That might not make the best sense, but it is easiest and behaves as 2.0.6 does.
Created attachment 538 [details] Alternative, more complicated fix Alternative causes either transport or transcription play to stay down during playback but not both. Also noticed and fixed this inconsistency: During recording the transport play was disabled but transcription play was not. Now both are disabled.
Paul, what are the steps to reproduce this? I thought this was fixed and don't see what you describe on Windows. Are you testing in HEAD?
That's odd. Did Leland do something to ControlToolBar.cpp that incidentally fixed this? Complaint a month or two ago was that both play buttons appeared "pressed" for the duration of play, and that was a consequence of things I did. But Gale is right that in head now, only the Transport play button stays depressed. That restores 2.0.6 behavior, it is true. But I have done some work so that either Transport or Transcription play (but not both) appears pressed, appropriately to the button push or the command. Perhaps that is a little bit preferable.
PX->P2. Regression. RM needs to decide if this is a show stopper. I think not only is it not by any stretch of the imagination a show stopper, but that also the bug as described is actually closed. Current behavior is that clicking the transcription play button causes the transport button (only) to stay down. I think that we do not need to open a new bug for 'the wrong button' being down as this is a logical way to do it. Needs a decision from RM though.
Bug 804 duplicated this complaint. Revision 13800 made a fix. The result of that fix is the old behavior, that the transport Play button, only, appears pressed for the duration of play. My proposed patch has the different effect that the button that was clicked, only, appears pressed. That may be transport Play or transcription Play. The latest comment at 804 said "Bill wrote: > Click the Play button or press spacebar, and both the Play and Play-at-speed > (Transcription toolbar) buttons show the “pressed” state. Similarly, click the > Play-at-speed button and both play buttons show the pressed state. > It should be one or the other. That's not how it worked before. After releasing click on the Play-at-speed button, the standard Play button lights up, indicating you can restart play at standard speed. That's the behaviour the fix has gone back to." But this confuses the pressed appearance ("lighting up") of a button with its enabled state (dark green, not gray).
(In reply to comment #6) I think the least confusing and least overhead solution is to rename this bug from "Transport and Transcription play buttons should not both appear pressed" (already fixed and closed at bug 804) to what it should have been in the first place "Transcription Toolbar Play button should be down after clicking it, not Transport Play button". I therefore reopened this bug. The current bug title is not a regression on 2.0.0 or on any version I can find. 1.3.3 had neither Play button down after clicking either button. Given that, I'm just going to demote to P4 Enhancement. I agree it would be better for the button that is activated to stay down but it isn't a show stopper IMO. I'm confused whether either patch attached here does only what the new bug title says, so pending clarification, removed "patch" keyword.
As mentioned, the second patch combined a fix for this and the problem in bug 816. Now bug 816 has a patch that fixes that other problem, only. I could make a third patch for 815, only... which would duplicate a little bit of the code for 816, because both fixes required a new method added to class TranscriptionToolBar.
(In reply to comment #8) Paul wrote: > I could make a third patch for 815, only... which would duplicate a little bit > of the code for 816, because both fixes required a new method added to class > TranscriptionToolBar That would sound fine to me, a patch for this bug only that keeps bug 816 fixed.
Sorry, I was confused. The first version of my patch (now obsoleted) was the cause of what I reported in bug 816, which is now rightly invalidated. The second version of the patch needed the extra work to avoid introducing that misbehavior during recording, so the patch should not be separated into two parts.
I am contemplating a third (!) play button in Audacity 2.1.1, on the Spectral Selection toolbar, to play selected frequencies only. That would complicate this fix further, to depress the correct one of three play buttons.
(In reply to comment #11) Paul, proposals for future features belong on wiki.
Created attachment 565 [details] Updated fix. Merged with head and removed an unnecessary line.
Created attachment 566 [details] Updated fix, again. I made sure in this version that the correct button appears pressed, even if you don't use the button but instead use shortcut keys for the related commands.
Steps to reproduce say: "Correct behavior: Just the transcription toolbar button should be down." I'm not sure that is the correct behaviour. The normal Play button and the Play at speed button work differently from each other. When the play button is pressed, two commands are issued. The first is to stop playback and the second is to start playback. The button stays down for as long as playback continues. If pressed again, playback stops, then starts again. When the "Play at speed" button is pressed, a command to start playing at the specified speed is given. If pressed again, another command to start playing at the specified speed is given. The difference in behaviour can be seen clearly by the following steps: 1) Open a project with at least 30 seconds of audio 2) Select from around 15 seconds to around 25 seconds 3) Press "play" (for second part of test, "play at speed") 4) While the audio is playing, click on the waveform at about 5 seconds. 5) Press "play". Note that (because playback is stopped), the play region disappears and playback resumes from the cursor position at around 5 seconds. Repeat the above using the "play at speed" button. On step 5, note that the play region from 15 s to 25 s is retained and playback resumes from around 15 seconds. It seems to me that the "play at speed" button is behaving like a "momentary action switch", in that it is issuing a command to start an action each time it is pressed. (Momentary action switches are like doorbell switches - they return to the "Up" position after being pressed). The "Play" button also appears to be behaving correctly as it designed to indicate (by the down position) that Audacity is in "play mode".
I believe that this is more than an enhancement request - it certainly looks to me like erroneous behavior - certainly deserving of at lest P3 and a release note. What happens is the when the user clicks on the green play button in the Transcription Toolbar and holds it down that button chnges to showing as depressed. Once the user releases the button then the play-at-speed commences - but the Play-at-speed button is popped up and the normal Play button is shown as depresssed (and active). This just looks wrong. There is some sense in this, I suppose, as the user needs to press the Stop or Pause in the Transport Toolbar to manage the play-at-speed (as it has no corresponding Stop/Pause button in the Transcription Toolbar). So depressing the normal Play button in the Transport Toolbar draws the user's attention to the Transport Toolbar and the Stop & Pause controls there.
(In reply to Steve Daulton from comment #15) > It seems to me that the "play at speed" button is behaving like a "momentary > action switch", in that it is issuing a command to start an action each time it > is pressed. (Momentary action switches are like doorbell switches - they return > to the "Up" position after being pressed). > > The "Play" button also appears to be behaving correctly as it designed to indicate > (by the down position) that Audacity is in "play mode". I have commented on this impasse on the -quality list: http://audacity.238276.n2.nabble.com/Bug-815-Transcription-Toolbar-and-Transport-Toolbar-play-buttons-td7579543.html .
James wrote by email: >For my money, the 'correct' behaviour is to do away with the play-at-speed >button, and instead always use the play button AND the slider. >The slider should have a toggle button on it, that toggles between some >preset speed and a speed of x1. And always toggles back to x1 on opening >a new project to avoid a 'stuck in mode' problem for noobs. I am strongly minded to agree
Testing with 3.1.3 on W10 and macOS 12.0.1 Monterey This now works as Paul requested - he may have fixed this as part of his recent changes to Play, TQP and PAS
