Welche der vielen Keymaps in diesem Repository ist autoritativ? #571

New Issue

Isopod · 2021-01-28T17:43:00+01:00

Isopod commented

2021-01-28 17:43:00 +01:00

Es gibt ja recht viele Keymaps und Treiber in diesem Repository, für verschiedene Betriebssysteme und so weiter. Die meisten davon (alle?) scheinen hardgecodet zu sein. Das heißt, es gibt sehr viel Duplikation.

Daher folgende Fragen:

Welche dieser Keymaps ist am vollständigsten? Auf welche sollte man sich berufen? Wenn man z.B. ein Skript schreiben will.
Gibt es irgendwelche Bestrebungen, den Prozess zu automatisieren?

Ich denke, es wäre sinnvoll, wenn es eine einzige, verbindliche Definiton von Neo gäbe und alle Keymaps, Treiber und so weiter automatisch per Skript daraus generiert würden. So müsste man nur eine Datei ändern und alle anderen wären automatisch auf dem neuesten Stand. Derzeit ist manches wohl veraltet (siehe auch #567) und ich habe den Eindruck, dass niemand wirklich einen Überblick hat, was noch aktuell ist und was nicht. Zumindest ich als Außenstehender finde das schwer zu überblicken.

Es gibt ja recht viele Keymaps und Treiber in diesem Repository, für verschiedene Betriebssysteme und so weiter. Die meisten davon (alle?) scheinen hardgecodet zu sein. Das heißt, es gibt sehr viel Duplikation. Daher folgende Fragen: * Welche dieser Keymaps ist am vollständigsten? Auf welche sollte man sich berufen? Wenn man z.B. ein Skript schreiben will. * Gibt es irgendwelche Bestrebungen, den Prozess zu automatisieren? Ich denke, es wäre sinnvoll, wenn es eine einzige, verbindliche Definiton von Neo gäbe und alle Keymaps, Treiber und so weiter automatisch per Skript daraus generiert würden. So müsste man nur eine Datei ändern und alle anderen wären automatisch auf dem neuesten Stand. Derzeit ist manches wohl veraltet (siehe auch #567) und ich habe den Eindruck, dass niemand wirklich einen Überblick hat, was noch aktuell ist und was nicht. Zumindest ich als Außenstehender finde das schwer zu überblicken.

hrnz commented

2021-01-28 22:19:53 +01:00

Autoritativ ist die Referenz. Ursprünglich wurde diese mal aus einer xmodmap generiert. Soweit ich das sehen kann, deckt die Referenz sich vollständig mit der hochgeströmten xkbmap. Als Referenz für Compose-Sequenzen dienen die Compose-Dateien in https://git.neo-layout.org/neo/neo-layout/src/branch/master/Compose .

Wir haben derzeit kein Tooling, um automatisch Treiber aus der Referenz zu generieren und es arbeitet auch niemand dran.

Ich stimme zu, dass im Repo sehr viel alter Legacy-Müll ist, dem eine größere Aufräumaktion vielleicht ganz gut tun würde.

Autoritativ ist die [Referenz](https://git.neo-layout.org/neo/neo-layout/src/branch/master/A-REFERENZ-A/neo20.txt). Ursprünglich wurde diese mal aus einer xmodmap generiert. Soweit ich das sehen kann, deckt die Referenz sich vollständig mit der hochgeströmten [xkbmap](https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/master/symbols/de#L384). Als Referenz für Compose-Sequenzen dienen die Compose-Dateien in https://git.neo-layout.org/neo/neo-layout/src/branch/master/Compose . Wir haben derzeit kein Tooling, um automatisch Treiber aus der Referenz zu generieren und es arbeitet auch niemand dran. Ich stimme zu, dass im Repo sehr viel alter Legacy-Müll ist, dem eine größere Aufräumaktion vielleicht ganz gut tun würde.

Isopod commented

2021-01-28 23:19:45 +01:00

Autoritativ ist die Referenz.

Das ist leider nicht wirklich maschinenlesbar.

Oder vielleicht doch. Habe hier noch was gefunden: https://git.neo-layout.org/neo/neo-layout/src/branch/master/yaml/parse_neo.py

Scheint zu funktionieren, gibt aber leider ausgerechnet Yaml aus, was auch nicht super zu parsen ist. Aber das könnte man wohl relativ leicht ändern.

Ich frage mich aber, ob die andere Richtung nicht mehr Sinn machen würde.

Als Referenz für Compose-Sequenzen dienen die Compose-Dateien in https://git.neo-layout.org/neo/neo-layout/src/branch/master/Compose .

Damit kann man arbeiten.

Wir haben derzeit kein Tooling, um automatisch Treiber aus der Referenz zu generieren und es arbeitet auch niemand dran.

Gäbe es denn grundsätzlich Interesse daran?

Ich stimme zu, dass im Repo sehr viel alter Legacy-Müll ist, dem eine größere Aufräumaktion vielleicht ganz gut tun würde.

Da fallen mir auch ein paar Sachen ein:

Der Ordner Artikel ist 10 Jahre alt und enthält nur eine einzige Platzhalterdatei.
linux/X enthält noch Dateien für Neo 1.0. Benutzt das noch jemand? Wer es unbedingt braucht, kann ja mit Git eine Zeitreise machen.
Gleiches gilt für windows/Neo1.1
Was ist mit diesen Installer-Binaries hier?
Wofür ist das?
Braucht man diese Skripte hier wirklich? Ich verwende Neo seit 2013 auf Linux und habe die noch nie vermisst.

> Autoritativ ist die [Referenz](https://git.neo-layout.org/neo/neo-layout/src/branch/master/A-REFERENZ-A/neo20.txt). Das ist leider nicht wirklich maschinenlesbar. --- Oder vielleicht doch. Habe hier noch was gefunden: https://git.neo-layout.org/neo/neo-layout/src/branch/master/yaml/parse_neo.py Scheint zu funktionieren, gibt aber leider ausgerechnet Yaml aus, was auch nicht super zu parsen ist. Aber das könnte man wohl relativ leicht ändern. Ich frage mich aber, ob die andere Richtung nicht mehr Sinn machen würde. --- > Als Referenz für Compose-Sequenzen dienen die Compose-Dateien in https://git.neo-layout.org/neo/neo-layout/src/branch/master/Compose . Damit kann man arbeiten. > Wir haben derzeit kein Tooling, um automatisch Treiber aus der Referenz zu generieren und es arbeitet auch niemand dran. Gäbe es denn grundsätzlich Interesse daran? > Ich stimme zu, dass im Repo sehr viel alter Legacy-Müll ist, dem eine größere Aufräumaktion vielleicht ganz gut tun würde. Da fallen mir auch ein paar Sachen ein: * Der Ordner [Artikel](https://git.neo-layout.org/neo/neo-layout/src/branch/master/artikel) ist 10 Jahre alt und enthält nur eine einzige Platzhalterdatei. * [linux/X](https://git.neo-layout.org/neo/neo-layout/src/branch/master/linux/X) enthält noch Dateien für Neo 1.0. Benutzt das noch jemand? Wer es unbedingt braucht, kann ja mit Git eine Zeitreise machen. * Gleiches gilt für [windows/Neo1.1](https://git.neo-layout.org/neo/neo-layout/src/branch/master/windows/Neo1.1) * Was ist mit diesen [Installer-Binaries hier](https://git.neo-layout.org/neo/neo-layout/src/branch/master/windows)? * Wofür ist [das](https://git.neo-layout.org/neo/neo-layout/src/branch/master/linux/etc/)? * Braucht man diese [Skripte](https://git.neo-layout.org/neo/neo-layout/src/branch/master/linux/bin) hier wirklich? Ich verwende Neo seit 2013 auf Linux und habe die noch nie vermisst.

qwertfisch commented

2021-01-29 01:38:06 +01:00

Die Referenz soll vermutlich auch nicht dafür gedacht sein, maschinenlesbar zu sein, sondern menschenlesbar. Sei es um mal ein Zeichen/Akzent nachzuschlagen oder eines zu suchen. Dafür ist sie vernünftig strukturiert.

Die oben verlinkte xkbmap kann hier eher den maschinenlesbaren Part übernehmen. Zumindest ist es ein gebräuchliches Format. Sollten wir dagegen für ein eventuelles Tooling zur Treibergenerierung ein bestimmtes/anderes Format haben wollen (z.B. JSON), lässt sich dann sicherlich ein Konvertierungsskript bauen, oder wir definieren uns ein eigenes und füllen das manuell, um dieses dann in weiteren Skripts (hast Du da Ideen?) zu verwenden.
Das YAML-Skript sieht mir ein bisschen unverständlich aus, und wie du sagst, YAML ist selbst wiederum etwas schlecht zu parsen. Heutzutage wäre wohl eher JSON (als YAML-Untermenge) das Format der Wahl und hat sich für Datensammlungen durchgesetzt.

Tooling

Die Referenz wird eigentlich nicht mehr angefasst, d.h. Treiber sind abgeschlossen, bis auf Bugfixes. Ich sehe wenig Sinn, da besonders viel Aufwand hineinzustecken in eine Sache, die manuell sehr selten angewendet wird.

Für kbdneo habe ich vor einigen Monaten ein Buildskript generiert, um die Generierung an Windows 10 anzupassen und die verschiedenen Varianten (Neo, Neoqwertz, Bone) unter einen Hut zu bringen. Dieses wird zwar manuell ausgeführt, ist aber nachvollziehbar dokumentiert. Ich denke, darauf kommt es eher an. Wie in #567 zu sehen ist, sind dort die Compose-Kombinationen ein Problem, weil nicht dokumentiert ist, wie diese (und welche) erstmalig zu C-Code generiert wurden und es nicht ohne Weiteres (manuell) reproduzierbar ist.
Ähnliches gilt für NeoVars, während die Linuxtreiber die systemeigenen Compose-Dateien verwenden können. (Für Mac weiß ich’s gerade nicht.)

Also ich finde nicht, dass wir automatisches Bauen und Deployen benötigen – aber dokumentierte und nachvollziehbare Buildschritte.

Aufräumen / weitere Sachen

Das sind gute Punkte. Magst Du die (gemeinsam) in ein eigenes Issue verschieben? Das passt thematisch jetzt nicht direkt zu „Welche Keymap ist die richtige“. Im anderen Issue können wir die dann der Reihe nach angehen und abhaken.

Die Referenz soll vermutlich auch nicht dafür gedacht sein, maschinenlesbar zu sein, sondern menschenlesbar. Sei es um mal ein Zeichen/Akzent nachzuschlagen oder eines zu suchen. Dafür ist sie vernünftig strukturiert. Die oben verlinkte xkbmap kann hier eher den maschinenlesbaren Part übernehmen. Zumindest ist es ein gebräuchliches Format. Sollten wir dagegen für ein eventuelles Tooling zur Treibergenerierung ein bestimmtes/anderes Format haben wollen (z.B. JSON), lässt sich dann sicherlich ein Konvertierungsskript bauen, oder wir definieren uns ein eigenes und füllen das manuell, um dieses dann in weiteren Skripts (hast Du da Ideen?) zu verwenden. Das YAML-Skript sieht mir ein bisschen unverständlich aus, und wie du sagst, YAML ist selbst wiederum etwas schlecht zu parsen. Heutzutage wäre wohl eher JSON (als YAML-Untermenge) das Format der Wahl und hat sich für Datensammlungen durchgesetzt. ### Tooling Die Referenz wird eigentlich nicht mehr angefasst, d.h. Treiber sind abgeschlossen, bis auf Bugfixes. Ich sehe wenig Sinn, da besonders viel Aufwand hineinzustecken in eine Sache, die manuell sehr selten angewendet wird. Für kbdneo habe ich vor einigen Monaten ein Buildskript generiert, um die Generierung an Windows 10 anzupassen und die verschiedenen Varianten (Neo, Neoqwertz, Bone) unter einen Hut zu bringen. Dieses wird zwar manuell ausgeführt, ist aber nachvollziehbar dokumentiert. Ich denke, darauf kommt es eher an. Wie in #567 zu sehen ist, sind dort die Compose-Kombinationen ein Problem, weil nicht dokumentiert ist, wie diese (und welche) erstmalig zu C-Code generiert wurden und es nicht ohne Weiteres (manuell) reproduzierbar ist. Ähnliches gilt für NeoVars, während die Linuxtreiber die systemeigenen Compose-Dateien verwenden können. (Für Mac weiß ich’s gerade nicht.) Also ich finde nicht, dass wir automatisches Bauen und Deployen benötigen – aber dokumentierte und nachvollziehbare Buildschritte. ### Aufräumen / weitere Sachen Das sind gute Punkte. Magst Du die (gemeinsam) in ein eigenes Issue verschieben? Das passt thematisch jetzt nicht direkt zu „Welche Keymap ist die richtige“. Im anderen Issue können wir die dann der Reihe nach angehen und abhaken.

qwertfisch commented

2021-03-30 21:49:18 +02:00

Ich fasse mal den Stand für die angefragten Punkte zusammen:

Die Referenz ist eine vollständige (menschenlesbare) Beschreibung des Tastaturlayouts inklusive aller direkt erzeugbaren Zeichen. Kombinationen über Tottasten und Compose sind nicht beschrieben und hängen (in aller Regel) auch nicht direkt am Layout, sondern lassen sich ergänzend definieren und nach eigenen Wünschen einstellen.
Eine maschinenlesbare / strukturierte Form der sechs Ebenen existiert in dem Sinne nicht. Wenn diese als JSON oder ähnlich benötigt wird, sollte ein neues Issue dazu erstellt werden.
Eine Automatisierung der Erstellung von Keymaps ist nicht (mehr) notwendig, da die Referenz seit 2010 feststeht. Entsprechend sind die Maps in xkeyboard, NeoVars, kbdneo usw. bereits abgeschlossen und ändern sich nicht – außer man findet noch Bugs.

Compose

Die Compose-Sequenzen wurden letztens neu geordnet. Sie unterliegen einem einfachen textuellen Format (von Mensch wie Computer lesbar) und können als XCompose direkt unter Linux, aber auch z.B. in ReNeo direkt verwendet werden.
Unklar ist noch, welche Compose-Sequenzen in kbdneo enthalten sind. Dies sollte mittelfristig aber durch ReNeo obsolet sein. In jedem Fall ist #567 der passende Ort zur Diskussion.

Aufräumen

Ein paar Dinge wurden in #576 aufgeräumt. Die legacy-Tools wie Neo1.1 könnten zwar weg, andererseits stören sie auch nicht weiter. Wenn mehr Klärungsbedarf besteht, bitte ein entsprechendes Issue erstellen.

Ich fasse mal den Stand für die angefragten Punkte zusammen: - Die [Referenz](https://git.neo-layout.org/neo/neo-layout/src/branch/master/A-REFERENZ-A/neo20.txt) ist eine vollständige (menschenlesbare) Beschreibung des Tastaturlayouts inklusive aller direkt erzeugbaren Zeichen. Kombinationen über Tottasten und Compose sind nicht beschrieben und hängen (in aller Regel) auch nicht direkt am Layout, sondern lassen sich ergänzend definieren und nach eigenen Wünschen einstellen. - Eine maschinenlesbare / strukturierte Form der sechs Ebenen existiert in dem Sinne nicht. Wenn diese als JSON oder ähnlich benötigt wird, sollte ein neues Issue dazu erstellt werden. - Eine Automatisierung der Erstellung von Keymaps ist nicht (mehr) notwendig, da die Referenz seit 2010 feststeht. Entsprechend sind die Maps in xkeyboard, NeoVars, kbdneo usw. bereits abgeschlossen und ändern sich nicht – außer man findet noch Bugs. ### Compose - Die [Compose-Sequenzen](https://git.neo-layout.org/neo/neo-layout/src/branch/master/Compose) wurden letztens neu geordnet. Sie unterliegen einem einfachen textuellen Format (von Mensch wie Computer lesbar) und können als XCompose direkt unter Linux, aber auch z.B. in [ReNeo](https://neo-layout.org/Benutzerhandbuch/Installation/#windows) direkt verwendet werden. - Unklar ist noch, welche Compose-Sequenzen in kbdneo enthalten sind. Dies sollte mittelfristig aber durch ReNeo obsolet sein. In jedem Fall ist #567 der passende Ort zur Diskussion. ### Aufräumen Ein paar Dinge wurden in #576 aufgeräumt. Die legacy-Tools wie Neo1.1 könnten zwar weg, andererseits stören sie auch nicht weiter. Wenn mehr Klärungsbedarf besteht, bitte ein entsprechendes Issue erstellen.

qwertfisch closed this issue

2021-03-30 21:49:18 +02:00

Sign in to join this conversation.

No Milestone

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: neo/neo-layout#571