Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic voice search (after delay) #18879

Open
hugbear opened this issue Jan 8, 2024 · 0 comments
Open

Automatic voice search (after delay) #18879

hugbear opened this issue Jan 8, 2024 · 0 comments
Labels
Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning

Comments

@hugbear
Copy link

hugbear commented Jan 8, 2024

Describe the idea (required)

The new feature would allow for the search parameters to be input through voice recognition software, as a complement and (delayed) alternative to keyboard-entered text. This has the potential to significantly reduce interaction with the device, which is especially useful while driving.
Optionally, upon finishing the voice recognition, OsmAnd would repeat the recognized text and wait for confirmation.

Tell us about the expected behaviour (required)

Upon invoking the „Search” dialog, if a configurable amount of time (seconds) has passed without keyboard input, OsmAnd would issue a short audio prompt and then it would automatically activate Voice Input to derive search terms. There should be user-configurable options to enable/disable this feature altogether, and to configure the time delay and the voice recognition engine.

Tell us about alternatives you've considered (required)

I'm currently trying to use automation software (MacroDroid) to manipulate OsmAnd's user interface to call a voice recognition engine (Futo Voice Input). So far (not very far...) it seems somewhat feasible, but even if successful it would be cumbersome to implement for users not familiar with that particular automation solution. A built-in option would make much more sense.

Context (optional)

Non-critical („nice-to-have”) feature request.

@vshcherb vshcherb added the Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning label Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Nice to Have Should be fixed but there is no priority or no possibility to fix it within current horizon planning
Projects
None yet
Development

No branches or pull requests

2 participants