#178: [xkbmap] Tastenkombinationen mit 4./7. Ebene bei KDE-Programmen
-------------------------------------+--------------------------------------
Reporter: martin_r | Owner:
Type: Fehler/Defekt | Status: new
Priority: hoch | Milestone: Neo Version 2.0
Component: Treiber: Linux – Xkbmap | Version: 2.0 BETA
Keywords: |
-------------------------------------+--------------------------------------
Comment(by anonymous):
OK. Ich habe die Ursache isoliert:
Qt kennt eine Methode namens „possibleKeys“. Sie ermittelt, welche
verschiedenen Bedeutungen eine Tastenkombination haben kann. So kann
Strg+Shift+i auch Strg+(Groß-I) bedeuten. Und man könnte per Xkbmap Strg+i
auch auf, sagen wir mal, iota ummappen, dann könnte Strg+Shift+i auch
Shift+iota bedeuten. Der Punkt ist, dass Qt es nicht wissen kann und
deswegen erstmal alle diese Kombinationen untersucht. Das ist eigentlich
auch vernünftig; im Prinzip ist es ein Designfehler von X, das
Tastenkombinations-Modifier (Strg, Alt, Meta…) und Modifier, die
Tastenbedeutungen verändern (Shift, Lock, ISO_Level3_Shift, …) nicht
trennt. Andererseits gibt es genau dafür auch wieder gute Gründe (so
müssten sonst für Shift+PfeilLinks etc. eigene Keysyms definiert werden,
unschön).
Im unserem Falle Strg+Mod4+i ergeben sich Strg+Left und Strg+i als
Möglichkeiten. Denn Qt kennt Mod4 (intern: ISO_Level5_Shift) nicht und
ignoriert es. Dass diese beiden Tastenkombinationen belegt sind und Qt
nicht entscheiden kann, welche gemeint ist, wird das entsprechend
angezeigt: In QShortcutEvent wird ein Feld „ambiguous“ gesetzt. KDE
registriert dies und gibt die Fehlermeldung aus.
Im anderen Fall, Shift+Mod4+u, können U, Shift+u, Home (die überflüssige
Eintragung in der Pseudoebene) und Shift+Home gemeint sein. Von diesen
sind Home und Shift+Home belegt ⇒ uneindeutig ⇒ Fehlermeldung. Wenigstens
diesen Fall können wir beheben.
KDE achtet auch explizit darauf, dass Tastenkombinationen z.B. nur als
Shift+I, nicht aber Strg+Shift+i eingetragen werden. Da es aber von Mod4
nichtmal was mitbekommt (Qt übergibt als Qt-keysym nur -1, da es die Taste
nicht kennt), kann es das bei Mod4 nicht machen und meldet sich auch bei
dem Versuch, eine Tastenkombination mit Mod4 einzutragen. Ob diese
Fehlermeldung ein Bug ist, kann man sich streiten. Würde -1 einfach
ignoriert, könnten wir mit Mod4 auch Tastenkombinationen definieren,
sofern die Taste auf der 4. Ebene belegt ist.
Der eigentliche Bug steckt in Qt, das ISO_Level5_Shift a)überhaupt gar
nicht kennt und b) nicht als Modifier erkennt.
Lösungsmöglichkeiten?
• Der Bug mit den Shift-Kombis kann wie beschrieben behoben werden, indem
in der Pseudoebene „NoSymbol“ eingetragen wird, statt die 4. Ebene zu
wiederholen. Ich sehe nicht, dass das Probleme ergeben würde; die
Pseudoebene ist schließlich genau für diese Funktionen frei gelassen.
• Für die Strg-Kombis (und auch eventuelle Alt-, Win-, Strg-Alt- usw.
-Kombis) gibt es keine einfache Lösung. Für uns am bequemsten wäre, Qt
würde den Bug beheben. Das wäre aber schon eine eher große Umstellung: Für
die internen Modifier ist nur noch ein einziges Bit frei, und da werden
sie lange nachdenken, ehe sie das belegen.
• Wir könnten statt ISO_Level5_Shift Meta oder Hyper o.ä. benutzen, das Qt
kennt und als Modifier akzeptiert. So eine Lösung hätte aber unzählige
Nachteile: Die Windows-Tasten wären im Gegenzug keine Modifier mehr, und
wir wären auch sehr inkompatibel mit anderen xkb-Treibern. Inakzeptabel.
• Wir könnten mit Redirect-Actions arbeiten. Irgendwer meinte aber, dass
das leider nicht so richtig funktioniert, jedenfalls nicht bei älteren
X-Servern.
• In Neo 3 könnte man einen Mod als „Overlay“ deklarieren; das ist eine
Fn-ähnliche Funktion, die die Tasten in einer gesamten Ebene auf andere
ummappt. Das würde allerdings große Änderungen an der Struktur von Neo
bedeuten
--
Ticket URL: <http://wiki.neo-layout.org/ticket/178#comment:3>
Neo-Layout <http://neo-layout.org/>
Das Neo-Tastaturlayout ist ein freies und ergonomisch optimiertes
Tastaturlayout für die deutsche Sprache, das auch sehr viele Sonderzeichen
direkt verfügbar macht.
