-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Speak selection on macOs always reads the first word of the last line #5357
Comments
I'm afraid I dont care about this, it will require some special purpose |
Content in kitty is rendered by GLFW (OpenGL), not by native Cocoa or other UI frameworks integrated with system accessibility. https://developer.apple.com/documentation/appkit/nsaccessibility?language=objc I don't think this is a bug, but a feature request. |
yes you will need to find whatever api informs the OS of the current |
I'll take a look at it myself, at least the above hints should point me in the right direction, because I had no idea whatsoever where to start. |
Instead of looking up the API in Apple's awful docs, I believe it would be easier to use the following configuration. kitty -o 'map f1 launch --type=background say -- @selection' Select a word and press F1. |
The problem with that is that |
It looks like the accessibility framework will read the selected text instead of being actively pushed by kitty. (Only for the feature mentioned by OP) Is it possible to get the selected text of the (last) active kitty window in current OS window in |
On Sat, Aug 06, 2022 at 02:59:41AM -0700, page-down wrote:
@kovidgoyal
It looks like the accessibility framework will read the selected text instead of being actively pushed by kitty. (Only for the feature mentioned by OP)
How does the accessibility framework know what text is selected? kitty
or rather glfw has to tell it no?
Is it possible to get the selected text of the (last) active kitty window in current OS window in `glfw/cocoa_window.m`?
Executing `Speak selection` after switching windows will get the text correctly.
just implement glfwplatformsetprimaryselection, that should be good
enough to cover most use cases.
|
According to my experiments, the accessibility framework will call the following method (when enabled). - (NSString *)accessibilitySelectedText {
return @"the selected text in active kitty window";
}
Well, even implementing a fake primary selection (store and read when needed) doesn't look any better than using |
On Sat, Aug 06, 2022 at 03:48:52AM -0700, page-down wrote:
> How does the accessibility framework know what text is selected? ...
According to my experiments, the accessibility framework will call the following method (when enabled).
```objc
- (NSString *)accessibilitySelectedText {
return @"the selected text in active kitty window";
You can easily add a callback to get the current selected text, it will
require a fair bit of boiler plate to pass it through glfw.
|
I added API to glfw to fetch the current active selection, just FYI. |
I finally had some spare time to take a closer look at this when I saw @kovidgoyal 's commits and @page-down 's PR. I can confirm that it works and I want to thank you folks for taking a look at this even though it got shot down initially. This makes kitty usable for me as a visually impaired user. Great work! 👍 |
Describe the bug
macOs features an accessibility option known as 'Speak Selection', it works by selecting a portion of text followed by pressing a hotkey (default is Option-Esc), the macOs tts engine is used to read the selected text aloud. In Kitty this doesn't work properly, it always reads the first word of the current line. For example, my prompt featuers the current working directory as the first item, which results in it always reading the cwd aloud.
It seems that the selection is not properly conveyed to the OS.
To Reproduce
Steps to reproduce the behavior:
Environment details
Additional context
I also tried this with other shells than ZSH, it results in the same issue. For instance in bash, my prompt starts with
bash-3.2
. The speak selection voice will read 'bash` regardless of the actual selection.The text was updated successfully, but these errors were encountered: