Pronounce button: stop if already playing #1002
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit provides a way to stop a long "pronunciation" with a button click or Alt+S shortcut. Such long "pronunciations" are common in Wikipedia - musical compositions, spoken articles, etc. They can be triggered inadvertently or automatically when "Auto-pronounce words ..." options are enabled. Alternative ways to stop playback without this commit: 1. Request a definition of a different word. An obvious solution, but not applicable when the user wants to read the long-pronounced definition for some time. 2. Request a definition of a different word in another window (scan popup or main), or another tab. This is a less obvious, less convenient, but more universal solution. 3. Open Dictionaries (shortcut - F3) or Preferences (shortcut - F4) window, then close it (shortcut - ESC). This is a convenient solution, but it is not obvious, and it works only in the main window, not in the scan popup window. Furthermore it works almost by chance: due to the destruction of the scan popup window and its article view, which happens to stop playback. This accidental "feature" might disappear with some future code reorganization or improvements.
This commit ensures the ability to stop main window's playback in scan popup and vice versa. More generally, if playback is active, it is always possible to stop it, even if there is no audio link inside the article definition in the focused Goldendict window.
This commit facilitates discoverability of the stop playback feature.
The tooltips are replaced quite often if "Auto-pronounce words ..." options are enabled. So it makes sense to minimize the amount of work that is done to swap the tooltips back and forth.
When the user triggers a pronounce action to listen to a word, the corresponding button becomes checked. If the requested audio resource is available, AudioPlayerInterface's promises allow to guarantee correct button checked state. However if the audio resource request fails, audio player is not notified, and so the pronounce button remains checked even though no pronunciation takes place. This commit detects synchronous audio resource acquisition failures and unchecks the triggered pronounce button. Unfortunately detecting asynchronous audio resource downloading failures is more difficult and not implemented in this commit. So it is still possible to end up with a wrong pronounce button checked state. For example, requesting a missing DSL audio resource triggers a search across all dictionaries in the current group, which can fail asynchronously. Fortunately, the wrongly checked button state should not cause much inconvenience in this case because the user can simply click the button twice; the next pronunciation or playback stop event also fixes the button state. I have tried an alternative solution - simpler and more reliable: uncheck the pronounce button immediately in MainWindow::onPronounceTriggered() and rely on an AudioPlayerInterface's signal to make the button checked when playback commences. Unfortunately this solution causes a noticeable button check state flickering with network audio resources. Even worse, if the resource takes some time to download, it can lead the user to trigger the pronounce action again after an apparent "failure" as indicated by the immediate button unchecking. Try for example the "Michael Jordan" Wikipedia article, which contains a large audio resource.
…o pronounce-button-stop-if-playing
…o pronounce-button-stop-if-playing
…o pronounce-button-stop-if-playing
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request provides a way to stop a long "pronunciation" with a button click or Alt+S shortcut. Such long "pronunciations" are common in Wikipedia - musical compositions, spoken articles, etc. They can be triggered inadvertently or automatically when "Auto-pronounce words ..." options are enabled. See individual commit messages for more details.
I'm not sure if changing the pronounce buttons' tooltip back and forth is worth the amount of code in the third and fourth commits. These two commits are optional and can be removed.
The pronounce button checked state can temporarily get out of sync with the actual audio playback state in case of asynchronous resource downloading errors, as described in the fifth commit message. I don't think that this is a critical issue. The situation can be improved by merging my other pull request #972. See the merge commit message in https://github.com/vedgy/goldendict/tree/wip-pronounce-stop-if-playing-and-from-next-dictionary for details [this is a separate branch that merges my pronounce-button-stop-if-playing branch (on which this pull request is based) and my wip-auto-pronounce-from-next-dictionary branch (on which #972 is based)].
There are 3 old
audioPlayer->stop();calls inArticleViewmember functions. They were briefly discussed in comments to #983. With the changes in this pull request there is a universal reliable way to stop audio playback, so there seems to be little reason to stop it before showing Dictionaries or Preferences windows (this might be marginally useful to avoid long annoying "pronunciation", which can't be stopped while one of these modal windows is open). Stopping playback before loading a new article has some benefit though: it can reduce the delay before the next pronunciation starts, because some audio player implementations may take several hundred milliseconds to stop. This delay reducing is not consistent however: clicking a Back or Forward navigation button does not stop current playback. Overall it is not clear to me whether these stop function calls should be removed or not. Perhaps they should if there is a common use case, for which stopping playback in these situations is undesirable.