diff options
| -rw-r--r-- | windows/neo-vars/Readme.txt | 151 |
1 files changed, 151 insertions, 0 deletions
diff --git a/windows/neo-vars/Readme.txt b/windows/neo-vars/Readme.txt new file mode 100644 index 0000000..bfc0b3b --- /dev/null +++ b/windows/neo-vars/Readme.txt @@ -0,0 +1,151 @@ +NEO-vars +======== + +NEO-vars ist die nunmehr zweite Implementierung des NEO-Tastaturlayouts +in der Programmiersprache AutoHotKey (auch AHK), www.autohotkey.com. +Statt mit langen if-then-else-Bäumen auf getrennten Key-Hooks +arbeitet neo-vars mit einem globalen, für (fast) alle Tasten +durchlaufenen Key-Hook (keyhooks.ahk), der nicht nur für key-press +sondern auch für key-release (up) verwendet wird. + +Der Key-Hook durchläuft die Funktion AllStar (varsfunctions.ahk), in +der der Name der gedrückten Taste (PhysKey, dann ActKey) um die +aktuelle Ebenennummer erweitert wird und das Ergebnis als Variable +abgefragt wird. Diese Variable (gespeichert in char) sagt nun, was +sich hinter dem Tastendruck für ein Zeichen (z.B. „U0041“ für ein +großes A) oder auch Sonderzeichen (z.B. „SComp“ für Compose), oder +auch Unterprogrammaufruf (z.B. „P_EHt“ für das Umschalten des +Einhand-Modus) verbirgt. Dieser „Lookup“, den man in „besseren“ +Programmiersprachen mit assoziativen Hash-Arrays implementiert, wird +in AHK über dynamische Variablenabfragen gemacht, wobei diese Variablen +vorher definiert wurden. + +Variablen werden aber nicht nur für die Zuweisung Ebene+Taste=Zeichen +(keydefinitions.ahk) verwendet, sondern auch für Shortcuts +(shortcuts.ahk), die später dazu dienen, aus abstrakten Zeichen +wieder von Programmen verwendbare Tastendrücke zu machen: Aus +„SHome“ wird beispielsweise über »send« wieder „{Home down}“ für den +Tastendruck und „{Home up}“ für das Loslassen. Auch für Buchstaben +und Sonderzeichen wird diese Methode verwendet, um größtmögliche +Kompatibilität mit normalen Programmen zu gewährleisten. Alles, +wofür es keine Shortcuts gibt, wird als unicode-Zeichen an die +Applikation geschickt. Ein paar wenige Zeichen können nicht oder nur +schwer durch getrennte Down-Up-Sequenzen umgesetzt werden; an diesen +Stellen wird auf den getrennten Key-Release verzichtet und das +Zeichen bzw. eine dafür notwendige Zeichenfolge über das gute alte +»send« geschickt. + +Zweiter wichtiger und auch für den Benutzer spürbarer Unterschied +zum alten AHK-Skript ist die Unterstützung von Key-Press und +-Release (down- und up-events), wodurch z.B. manche Programme erst +benützbar werden wie z.B. Spiele, die die Dauer messen, für die eine +Taste niedergedrückt ist. Dafür muss sich das Skript aber für jede +Taste merken, was es bei einem späteren Release für ein Zeichen +schicken muss, damit keine Taste „hängen“ bleibt. Auch diese +Informationen werden in Variablen gespeichert, deren Namen mit dem +Scancode/Virtualcode der Taste zusammenhängen. + +Ähnlich werden Compose-Sequenzen unterstützt: Ist eine Variable +definiert, die darauf hinweist, dass die bisherige Sequenz ein +Compositum ist, wird dieses dargestellt. Ist eine andere Variable +definiert, die sagt, dass bis zu einem fertigen Compositum noch mehr +Zeichen kommen können, wird das aktuelle Zeichen nicht ausgegeben +und stattdessen dem Compositum angehängt. Die dafür nötigen +Variablen werden von einem Extra-Skript aus den definierten +Compose-Sequenzen erstellt und als AHK-Code abgespeichert +(compose.generated.ahk). Hier ist von Vorteil, dass AHK fast beliebig +lange Variablennamen unterstützt. + +Mit der Verwendung von Unterprogrammen, sowohl beim Drücken von +Tasten, als auch bei Composita, eröffnen sich interessante +Möglichkeiten, die z.T. noch garnicht ausgeschöpft sind. Ein paar +Schmankerln sind aber jetzt schon eingebaut, wofür aber z.T. +auch Hooks bemüht werden müssen. + +Erst diese Key-Hooks an mehreren Stellen machen Spezial-Modi +möglich: Es gibt einen Physical-Key-Hook, der z.B. für die +Implementierung des einhand-Neo verwendet wird (einhandneo.ahk). Er +kann unter entsprechenden Nebenbedingungen, wie hier dem +Gedrückthalten der Space-Taste, Tastencodes austauschen. Ein weiterer +Key-Hook ermöglicht das Abfangen sämtlicher Tastendrücke für z.B. +einen Römische-Zahlen-Modus (tools.ahk), um den gewohnten Ablauf zu +ändern, um also hier die gedrückten Ziffern als Dezimalzahl zu +interpretieren und in die für sie nötigen römischen +Zahlen-Buchstaben umzuwandeln. Ähnlich funktioniert auch der +generische Unicode-Zeichengenerator über ♫uu. + +Eine weitere Stelle für Hooks ist die Ausgabefunktion, die derzeit +für das Decodieren von Unicode-Zeichen verwendet wird: ♫dd und dann +ein Zeichen eingeben, das auch über ein Compositum entstanden sein +kann, und ein kleiner ToolTip gibt den entsprechenden +Unicode-Codepoint aus (tools.ahk). + +Die Bildschirmtastatur (M3+F1) reagiert nunmehr dynamisch auf die +verschiedenen aktivierten Ebenen, d.h. mit dem Drücken eines +Modifiers wird automatisch die entsprechende Ebene angezeigt, ohne +dass man diese manuell wählen müsste. Im CapsLock-Modus funktioniert +das noch nicht richtig, da sich dort Buchstaben und Sonderzeichen +unterschiedlich verhalten und wir dafür noch zwei zusätzliche PNG- +Dateien brauchen. Abgesehen davon gibt es Überlegungen, die +Bildschirmtastatur komplett dynamisch zu machen, das heißt, dass man +auch die zu erwartenden Compose-Sequenzen sehen kann. Wenn man also +das tote Hochkomma ́ tippt, würde die Bildschirmtastatur für die +solcherart unterstützten Tasten die Buchstaben mit Apostroph +darstellen. Ob das aber so einfach geht, ist nicht ganz klar: +Erstens muss die Ausgabe ausreichend gut ausschauen, zweitens muss +die Existenz eines dafür ausgelegten Unicode-Fonts sichergestellt +sein, und schließlich muss man die entsprechenden Windows-Funktionen +umständlich über DLL-Calls aufrufen, um die AHK-Beschränkung auf die +System-Codepage zu überwinden. Ob diese Funktion dann auch die +benötigte Performance hat, müsste sich erst weisen. + +Das AHK-Skript (leider nicht das EXE) bindet jetzt eine eventuell +bestehende individuelle Datei aus dem NEO2-Applikationsverzeichnis +ein (custom.ahk). Überhaupt sind die Spezialmodi wie EinHand-Neo, +Lernmodus und Lang-s-Tastatur in eigene „Module“ ausgelagert worden, +die den restlichen Code überhaupt nicht mehr tangieren. Das bedeutet +einerseits, dass man sie einfacher warten kann, andererseits auch, +dass sie durch diese leicht zu durchschauende Kapselung als Vorlage +für individuelle Erweiterungen zur Verfügung stehen. So wäre +denkbar, dass man auch die normale Belegung in ein Modul packt, das +dann recht einfach und unabhängig vom restlichen Code gewartet +werden kann. Auch die etwas eingeschlafene Diskussion über die +Tastenbelegung von NEO3 kann über diesen übersichtlichen Mechanismus +schnell wieder aufgenommen werden. + +Auf kurze Sicht steht eine automatische Tasten-Layout-Generierung +auf dem Plan, mit der man über einen Klick die aktuelle +Tastenbelegung aus der Referenz erzeugen kann. Zuvor sollte ein +vernünftiges Dateiformat für die Referenz gefunden werden, dann kann +mit der Erstellung des Konverters begonnen werden. + +Last, but not least gehört für die vielen Konfigurationsoptionen ein +entsprechender Dialog her. Der Kapselung wegen könnten die einzelnen +Module hier separate Dialogboxen oder Tabs erhalten. + +Übrigens stellt neo-vars seine Informationen (z.B. über die +Aktivierung des Mod4-Lock) über Tray-Tips dar, die mitunter im +Explorer oder über die Registry aktiviert werden müssen. Diese +Einstellung zu ändern, wäre auch ein heißer Kandidat für die +Config-Dialoge. + +Nur ein kleiner Teil des Codes wurde vom alten Neo-AHK übernommen, +darunter die kaum benutzten Keyboard-LEDs und die stark angepassten +Unicode-Zeichenausgaben und Ebenenfunktionen. Mittlerweile werden +sogar die Modifier über die normalen Keyboard-Hooks geleitet, +wodurch man im Prinzip auch diese Zeichen generisch umlegen kann. +Einen Strich durch die Rechnung macht uns AHK mit einer recht +unflexiblen Handhabung der Alt-Taste, die zwar ge-hookt aber nicht +so einfach gesendet werden kann (AHK sendet bona fide automatisch +Key-release-Events und simuliert Strg-Tastendrücke). Strg, Win und +Konsorten wären hingegen kein Problem. + +Wir hatten recht lang ein generelles Performance-Problem, das zur +Folge hatte, dass hie und da ein Zeichen nicht vom AHK-Skript +verarbeitet wurde und stattdessen direkt zur Applikation weiter +gereicht wurde. Dieses Problem ist offenbar auf AHK und dessen +Funktion SendInput in seiner derzeitigen Version zurückzuführen. Mit +SendEvent (bzw. »SendMode Event« am Beginn des Skripts) haben wir +aber keine Probleme mehr, weshalb neo-vars nun auch die offizielle +AHK-Version ist. + |