habe mal svn:eol-style auf native gesetzt. betrifft alle textdateien

(ich hoffe ich hab keine vergessen)


git-svn-id: https://svn.neo-layout.org@757 b9310e46-f624-0410-8ea1-cfbb3a30dc96

1 files changed, 53 insertions, 53 deletions

diff --git a/windows/autohotkey/CHANGES.txt b/windows/autohotkey/CHANGES.txt
index d1230fa..4123181 100644
--- a/windows/autohotkey/CHANGES.txt
+++ b/windows/autohotkey/CHANGES.txt
@@ -1,53 +1,53 @@
-== Neo 2.0 Autohotkey-Treiber für Windows ==

-

-== 2008-08-11 Matthias Wächter ==

-

-Ebene4-Ziffernblock: NumPadAdd und NumPadSub korrigiert

-

-

-== 2008-08-10 Matthias Wächter ==

-

-• Erstmal ist fast kein Stein auf dem anderen geblieben. Die grobe Struktur und das Verhalten (natürlich ist auch die Tastenbelegung 100% NEO!) sind grundsätzlich gleich geblieben, aber einerseits hat sich im Feinen viel getan (z.B. Tab-Behandlung), andererseits schauen viele Zeilen altbekannten Codes jetzt anders aus.

-

-• Beim »Booten« wird einmal EbeneAktualisieren() aufgerufen, um die Ebene sicher richtig zu haben. Dieses fragt jetzt auch den Zustand von NumLock ab, damit man es bei der NumPad-Behandlung gleich parat hat.

-

-• Die DeadKey- und CompKey-Behandlung ist zwar im Prinzip gleich geblieben, aber die Syntax habe ich wesentlich gestrafft. Die einzelnen Subs haben jetzt nur mehr den Job, DeadKey und CompKey zu setzen, wenn dieser nach Verlassen des Subs einen Wert haben soll.  EbeneAktualisieren() überträgt für eine einfachere Handhabung die beiden Variablen DeadKey und CompKey nach PriorDeadKey und PriorCompKey. Letztere können im Programm abgefragt werden, während die nicht-Prior-Varianten schamlos verändert werden dürfen. Das entfernt die immer gleichen (aber doch manchmal unterschiedlichen und nicht selten lückenhaften) Zeilen a la »CompKey := ""«.

-

-• Ich habe ganz dreist auf Scancodes mit Virtual Keys umgestellt. Schöner wäre es natürlich gewesen, wenn ich auf die VKs hätte verzichten können, aber das führt ja zu bekannten Problemen mit AHK-Bugs, sodass Scancode-Trigger plötzlich von SendUnicodeChar-Zeilen aktiviert werden. Durch das Abfragen der VKs sind wir aber immer noch nicht soweit, dass wir Layout-agnostisch arbeiten können.

-

-• Dabei gibt es noch ein paar wesentliche Änderungen im Bereich der Tastentrigger: Erstens gehen alle bekannten Scancodes für den NumPad auf paarweise gemeinsame Routinen. Das hält sie nicht nur konsistent, sondern ermöglicht erst eine konsequente Analyse in Zusammenhang mit NumLock und Shift. Zweitens wird bei der Tab-Taste _nur_ noch der Trigger ohne Modifier abgefragt. Das bedeutet, dass beispielsweise Tab in Verbindung mit Alt an unserem Skript vorbei geschleust wird, um Probleme zu verhindern.

-

-• Schließlich, und eines eigenen Punktes in dieser Liste würdig, werden die Modifier in deutlich reduziertem Umfang abgefragt und nur die wirklich interessanten Fälle behandelt. Auch das erlaubt beispielsweise der Alt-Taste wieder ungestörten Einsatz, Shifts werden ganz normal der Applikation gemeldet, wenn sie gedrückt sind, und weniger Merkwürdigkeiten mit lange gehaltenen Modifiern. Grundsätzlich ist in diesem Bereich aber einer der Schwachpunkte des AHK-Skripts sauberer Key-Repeat.

-

-• In jedem Fall laufen bei mir alle Modifier-Locks: Shift+Shift in jedwelcher Reihenfolge für CapsLock, Mod3+Mod3 genauso, und auch Mod4-Lock spielt auf die Art problemlos!

-

-• Bei mir hat die Bildschirmtastatur nicht richtig funktionieren wollen, wenn ich das all.ahk aus dem source/-Verzeichnis verwendet habe. Ein kleiner Patch, und schon geht’s. Ein Refresh beim ersten Start war auch eingebaut, der hat ein unnötiges Flackern produziert. Vielleicht braucht ihn ja wer, bitte melden (mit Begründung!). Außerdem habe ich die Abfragen für die Funktionstasten und von Shift+Pause im Stil der anderen Tasten abgeändert.

-

-• Nachdem ich viel Zeit verplempert hatte, weil ich den Unterschied zwischen »if Ebene = 2« und »if (Ebene = 2)« nicht gekannt und daher den ganzen Quellcode großzügig editiert hatte, um dann herauszufinden, dass es so nicht geht, habe ich jetzt konsequent (hoffentlich) alle Abfragen mit »if ()«, also mit konsequenter Klammersetzung zur richtigen Evaluierung durch AHK gemacht.

-

-• Nicht ganz fertig bin ich mit meinem deadKeys-deadComposeKeys geworden: Über Tastendrücke (z.B. Mod4+F9) sollen sich die Deadkeys und ComposeKeys tatsächlich dergestalt »umbringen«, dass sie nicht mehr am Schirm erscheinen, wodurch das Skript sie auch nicht mehr mit {bs} löschen muss, wenn das endgültige Zeichen fest steht. Für die DeadKeys ist’s schon drinnen, aber für die Compose-Sachen müsste ich die Logik ein weiteres Mal auf den Kopf stellen, und das ist mir für heute einfach zu viel.

-

-• Für das Abfragen von gemerkten DeadKeys und CompKeys habe ich Routinen geschrieben, die sich mit einem Shortcut-Evaluations-Trick recht kompakt darstellen lassen. Zusätzlich habe ich bei den Buchstaben die Abfragen für die Ebenen 1 und 2 zusammen gelegt, was nochmals deutlich Platz spart und der Übersichtlichkeit dienlich ist.

-

-• Ich habe jetzt, wo möglich, doch die Ausgabe mit »send« der mit »SendUnicodeChar« vorgezogen, da so manches Windows-Programm doch nicht ganz so intelligent wie der Rest der Meute ist. Andererseits habe ich ziemlich konsequent mit {blind} gearbeitet. Ein paar Passagen fehlen noch, insbesondere auf Ebene 2, die noch ohne {blind} sind, diese sollte man wohl umstellen auf »send {blind}{Shift up}..{shift down}«, um auch mit Alt, Strg und Win korrekt kombinieren zu können (Shift fällt ja leider flach, da bereits gedrückt).

-

-• Diverse Compose-Namen habe ich gekürzt, wenn man case-sensitive vergleichen möchte, muss man nur mit == abfragen, statt die Strings auf beispielsweise »r_capital« zu setzen.

-

-• Die Sache mit Capslock ist für meinen Geschmack immer noch nicht befriedigend gelöst, scheint aber im Moment ganz gut zu laufen. Mit Compose verträgt sich CapsLock garnicht, außer man erwartet bei aktiviertem CapsLock nach Eingabe von »R12« das da: ?.

-

-• Ungeachtet der Vorschläge, wie mit dem NumPad weiter vor zu gehen ist, habe ich es jetzt erst mal unangetastet lassen, wenn man bei solch einer Baustelle noch von Unversehrtheit sprechen kann.

-

-• Das Numpad auf Ebene 4 unter der rechten Hand habe ich derart abgeändert, dass es statt der blanken Zahlen NumPad-Codes liefert. Damit kann man es reichhaltiger verwenden als die Tasten in Zeile 1. Auch die Cursortasten auf gleicher Ebene, linke Hand, werden jetzt {blind} geschickt, um diverse Navigationsmöglichkeiten mit den anderen Modifiern (Shift, Strg) zu öffnen.

-

-• Insgesamt hat sich der Code-Umfang drastisch verringert: meine fertige neo20.ahk hat jetzt nur noch 93 kB, wogegen die alte noch 126 kB hatte. Das ist mit 33 kB fast ¼ weniger Code! Ob’s damit auch ¼ weniger Bugs sind, kann ich nicht sagen … ;-)

-

-Known Bugs:

-===========

-

-• Ich kann keine Flash-Spiele spielen (Firefox), die die Tastatur benötigen. Ist das bekannt? Ist davon auch Java betroffen?

-

-• Manche Compose-Kombinationen zwischen den Zahlen habe ich auf dem NumPad vereinheitlicht aber noch nicht auf Zeile 1.

-

-• Die diversen Compose-Experimentierkästen unter Compose/ habe ich nicht angerührt, sie werden wohl auch kleine Anpassungen benötigen.

-

-• Der Patch ist in dieser Form quasi ungetestet. Die wichtigsten funktionalen Änderungen wie die Mod-Lock und das Zusammenführen der Numlock-Numpad-Ebenen habe ich schon vor diesem Patch ausprobiert, aber insbesondere die diversen CheckDead* und CheckComp*-Aufrufe sind erst vor ein paar Stunden entstanden.

+== Neo 2.0 Autohotkey-Treiber für Windows ==
+
+== 2008-08-11 Matthias Wächter ==
+
+Ebene4-Ziffernblock: NumPadAdd und NumPadSub korrigiert
+
+
+== 2008-08-10 Matthias Wächter ==
+
+• Erstmal ist fast kein Stein auf dem anderen geblieben. Die grobe Struktur und das Verhalten (natürlich ist auch die Tastenbelegung 100% NEO!) sind grundsätzlich gleich geblieben, aber einerseits hat sich im Feinen viel getan (z.B. Tab-Behandlung), andererseits schauen viele Zeilen altbekannten Codes jetzt anders aus.
+
+• Beim »Booten« wird einmal EbeneAktualisieren() aufgerufen, um die Ebene sicher richtig zu haben. Dieses fragt jetzt auch den Zustand von NumLock ab, damit man es bei der NumPad-Behandlung gleich parat hat.
+
+• Die DeadKey- und CompKey-Behandlung ist zwar im Prinzip gleich geblieben, aber die Syntax habe ich wesentlich gestrafft. Die einzelnen Subs haben jetzt nur mehr den Job, DeadKey und CompKey zu setzen, wenn dieser nach Verlassen des Subs einen Wert haben soll.  EbeneAktualisieren() überträgt für eine einfachere Handhabung die beiden Variablen DeadKey und CompKey nach PriorDeadKey und PriorCompKey. Letztere können im Programm abgefragt werden, während die nicht-Prior-Varianten schamlos verändert werden dürfen. Das entfernt die immer gleichen (aber doch manchmal unterschiedlichen und nicht selten lückenhaften) Zeilen a la »CompKey := ""«.
+
+• Ich habe ganz dreist auf Scancodes mit Virtual Keys umgestellt. Schöner wäre es natürlich gewesen, wenn ich auf die VKs hätte verzichten können, aber das führt ja zu bekannten Problemen mit AHK-Bugs, sodass Scancode-Trigger plötzlich von SendUnicodeChar-Zeilen aktiviert werden. Durch das Abfragen der VKs sind wir aber immer noch nicht soweit, dass wir Layout-agnostisch arbeiten können.
+
+• Dabei gibt es noch ein paar wesentliche Änderungen im Bereich der Tastentrigger: Erstens gehen alle bekannten Scancodes für den NumPad auf paarweise gemeinsame Routinen. Das hält sie nicht nur konsistent, sondern ermöglicht erst eine konsequente Analyse in Zusammenhang mit NumLock und Shift. Zweitens wird bei der Tab-Taste _nur_ noch der Trigger ohne Modifier abgefragt. Das bedeutet, dass beispielsweise Tab in Verbindung mit Alt an unserem Skript vorbei geschleust wird, um Probleme zu verhindern.
+
+• Schließlich, und eines eigenen Punktes in dieser Liste würdig, werden die Modifier in deutlich reduziertem Umfang abgefragt und nur die wirklich interessanten Fälle behandelt. Auch das erlaubt beispielsweise der Alt-Taste wieder ungestörten Einsatz, Shifts werden ganz normal der Applikation gemeldet, wenn sie gedrückt sind, und weniger Merkwürdigkeiten mit lange gehaltenen Modifiern. Grundsätzlich ist in diesem Bereich aber einer der Schwachpunkte des AHK-Skripts sauberer Key-Repeat.
+
+• In jedem Fall laufen bei mir alle Modifier-Locks: Shift+Shift in jedwelcher Reihenfolge für CapsLock, Mod3+Mod3 genauso, und auch Mod4-Lock spielt auf die Art problemlos!
+
+• Bei mir hat die Bildschirmtastatur nicht richtig funktionieren wollen, wenn ich das all.ahk aus dem source/-Verzeichnis verwendet habe. Ein kleiner Patch, und schon geht’s. Ein Refresh beim ersten Start war auch eingebaut, der hat ein unnötiges Flackern produziert. Vielleicht braucht ihn ja wer, bitte melden (mit Begründung!). Außerdem habe ich die Abfragen für die Funktionstasten und von Shift+Pause im Stil der anderen Tasten abgeändert.
+
+• Nachdem ich viel Zeit verplempert hatte, weil ich den Unterschied zwischen »if Ebene = 2« und »if (Ebene = 2)« nicht gekannt und daher den ganzen Quellcode großzügig editiert hatte, um dann herauszufinden, dass es so nicht geht, habe ich jetzt konsequent (hoffentlich) alle Abfragen mit »if ()«, also mit konsequenter Klammersetzung zur richtigen Evaluierung durch AHK gemacht.
+
+• Nicht ganz fertig bin ich mit meinem deadKeys-deadComposeKeys geworden: Über Tastendrücke (z.B. Mod4+F9) sollen sich die Deadkeys und ComposeKeys tatsächlich dergestalt »umbringen«, dass sie nicht mehr am Schirm erscheinen, wodurch das Skript sie auch nicht mehr mit {bs} löschen muss, wenn das endgültige Zeichen fest steht. Für die DeadKeys ist’s schon drinnen, aber für die Compose-Sachen müsste ich die Logik ein weiteres Mal auf den Kopf stellen, und das ist mir für heute einfach zu viel.
+
+• Für das Abfragen von gemerkten DeadKeys und CompKeys habe ich Routinen geschrieben, die sich mit einem Shortcut-Evaluations-Trick recht kompakt darstellen lassen. Zusätzlich habe ich bei den Buchstaben die Abfragen für die Ebenen 1 und 2 zusammen gelegt, was nochmals deutlich Platz spart und der Übersichtlichkeit dienlich ist.
+
+• Ich habe jetzt, wo möglich, doch die Ausgabe mit »send« der mit »SendUnicodeChar« vorgezogen, da so manches Windows-Programm doch nicht ganz so intelligent wie der Rest der Meute ist. Andererseits habe ich ziemlich konsequent mit {blind} gearbeitet. Ein paar Passagen fehlen noch, insbesondere auf Ebene 2, die noch ohne {blind} sind, diese sollte man wohl umstellen auf »send {blind}{Shift up}..{shift down}«, um auch mit Alt, Strg und Win korrekt kombinieren zu können (Shift fällt ja leider flach, da bereits gedrückt).
+
+• Diverse Compose-Namen habe ich gekürzt, wenn man case-sensitive vergleichen möchte, muss man nur mit == abfragen, statt die Strings auf beispielsweise »r_capital« zu setzen.
+
+• Die Sache mit Capslock ist für meinen Geschmack immer noch nicht befriedigend gelöst, scheint aber im Moment ganz gut zu laufen. Mit Compose verträgt sich CapsLock garnicht, außer man erwartet bei aktiviertem CapsLock nach Eingabe von »R12« das da: ?.
+
+• Ungeachtet der Vorschläge, wie mit dem NumPad weiter vor zu gehen ist, habe ich es jetzt erst mal unangetastet lassen, wenn man bei solch einer Baustelle noch von Unversehrtheit sprechen kann.
+
+• Das Numpad auf Ebene 4 unter der rechten Hand habe ich derart abgeändert, dass es statt der blanken Zahlen NumPad-Codes liefert. Damit kann man es reichhaltiger verwenden als die Tasten in Zeile 1. Auch die Cursortasten auf gleicher Ebene, linke Hand, werden jetzt {blind} geschickt, um diverse Navigationsmöglichkeiten mit den anderen Modifiern (Shift, Strg) zu öffnen.
+
+• Insgesamt hat sich der Code-Umfang drastisch verringert: meine fertige neo20.ahk hat jetzt nur noch 93 kB, wogegen die alte noch 126 kB hatte. Das ist mit 33 kB fast ¼ weniger Code! Ob’s damit auch ¼ weniger Bugs sind, kann ich nicht sagen … ;-)
+
+Known Bugs:
+===========
+
+• Ich kann keine Flash-Spiele spielen (Firefox), die die Tastatur benötigen. Ist das bekannt? Ist davon auch Java betroffen?
+
+• Manche Compose-Kombinationen zwischen den Zahlen habe ich auf dem NumPad vereinheitlicht aber noch nicht auf Zeile 1.
+
+• Die diversen Compose-Experimentierkästen unter Compose/ habe ich nicht angerührt, sie werden wohl auch kleine Anpassungen benötigen.
+
+• Der Patch ist in dieser Form quasi ungetestet. Die wichtigsten funktionalen Änderungen wie die Mod-Lock und das Zusammenführen der Numlock-Numpad-Ebenen habe ich schon vor diesem Patch ausprobiert, aber insbesondere die diversen CheckDead* und CheckComp*-Aufrufe sind erst vor ein paar Stunden entstanden.