- Status Closed
- Percent Complete
- Task Type Bugs
- Category User Interface
- Assigned To No-one
- Operating System SW-codec
- Severity Low
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#7313 - Current menu item not spoken after accepting or cancelling a choice setting
After accepting or cancelling a choice setting, the current menu item (i.e. the name of the setting) is not voiced as it should be. To explain by example:
1. Ensure that voiced menus are enabled.
2. From the main menu, select Settings→General Settings→Bookmarking→Bookmark on stop.
3. Observe that the possible choices are spoken correctly as you move around the menu.
4. Exit the choice without accepting (e.g. press left on the Iriver H300).
5. Observe the return to the Bookmarking settings menu. However, the current option, “Bookmark on stop”, is not spoken.
6. Repeat this procedure, but accept the setting in step 4 (e.g. by pressing select) instead of cancelling it. The same observation applies (step 5).
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
This patch fixes this bug. The patch also fixes other instances of this bug, such as items like System→Rockbox info which call a function. Additionally, the patch fixes the bug where exiting from a sub-menu of a context menu would speak the parent menu item, even though the menus are exited; e.g. if you enter WPS context menu→Sound settings→Volume then press back, “Sound settings” was spoken, even though pressing back from Volume exits the menus.
The attached patch hopefully does the same as yours, except I tihnk its a bit cleaner, I havnt tested it because i can grab a voice file atm, so please let me know
Ah. I did consider using a variable like this, but wondered whether it would be less efficient, as the talk_item check has to be done even if there should be no speech.
Your patch does not fix the bug I described above regarding sub-context menus with the MENU_EXITAFTERTHISMENU flag. This patch fixes. (There should be no speech if we are exiting the loop.)