Custom system's Unicode key labels confuse Plover's verbatim stroke output

[chambln]

Summary

I wrote a plugin to implement my own system for Plover. It uses Unicode's IPA symbols for its key labels:

ə p t w     f t ʃ l i
s b d r  *  n d g z ə

     a e   ɪ ʊ       

Problem is that when I do {PLOVER:ADD_TRANSLATION}, the 'Strokes' text box consistently gets the IPA symbols wrong, whereas it works fine when programmed to use ASCII substitutes.

For example I stroke bʊg in vim, then do {PLOVER:ADD_TRANSLATION}, then I stroke bɪgə in the 'Strokes' text box but 'bʊgʊ' appears (I expect to see 'bɪgə' of course). So it seems to replace all Unicode characters with the one it last received outside of that dialogue box.

Coming from chambln/plover-phenrsteno#5

Reproducing

1. Plug an NKRO keyboard into your computer
2. Install Plover 4.0.0.dev8+66.g685bd33 for Windows
3. Install plover-phenrsteno 0.1.19 from the Plugins manager
4. Restart Plover
5. Configure > System > Select 'Phenrsteno'
6. Enable output
7. Open your favourite text editor and stroke bʊg (SML on QWERTY)
8. In Plover click 'Add translation'
9. Stroke bɪg into the 'Strokes' text box (SNL on QWERTY)

You should expect to see bɪg appear in the text box, because that's what you stroked. However you actually see bʊg. You could also stroke, for example, -ʃ (O on QWERTY) but again see that LATIN SMALL LETTER UPSILON ʊ character instead.

Plover Version

Plover 4.0.0.dev8+66.g685bd33

System

Windows 10 Pro (build 17134.191)

[benoit-pierre]

I can't reproduce on Linux. It's hard to know with your report if it's a bug with Plover (Windows specific) output stage, or an issue with Qt.

Stroking bʊg/bɪg work when outputting to a text editor? Does it work in any text entry in Plover (e.g. the lookup dialog)?

[chambln]

I have no such problem in non-plover programs. The problem seems to happen within any of Plover's text boxes. The paper tape and suggestions displays however are working perfectly.

I played around some more and it seems that Plover chooses the first received Unicode character to represent all subsequent Unicode characters. It makes a choice again upon losing-then-regaining focus of any of Plover's windows.

Screencast to demonstrate #991 (3.2 MB)

[benoit-pierre]

OK, so the next question is: is it a font rendering bug with Qt (on Windows), or an issue with it's handling of key events? Probably 2 if the output is valid in other part of the UI.

I suggest installing the development environment and updating PyQt5, to see if maybe that's a bug that was fixed in a newer release.

[amikumanto]

One thing I want to add to this is that is it doesn't just happen with the verbatim stroke output, it actually happens with all non-ASCII output to a Plover window. For example, I have the following definition in my dictionary:

"STPHEUGT": "⸢Signet⸣",

In all applications outside of Plover, that stroke does in fact produce ⸢Signet⸣. However, if I open the Plover lookup window and try that same stroke, it comes out as ⸢Signet⸢. This happens in the dictionary update and editor windows as well.