1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
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.
|
