Hallo,
die grobe Idee eine deklarativen, intuitiven, mächtigen Beschreibungssprache
für Tastaturlayouts finde ich sehr ansprechend. Meine Beweggründe zu
Keymechs sind ja Funktionsmächtigkeit und – nachdem ich bemerkte, dass es
ohne gute Konfiguration nicht geht – eben gerade eine intuitive Sprache.
1. Die Sprache beschreibt möglichst einfach den kompletten Funktionsumfang
von NEO.
Für Neo existiert bereits Reneo, und man kann damit Neo-artige Layouts
erstellen/anwenden (sogar annehmbar einfach). Mehr geht aber leider nicht:
der Nutzer ist nicht völlig frei in der Konfiguration, noch kann alles
beliebig reduziert, geändert oder erweitert werden. Und einige
Verhaltensweisen sind halt gar nicht möglich (oder fest einkodiert). Die
angedachte Sprache soll aber funktionsmächtig und unabhängig sein.
2. Da die Beschreibung komplett ist, kann nun für verschiedene Zielsystem
(Karabiner Elements, ReNeo, Keymechs, kanata, ...) eine Konvertierung
erfolgen.
Keymechs ist das kanonische Mapping-Tool explizit für diese Sprache. Andere
Mapping-Tools können einige Features vielleicht unterstützen, vielleicht
nicht. ReNeo ist wie eben beschrieben eingeschränkt. Eine Konvertierung
bringt da nicht viel und ist unsinnig, weil die Funktionsweise am Ende exakt
dieselbe ist (mehr dazu weiter unten). Da kann man auch gleich Keymechs
nehmen. Ich würde soger behaupten, es macht mehr Sinn, ein kleines
Konvertierungstool zu haben, was andersherum alte Reneo-Konfigs in die neue
Sprache übersetzt.
Kanata, Keyd, Karabiner … das wäre denkbar, ja. Meinem Verständnis nach
können Kanata und Keyd ähnliches, vielleicht sogar den ganzen angedachten
Funktionsumfang. Hier sehe ich tatsächlich einen Punkt, dass man schauen
könnte, ob die Keymechs-Implementierung sinnvoll ist, oder ob man einen
Konverter von der Keymechs-Konfiguration nach bspw. Kanata baut. Letzteres
erscheint mir auch nicht allzu trivial: der ganze Punkt mit der Parsen der
Beschreibungssprache bliebe weiterhin notwendig. Ein Keymechs-Client müsste
neben dem Parsen gar nicht soviel mehr tun. Die Implementierung eines
Keymappers ist relativ einfach.
Ich würde liebend gerne überhaupt eine Karabiner Elements Konfiguration
haben, die fehlerfrei Neo auf macOS abbildet, ohne dass man da noch
Neo-Layouts oder dieses ABC-Layout installieren müsste und in sovielen
Programmen Bugs erlebt. Doch solange nichtmal das zu bewerkstelligen ist,
sehe ich denn Sinn hier noch weniger. Ein Keymechs für macOS wäre cool, aber
ich habe keinen Mac und kann daher keine Software dafür entwickeln oder mit
der System-API experimentieren. (Und wenn, würde ich damit erst anfangen
wollen, wenn eine Windows-Version besteht.)
3. Da die Sprache ja einfach und deklarativ ist, kann nun jeder Benutzer
seine persönlichen Anpassungen einfach am Ende der Konfiguration
hinzufügen,
und beim nächsten Konvertierungslauf (dynamisch?) ist die Änderung
aktiv.
„Wir definieren uns eine Sprache S. Sei S einfach und deklarativ …“ ;) Das
ist ja gerade das Schwierige an dieser Sache! Zum Konvertieren hab ich beim
zweiten Punkt schon entsprechendes geschrieben.
Nebenschauplatz: die Sprache sollte möglichst keine Struktur-Symbole der
Länge Eins, wie ( , ) " + ' ; ... enthalten um "Escaping" zu vermeiden
(Um Return und Space kommt man wohl nicht drum rum)
Du brauchst irgendwelche Symbole oder Wörter, um deine Grammatik zu
definieren. Das können auch Symbole der Länge 1 sein, solange im aktuellen
Kontext klar ist, ob nun Syntax gemeint ist oder ein String (für
auszugebende Zeichen). Ich stimme dir zu, dass man Escaping auf einen
möglichst kleinen Bereich reduzieren oder besser ganz vermeiden sollte. Ich
hab ein paar Ideen im Kopf, kann ich mal in einer anderen Mail vorbringen.
Mir ist bewusst, dass das auch ein bisschen was von xkcd/Standards hat (
https://xkcd.com/927/ ) – wobei es hier nicht wirklich um Standards geht.
Aber häufig ist das Konfigurationsformat auch nicht in Hinblick auf den
Nutzer und Intuition und Einfachheit ausgewählt, sondern nach
Implementierbarkeit. Also technische Gründe. Das halte ich für keine gute
Grundlage.
Bei der Aufzählung der äh „Zielsysteme“ fiel mir auf, dass es
unterschiedliche Ebenen gibt, auf denen so ein System wirkt. Ganz unten
haben wir mit QMK, ZMK, RMK Tastatur-Firmwares, die es ermöglichen, eine
physische Tastatur zu konfigurieren. Dabei wird festgelegt, welche
Tasten(drücke) zu welchen ausgegebenen Scancodes führen. Inklusive der
Möglichkeiten mit verschiedenen Ebenen, Locks, Multitaps, Sequenzen – das
regelt die Tastatur, um am Ende Scancodes rauszuhauen. Nur diese werden vom
jeweiligen Betriebssystem verarbeitet und anhand eines obligatorischen
Grundlayouts in die Zeichen und Nicht-Zeichen-Codes (Pfeiltasten, F-Tasten
usw.) umgesetzt.
Eine Konfiguration auf Firmware-Ebene muss notwendigerweise anders gestaltet
sein (mit einer anderen Zielsetzung) als eine Konfiguration auf der Ebene,
wo Karabiner, Keymechs oder Kanata angesetzt sind. Diese bekommen nämlich
die Scancodes (und sogar die bereits vom Betriebssystem umgesetzten
virtuellen Keycodes, ggf. die zu generierenden Zeichen). Um dann anhand
einer Konfiguration zu sehen, welche Ebene aktiv ist, welche Zeichen /
Nicht-Zeichen ausgegeben werden, ob Sequenzen (Compose) verarbeitet werden
und andere Dinge. Dabei wird die Arbeit des Betriebssystem-Layouts leider
teilweise wieder revidiert – aber die Betriebssysteme geben einem eben nicht
die ganze Funktionsmächtigkeit an die Hand.
Es ist nunmal so, Tastatur und Betriebssystem sind zwei Teile, die
zusammenspielen. Wenn man keine programmierbare Tastatur hat bleibt nur die
Software-Ebene übrig. Und für diese Ebene fehlt mir eben die mächtige und
erweiterbare Konfiguration (plus Mapping-Tool).
Es gäbe sogar noch eine dritte logische Ebene. Das sind dann Tools wie
keymapper oder AHK, die eher mehr … Shortcuts definieren, um damit z.B.
Programme zu starten, oder andere Tastenkombinationen ersetzen, Makros
ausführen usw. Sowas könnte man auch für Keymechs in Maßen auch mit
einbauen, aber würde ich erstmal auf (viel) später verschieben.
qwertfisch
_______________________________________________
Diskussion mailing list -- [email protected]
To unsubscribe send an email to [email protected]
