Probleme mit japanischer IME

[Rojetto]

Meldung von bored42 aus Neo-IRC:

1. Das Hin- und Zurückschalten zwischen Bone und JP-Tastatur geht dann nicht korrekt, wenn man im aktivierten Kana-Input etwas getippt hat und danach zurück schaltet:
   Dann ist Ebene 4 (nicht Ebene 3, wie ich gestern fälschlicherweise geschrieben habe) dauerhaft eingerastet und lässt sich auch nicht lösen. Man muss noch einmal auf die JP-Tastatur und zurück wechseln, dann ist wieder Ebene 1 aktiv.
   Das Umschalten funktioniert im Romaji-Modus. Das Problem scheint nur dann aufzutreten, wenn der Kana-Input aktiviert ist. In diesem Modus wird das Tastur-Layout komplett umgebaut, so dass man direkt Kana eingeben kann.
   Der Kana-Input ist standardmäßig nicht aktiviert, und muss zunächst im Kontextmenü der IME aktiviert („Kana-Eingabe“) werden. Danach kann man mit z.B. ALT+^ zwischen QWERTY und Kana hin- und herschalten.
   Die so eingerastete Ebene 4 ist auch nicht vollständig operabel: Die linke Seite (Cursor-Tasten, etc.) reagiert gar nicht mehr – die rechte scheint aber noch zu gehen.
   Der gleiche Effekt tritt auch ohne reneo auf.
2. Kana-Eingabe funktioniert nicht vollständig:
   Grundsätzlich scheint die Kana-Eingabe nicht vollständig zu funktionieren. Es lässt sich z.B. »ず« nicht eingeben (Tastenfolge »rü« auf einer QWERTZ-beschrifteten Tastatur). Stattdessen kommen, wenn man das »ü« mermals drückt, das »´« Totzeichen. Das »ü« ist auf der Kanatastatur ein »゛« und ebenfalls ein Totzeichen.
   Ohne reneo funktioniert die Kana-Eingabe vollständig.

Die Tests habe ich in notepad++ gemacht.

[Rojetto]

Beide Probleme konnte ich nachstellen:

1. Hängt sehr wahrscheinlich damit zusammen, dass kbdneo den Kana Modifier für Ebene 4 missbraucht. Wenn der gelockt wird, sieht ReNeo dann diese Taste die ganze Zeit als gedrückt. Entweder man versucht in kbdneo davon weg zu kommen, oder man versucht in ReNeo beim Wechsel den Lock zu deaktivieren.
2. Liegt daran, dass ReNeo nur beim Fensterwechsel das Layout prüft. Nach einem weiteren Fensterwechsel lässt sich das Zeichen eingeben, ReNeo hat sich korrekt deaktiviert. Hier könnte es nochmal lohnen, nach dem richtigen Event zu schauen.

[natsume42]

Nach Möglichkeit sollten sich die einzelnen Sprachlayouts nicht gegenseitig beeinflussen. Daher wäre es schön, wenn:

1. Beim Umschalten auf neo die bisherigen Modifier-Zustände gemerkt würden → 4
2. Beim Umschalten auf neo die letzten Modifier-Zustände von neo neu gesetzt würden → 3
3. Beim Umschalten weg von neo, die aktuellen Modifier-Zustände gemerkt würden → 2
4. Beim Umschalten weo von neo, die vorherigen Modifier-Zustände wieder gesetzt würden → 1

Auf diese Weise sollten die Modifier-Zustände der verschiedenen Layouts über Wechsel hinweg erhalten bleiben.

Evtl. ist WM_INPUTLANGUAGECHANGE der richtige Trigger.

[Rojetto]

Zu 1.: Meine ersten Versuche sind etwas durchwachsen. Mit SendInput und dem VK_KANA kann man das Problem beheben (habe testweise diesen Kana-Schalter auf 4(4) gemappt). Leider macht man das blind, da es nur den Zustand vom einen in den anderen schaltet. GetKeyState(VK_KANA) sieht so aus als sollte man damit den Kana-Zustand lesen können, das gibt aber irgendwie immer 0 zurück. Mit Capslock funktioniert es hingegen...

[natsume42]

Bin mir nicht sicher, ob es hilft, aber ich habe folgendes gefunden: Re: How to get Kana toggle key state?
Außerdem gibt es noch eine zweite Funktion: GetKeyboardState. Vielleicht hast du damit mehr Erfolg.

[Rojetto]

Zu 1.: Ist nach meinen Tests gelöst.

Zu 2.: Bei jedem Tastendruck das Layout zu prüfen verschlechtert die Performance deutlich messbar. Ohne Layoutprüfung ist man bei ca. 10-20 μs, mit Prüfung bei ca. 100 μs. Dafür dass in 99.99% der Anschläge eben nichts gemacht werden muss finde ich das nicht angemessen.

Die Sache mit WM_INPUTLANGUAGECHANGE (Ansatz von hier) habe ich nochmal ausprobiert und weiß jetzt wieder, warum ich das letztes Mal aufgegeben hatte. Die Hook Procedure die man dort übergibt muss in einer eigenen DLL liegen, weil sie in den Prozess des jeweiligen Top-Level-Fensters geladen wird. Davon braucht man dann auch zwei, für 32-Bit und 64-Bit-Anwendungen. Bevor es damit weitergeht müsste ich mich intensiv belesen, wie dieser ganze Kram funktioniert, oder jemand mit Erfahrung nimmt sich der Sache an. Vorher sollte man aber schnell testen, ob dieses Event überhaupt alle benötigten Fälle abdeckt (also sowohl Wechsel der Sprache, z. B. Deutsch -> Japanisch, als auch der Eingabemethode, z. B. Neo -> QWERTZ).

Eine andere dreckige Variante wäre, z. B. alle 2 s das Layout zu prüfen.

Bearbeit: WM_INPUTLANGUAGECHANGE deckt in meinen Tests alle benötigten Fälle super ab (in einem Testfenster).

[natsume42]

Cool, dass du 1. bereits lösen konntest. Sobald du einen neuen Release anbietest werde ich das auch gleich nutzen. Danke!
Punkt 2 klingt nach einer schrägen Sache…

[Rojetto]

Je mehr ich in Punkt 2 arbeite, desto haariger wird es 😄 Denke nachwievor das ist so lösbar, könnte aber noch eine Weile dauern. Die anderen Sachen sind in v1.2.0 aber schon mal online.

[natsume42]

Danke für den Release. Wird umgehend installiert.

[yue-dongchen]

Zu 1.: Ist nach meinen Tests gelöst.

Zu 2.: Bei jedem Tastendruck das Layout zu prüfen verschlechtert die Performance deutlich messbar. Ohne Layoutprüfung ist man bei ca. 10-20 μs, mit Prüfung bei ca. 100 μs. Dafür dass in 99.99% der Anschläge eben nichts gemacht werden muss finde ich das nicht angemessen.

[...]

Eine andere dreckige Variante wäre, z. B. alle 2 s das Layout zu prüfen.

Bearbeit: WM_INPUTLANGUAGECHANGE deckt in meinen Tests alle benötigten Fälle super ab (in einem Testfenster).

Deiner Neo-Implementierung bin ich dankbar, da ich den vollständigen Funktionen unter Linux angewöhnt bin, und benutze seit einer Woche auch Windows.

Nr. 2 trifft mich besonders hart, da ich nebenbei zwischen einer Arabisch-Belegung sowie Chinesisch-IME oft spontan wechseln muss. Die "dreckige Lösung" (deiner Beschreibung nach — indem aller z.B. 2 Sekunden das Layout geprüft wird) wäre mittlerweile eigentlich besser als gar nichts, oder?

Dongchen