Guten Abend, werte Leute! Der eine oder andere erinnert sich vielleicht noch an neo_yaml. (Warum heißt das eigentlich so?)
Zum baldigen Start von Neo 3 – auch wenn ich davon nicht so viel halte – sollte so langsam auch eine automatisierte Erstellung der Treiber aus der Referenz stehen. Zur Zeit bin ich hin und weg von awk und damals hieß es, dass das Fortführen von yalm nicht unbedingt an Python gebunden ist und gerne von vorne begonnen werden darf. awk ist nicht so gut bzw. umfangreich wie Python oder Perl, eignet sich aber für unsere Zwecke hervorragend. Es sollte für alle gängigen Betriebssysteme verfügbar sein. Einige der nachfolgenden Hinweise und Befehle gelten aber nur für Linux. Alle relevanten Dateien sind angefügt und ich würde erstmal gerne von euch wissen, was ihr so davon haltet. Betrachtet bitte die neo_de.xmodmap: Sie ist bei der Ziffernreihe modifiziert, sodass sie dort mehr oder weniger layoutunabhängig ist. (Die ganze Datei wollte ich noch nicht „portieren“, es geht erstmal nur ums Testen.) Statt dem Befehl onesuperior befindet sich dort zum Beispiel lnxkcd10_3 – damit ist die 3. Ebene des Linux-Keycode 10 gemeint. Und so zieht sich das durch den ganzen Abschnitt, es könnte auch auf die ganze Datei und auch auf andere Dateien wie das ahk-Skript oder gar das Tastaturlayout als svg-Datei ausgeweitet werden. awk läuft nun durch diese Datei und ersetzt diese Schlüsselwörter durch die korrekten Einträge. Probiert’s aus: awk -f transform layout systemcodes neo_de.xmodmap > ausgabe Die entstandene Datei entspricht nun der originalen, die auf der Neo-Website zu finden ist: diff -s ausgabe neo_de.xmodmap.orig Die wichtigen zwei Hilfsdateien sind layout und systemcodes. In layout stehen die ganzen „Keycodes“ (habe ich willkürlich gewählt – sie repräsentieren einfach nur die Tasten) und dahinter die sechs Zeichen der sechs Ebenen. systemcodes enthält alle per Neo darstellbaren Zeichen und dahinter jeweils das Kommando, das der Treiber benötigt. Zum Beispiel braucht die xmodmap für » das Kommando guillemotright. Im Moment ist dort auch nur die xmodmap berücksichtigt, das kann aber sehr leicht erweitert werden. Natürlich kann diese Automatisierung nicht alles berücksichtigen. Die Position der Modifier etwa müssen in den „layoutunabhängigen“ Treiberdateien dann doch manuell verändert werden. Außerdem gibt es hier und da noch Probleme: Mit der Pseudoebene wusste ich im Moment noch nicht so viel anzufangen, das kann man sicher noch eleganter lösen. Und auch schwer erkennbare oder nicht darstellbare Unicodezeichen habe ich provisorisch abgekürzt: Da man im Quelltext zum Beispiel deutschen und englischen Gedankenstrich nicht unterscheiden kann, hab ich als Kennung für emdash nicht — sondern m- gewählt; und für KP_Multiply, der eigentlich * entspricht, stattdessen k*. Der Gravis könnte ` und der tote Gravis einfach d` sein. usw. Sooo: Ist awk ok? Eine schöne Einführung findet ihr in der letzten Juniausgabe von freiesMagazin¹, ein etwas umfangreicheres Handbuch bei Wikipedia². Sind die keycodes in Ordnung? Die sind nämlich gar nicht so unveränderbar, ich würde mir hier etwas mehr Invarianz wünschen. Was wünscht ihr euch von der layout-Datei? Sie ist im Moment nicht so gut leserlich. Man könnte das verbessern, aber dann wäre das awk-Skript „transform“ nicht mehr so einfach gestaltet. Eine gut lesbare Referenz kann (und muss) man aber sowieso erstellen. Sonstige Verbesserungsvorschläge/Wünsche/Anmerkungen? Ich arbeite auch gerne an diesem Projekt weiter, aber erst, wenn ich weiß, dass das in keine falsche Richtung geht. tschau Frank [1] http://www.freiesmagazin.de/freiesMagazin-2009-06 [2] http://www.ostc.de/awk.pdf
yaml.tar.gz
Description: application/compressed-tar
