I believe this is a problem with Audacity and not Keyman. However, I am hoping that community might help me understand or figure out the (likely) problem so that I can better provide a bug report. I already opened a bug report early last year and it seems 3 versions of Audacity later, no fix. I’m turning to the community here who may have more experiences with the same/similar behavior and what the root cause was (and how to fix), so that I might get some movement on their end.
OS: Windows 10 (builds 1607, 1703, and 1709)
Keyman version: 9.0.528 (and previous two updates) - I have Pro, but installed the Free version on another computer and encountered the same behavior
Keyman keyboards: all
Audacity versions: 2.2.1; 2.1.3; 2.1.2
Behavior:
After installing an updated version of Audacity, nowhere in its GUI interface does it recognize that the Keyman keyboard is enabled. The regular, standard Windows keymapping is used. I originally noticed this with the SIL IPA keyboard but installed several other keyboards and found none of them work. Installing the older 2.1.1 version of Audacity immediately recognizes Keyman (no reinstallation necessary).
This indicates that something changed in Audacity and not Keyman. I looked through the code for Audacity, but it is a reasonably large project and written in C which is pain for someone jumping into new code without any support documents.
What type of change could cause a program to no longer recognize Keyman in Windows 10? Let me know if I can provide additional information that might help!
Thank you for letting us know of this compatibility issue in such useful detail. I had a look also at the Audacity release history and one thing stood out to me with the 2.1.2 release:
This is our first release after migrating from wx2.8.12 to wx3.0.2 wxWidgets library.
Given the major version update of the wxWidgets library, that’s where I’d be looking first. I’ve added issue 523 into the Keyman issue database for us to also dig into this further, but if you’d like to pursue it with the Audacity (or wxWidgets) team as well, that’d be most welcome.
Great, thank you for the pointer! Not knowing all the background of both programs (and their libraries), I would not have picked up on this.
Before moving on your suggestions, what I would like to know is how things should proceed, if this is indeed the source of the issue? I assume it would require a new wxWidgets version and also the next Audacity release (or some future release, at least) would need to update to that version as well? Or, would the process be slightly different?
Having a better understanding of the likely resolution path is useful in how I present the issue (again in the case of Audacity).
Without more research, it’s not clear if both Audacity and wxWidgets need update or just one of them. wxWidgets may well be fine but Audacity using it in a mode that doesn’t permit Unicode input. Audacity will almost certainly need a new version. Remember that I am just guessing that a non-Unicode window is the issue
I opened up a ticket with both…or attempted to. It may be better for a developer, rather than an end-user to do so, provided the treatment I received. Audacity people keep trying to associate this bug with a MacOS bug which is restricted to diacritics: at bugzilla dot audacityteam dot org bug #1778 (I can’t post links, because being a new user, apparently)
This issue is that none of the keyboard mappings (not even single character mappings) are recognized from Keyman. I replied stating all of these details, but have been ignored since their reply that the bug is something that it isn’t… I’m rather disappointed with their current attitude regarding it.
I also tried opening a wxWidgets bug ticket and after providing the information they asked (about which components are used), their response was that standard “controls” are not used. Looking through the wxWidgets codebase, all the includes and objects looked the same to me…
As an end-user unfamiliar with the codebase from both, even though there is obviously a bug somewhere, I’m essentially ignored because I don’t know enough to be taken seriously.
I’ve just installed 2.2.1 here and tested. I can reproduce the issue you describe, e.g. in a Label track. The issue doesn’t arise in the Metadata window. A high-level diagnostic showed that Audacity is capturing keystrokes before Keyman sees them and doing an internal translation to characters using Windows API calls. This is not an uncommon pattern for cross-platform projects but it cannot duplicate the Windows internal character translation, even for Windows keyboards, 100% perfectly. So it’s the wrong way to go… I’ll continue investigation in the Github report at https://github.com/keymanapp/keyman/issues/523
Right-click on the label and click Edit. There you get a standard edit control that works fine.
Also, maybe worth noting that the label control in Audacity doesn’t work with Chinese/Japanese/Korean IMEs shipped with Windows either. The best solution would be for Audacity to use a standard edit control.
Thanks for the help so far! I wasn’t able to reply earlier.
Yes, I forgot to include that copying and pasting is possible. Problem is that it is not a suitable workaround when work on 30+ minutes and tons of Labels. The extra steps for #2 also add too much burden, process-wise.
I have Japanese in Windows (not Keyman) installed and I just confirmed what you said. It continues to write in the default keyboard. It does recognize Japanese in some other fields, such as the Save Project As dialogue.
I can write back to the feedback@audacityteam.org email address which is the one they identify for bugs. You need to contact them also to request a Bugzilla account anyway. I’m not sure if you would actually want that account for a one-off situation (or if they would give it). I’ll send a link to the Github issue that you created.
I agree that the workarounds are not viable. I note the bugzilla item has a reference to our github issue already, so they are aware of it. Whether or not they are tracking it, I don’t know. We’d be happy to help one of their devs resolve the problem but I’m not that keen on trying to write a PR myself – too much code to come up to speed with and not enough time!
Well, I received a response thanking me (really you) for tracking down the
issue, but no indication of it being opened as a new bug or being updated
with that current bug… I am going to try to reply their email and
including your Github email. I hope you don’t mind! It might be better
for you to jump in, or at least be able to!
