Glfw: IME-Eingang

Eingabemethoden-Manager

ein paar mal editiert

Zu Ihrer Information ab dem aktuellen GLFW, bei dem Microsoft IME verwendet wird, um zB Japanisch einzugeben, scheint die während der IME-Eingaben gedrückte Taste die Anwendung direkt über normale WM_KEYDOWN-Nachrichten zu erreichen.

Ich weiß nicht einmal, was dies verursacht, in meiner einfachen Win32-Testanwendung mit einer trivialen Nachrichtenschleife fängt der IME diese Schlüssel korrekt ab. Ich erhalte WM_KEYDOWN mit VK_PROCESSKEY (229) und normalem unfiltriertem WM_KEYUP.

In GLFW erhalte ich ungefilterte Tastenwerte sowohl für gedrückte als auch für losgelassene.
Ich untersuche jetzt, was den Unterschied verursacht, um zu sehen, ob ich eine Lösung für GLFW vorschlagen kann.

OK, was passiert, ist, dass ich in meiner Anwendung wParam verwende, das einen virtuellen Schlüsselcode enthält und von IME gefiltert werden kann. GLFW in translateKey() verwendet HIWORD(lParam)&0x1FF, was Scancode ist und nie gefiltert wird.

Wenn Sie also eine von IME abgefangene Buchstabentaste drücken und wieder loslassen, läuft die Sequenz ungefähr wie folgt ab:

WM_KEYDOWN 229
13.36 Key 49 pressed
WM_KEYUP 78
13.43 Key 49 released

Um also etwas Ähnliches aus Sicht des GLFW-Benutzers zu emulieren, kann es ausreichen, dies zu translateKey() hinzuzufügen:

if (wParam == VK_PROCESSKEY)
    return _GLFW_KEY_INVALID;

Welche weder gedrückte noch freigegebene Ereignisse erzeugen.

Das Problem ist nun, dass es so viele Möglichkeiten gibt, die Low-Level-Daten zu interpretieren, aber ich glaube, und trotz der Tatsache, dass IME so viel mehr bietet und dies nicht das gesamte Bild ist, wäre dieses Verhalten das wünschenswert Standard und sehr vorteilhaft. Die allermeisten Anwendungen wollen bei der Anzeige des IME-Fensters nicht auf Tastendruck reagieren, was zumindest IME-basierte Texteingaben in die Anwendung ermöglichen würde.

Anwendungen, die 100% IME-bewusst sein wollen (bis hin zur Implementierung einer eigenen IME-Anzeige), was extrem selten ist, müsste viel mehr Nachrichten in großen Details verarbeiten, was wahrscheinlich nie der Umfang von GLFW sein wird (aber das kann man sich vorstellen .) GLFW kann in Zukunft WM_*-Hooks bereitstellen, damit interessierte Benutzer sie selbst bearbeiten können, und auch hier macht es keinen Sinn, diese Arbeit zu erledigen, es sei denn, es gibt einen wirklich guten Grund dafür).

Zu Ihrer Information Ich habe in meiner glfw-Fork Unterstützung für IME über IBUS auf X11/wayland implementiert.