Tastenkombinationen aus Alt+Mod3-Symbol funktionieren nicht #368

Wenn ein Mod3-Symbol in Kombination mit Alt verwendet werden muss, dann wird vom kbdneo Treiber das Mod3-Symbol nicht erkannt und stattdessen die nicht modifizierte Taste verwendet.

Beispiele:

MS Word: Langer Gedankenstrich → Alt + Strg + Minuszeichen
Mit Neo wird ein »™«-Zeichen eingefügt (Alt + Strg + T)

Emacs: Ersetzen (Alt + %) wird nicht erkannt

Der Fehler entsteht durch eine Mischung aus den tatsächlich gesendeten Zeichen bzw. Tasten und der Unkenntnis der Anwendungsprogramme von Ebene3. Der kbdneo-Treiber macht eigentlich nichts wirklich falsch, aber die Interpretation der Tasten ist unzureichend. Ich zeige das mal am Beispiel von Alt+% in Emacs.

Qwertz

Unter Qwertz werden dabei nacheinander gesendet:

VK_LMenu (die linke Alt-Taste) down
VK_LShift down
VK_KEY_5 down

Im Programm kommen mehrere mögliche Interpretationen an. Eine davon ist, dass zunächst der Alt-Status abgefragt wird, und zum anderen geprüft wird, was für ein Zeichen beim Rest (Shift, 5) rauskommt. Das wäre das %-Zeichen. Dies scheint aber ein manueller Vorgang zu sein, der Kenntnisse über mögliche Modifier erfordert.
Bin mir nicht sicher, was genau Windows an das Programm meldet, aber wahrscheinlicher (das wird später klar) ist es, dass das Prozentzeichen schon vorher intern gebastelt wird und bei Emacs nur »%« und der Alt-Status ankommt. Was ja sinnvoll ist.

kbdneo

Bei kbdneo wird entsprechend folgendes gesendet:

VK_LMenu down
VK_OEM_102 (Capslock-Taste) down
VK_KEY_M down

Bei Emacs kommt aber nur Alt+M an. Wäre also möglich, dass entweder Emacs beim manuellen Basteln Mod3 natürlich nicht kennt und nur das M erzeugt, oder dass Windows nur ein M (mit Alt) meldet. (Mir kommt gerade die Idee, dass Alt+Mod3 wiederum eine neue Modifier-Kombination ist, die aber nicht im Treiber gesetzt wird. Hier könnte man mit experimentieren, aber das ist aus folgendem Grund nicht nötig.)

ReNeo

Interessant wird es mit ReNeo als Ergänzung, da klappt das nämlich wieder. ReNeo blockiert die Mod3-Taste, sie wird also nicht ans Programm weitergeleitet. Stattdessen wird direkt ein Prozentzeichen (als Unicode) übermittelt:

VK_LMenu down
VK_PACKET (Unicode) down mit Scancode = Unicode von %

Bei Emacs kommt dann in jedem Fall ein Prozentzeichen mit Alt-Status an. Genau das, was man haben will, und es wird korrekt interpretiert. Habe das jetzt mit MS Office (mangels Verfügbarkeit) nicht getestet, aber ich gehe vom gleichen Verhalten aus.

Lösung

Bei empfohlener Verwendung von ReNeo als Ergänzung zu kbdneo – allein schon um eine vollständige Ebene4 und den Capslock zu bekommen – tritt dieses Problem nicht mehr auf. Schlaue Programme, die mit Tastenkombinationen arbeiten, sollten Eingaben damit korrekt interpretieren können, jedenfalls geht es nicht besser auf Treiberseite. Höchstens durch eine Art Kompatibilitätsmodus, so dass wieder dieselben Tasten wie bei Qwertz gesendet würden. Aber das klappt ja schon bei manchen Programmen und AltGr-basierten Zeichen wie { oder \ nicht so richtig. ReNeo unterstützt diesen Modus auch nicht (bei Mod3).

Der Fehler entsteht durch eine Mischung aus den tatsächlich gesendeten Zeichen bzw. Tasten und der Unkenntnis der Anwendungsprogramme von Ebene3. Der kbdneo-Treiber macht eigentlich nichts wirklich falsch, aber die Interpretation der Tasten ist unzureichend. Ich zeige das mal am Beispiel von `Alt+%` in Emacs. ### Qwertz Unter Qwertz werden dabei nacheinander gesendet: 1. VK_LMenu (die linke Alt-Taste) down 2. VK_LShift down 3. VK_KEY_5 down Im Programm kommen mehrere mögliche Interpretationen an. Eine davon ist, dass zunächst der Alt-Status abgefragt wird, und zum anderen geprüft wird, was für ein Zeichen beim Rest (Shift, 5) rauskommt. Das wäre das %-Zeichen. Dies scheint aber ein manueller Vorgang zu sein, der Kenntnisse über mögliche Modifier erfordert. Bin mir nicht sicher, was genau Windows an das Programm meldet, aber wahrscheinlicher (das wird später klar) ist es, dass das Prozentzeichen schon vorher intern gebastelt wird und bei Emacs nur »%« und der Alt-Status ankommt. Was ja sinnvoll ist. ### kbdneo Bei kbdneo wird entsprechend folgendes gesendet: 1. VK_LMenu down 2. VK_OEM_102 (Capslock-Taste) down 3. VK_KEY_M down Bei Emacs kommt aber nur `Alt+M` an. Wäre also möglich, dass entweder Emacs beim manuellen Basteln Mod3 natürlich nicht kennt und nur das M erzeugt, oder dass Windows nur ein M (mit Alt) meldet. (Mir kommt gerade die Idee, dass Alt+Mod3 wiederum eine neue Modifier-Kombination ist, die aber nicht im Treiber gesetzt wird. Hier _könnte_ man mit experimentieren, aber das ist aus folgendem Grund nicht nötig.) ### ReNeo Interessant wird es mit ReNeo als Ergänzung, da klappt das nämlich wieder. ReNeo blockiert die Mod3-Taste, sie wird also nicht ans Programm weitergeleitet. Stattdessen wird direkt ein Prozentzeichen (als Unicode) übermittelt: 1. VK_LMenu down 2. VK_PACKET (Unicode) down mit Scancode = Unicode von `%` Bei Emacs kommt dann in jedem Fall ein Prozentzeichen mit Alt-Status an. Genau das, was man haben will, und es wird korrekt interpretiert. Habe das jetzt mit MS Office (mangels Verfügbarkeit) nicht getestet, aber ich gehe vom gleichen Verhalten aus. ## Lösung Bei empfohlener Verwendung von ReNeo als Ergänzung zu kbdneo – allein schon um eine vollständige Ebene4 und den Capslock zu bekommen – tritt dieses Problem nicht mehr auf. Schlaue Programme, die mit Tastenkombinationen arbeiten, sollten Eingaben damit korrekt interpretieren können, jedenfalls geht es nicht besser auf Treiberseite. Höchstens durch eine Art Kompatibilitätsmodus, so dass wieder dieselben Tasten wie bei Qwertz gesendet würden. Aber das klappt ja schon bei manchen Programmen und AltGr-basierten Zeichen wie `{` oder `\` nicht so richtig. ReNeo unterstützt diesen Modus auch nicht (bei Mod3).