Tk Source Code

macOS (since 10.8 Mountain Lion) has a system-wide feature called "dictation": speech to text by pressing Fn (or some configurable key) twice, or using Edit > "Start dictation".

Several months ago, users of Tcl::pTk (Perl wrapper for Tcl/Tk) noticed that did not work as expected in their programs; I could observe the issue in Tcl::pTk's demos. However I noticed that in the Tcl/Tk widget demo, it seemed to work fine for any entry and text widgets that I tried: https://stackoverflow.com/a/51434086/4896937

At the time I was using 8.6.8 on macOS 10.13 High Sierra, and thought this was probably just a Tcl::pTk issue (though I could never identify a cause in Tcl::pTk). I've since upgraded to 8.6.9.1 on macOS 10.14 Mojave, and it seems somewhat more difficult now to use dictation even in Tcl/Tk. In the widget demo, I can only get dictation to work in text widgets, not entries.

I've now tried to compare simpler cases such as a window containing only a single entry or text widget:

package require Tk
entry .e
pack .e

or

package require Tk
text .t
pack .t

When trying these, dictation does not work right away. Sometimes the system "waits" until I focus on something else to dictate into—even another app—before showing the dictation balloon.

This is a rather basic accessibility feature; it would be great if this worked reliably. Is there some special sequence of doing things for dictation to reliably work? (Should I not be using it/is it somehow inherently "broken"?) Why does the widget demo (in some cases) work whereas these simple tests do not?

I imagine this could be more of a question involving the Cocoa API, which I'm not knowledgable on. Some brief research on this says there needs to first be a menu in the menu bar called "Edit", but that seems to not help universally. (It seems the popular Q&A's out there on this tend be developers so bothered by the presence of "Start dictation" in their app's Edit menu that they just want it gone, which is unwise because Mac users expect dictation to be available wherever they can type.)

I wonder if this issue has to do with how Tk is built and/or embedded. I still have yet to build Tcl/Tk Aqua any way other than with the Makefile generated by unix/configure, and dictation still never works with recent core-8-6-branch. However I tried Kevin Walzer’s recent build of TkChat 1.500 beta on macOS 10.15, as well as the 2020 build of PortAuthority on macOS 12, and dictation works reliably for both.

With commit |769f555de I am not seeing any problems with the dictation. I have tried several times on my macbook air as well as on my mac mini with a bluetooth microphone. When I select "Start dictation" from the Edit menu the popup appears consistently and once the microphone icon appears in the popup I can dictate. With the widget demo I was able to dictate into entry, text and combobox widgets.

I realize that unreliability may be a difficult thing to reproduce reliably, but it works for me.

In recent core-8-6-branch, macOS dictation seems to have gone from unreliably appearing to reliably never appearing.

Dictation appears to only require a properly working NSTextInputClient implementation, so a little more improvement to the one in Tk (tkMacOSXKeyEvent.c, similar to what was done for handling PressAndHold) might be all that's needed for this to finally work right. But I have not yet spotted what is wrong or missing.

Some NSTextInputClient usage examples exist which might be useful for comparison: Firefox, Apple sample code, Qt5. I've only verified that the Qt5 one works with dictation.

What I observe so far is that trying to activate dictation invokes at least the following in Tk:

validAttributesForMarkedText
selectedRange request
selectedRange request
hasMarkedText request (returning 0)
selectedRange request
firstRectForCharacterRange (theRange = {.location = 0, .length = 0})
validAttributesForMarkedText
selectedRange request
selectedRange request
hasMarkedText request (returning 0)
selectedRange request
firstRectForCharacterRange (theRange = {.location = 0, .length = 0})

Is a dedicated accessibility API even needed for this feature to work though? I was under the impression this is something macOS provides Cocoa apps "for free", that way users would find it works with any existing apps.

Tk has no support for accessibility API's on any platform. It would be a great, if complicated, project for someone to take on.