Umlaute ohne QWERTZ Tastatur-Layout (für Windows-Nutzer)

Ich verwende seit Jahren unter Linux (X11) eine .Xmodmap-Datei die mir ermöglicht, stressfrei deutsche Umlaute zu schreiben: Drücke ich [Windows]-[o] bekomme ich ein ö. Brauche ich ein Ö, drücke ich [Windows]-[Shift]-[o]. Ein ß gibt’s mit [Windows]-[s]. Das funktioniert hervorragend, nach wenigen Tagen hatte ich mich daran gewöhnt – und die Windows-Taste ist nun endlich mal für etwas gut 🙂

Da ich mich seit längerem im Ausland aufhalte, treffe ich viele Deutsch-Schreibende die auf amerikanischem Tastatur-Layout schreiben. Darunter sind (leider) auch viele Windows-Benutzer. Alle diese Personen umschreiben die Umlaute mit “oe”, “Oe”, “ss”, etc.

Also habe ich heute mal recherchiert, ob es nicht doch eine Möglichkeit gibt, diesen Personen zu Umlauten zu verhelfen. Die offensichtlichste Möglichkeit ist natürlich, auf Linux umzusteigen und meine .Xmodmap zu verwenden. Aber das ist eher etwas längerfristiges, und viele sind dafür einfach zu unflexibel…
Es gibt jedoch noch eine andere Lösung, dank der unter der GPL stehenden Software AutoHotKey. Ungewohnt schön (für Windows-Programm-Verhältnisse) an dieser Software ist, dass sie sogar einen “Compiler” mitbringt, der aus der Tasten-Mapping-Definition eine ausführbare Datei erstellt.

Die AutoHotKey Mapping-Definition (.AHK Datei), die zu meiner gewünschten Funktionalität führt, sieht so aus:

+#a::Ä
#a::ä
+#o::Ö
#o::ö
+#u::Ü
#u::ü
#s::ß

Sehr wichtig dabei ist, dass die Datei ANSI-codiert gespeichert wird, weil AutoHotKey wohl nichts mit Unicode anzufangen weiß. Wenn man sich allerdings (wie ich während meiner Recherche) auf einer Windows-Installation befindet, deren Non-Unicode program locale keine deutschen Umlaute im erweiterten ASCII-Bereich hat, ist das nicht sonderlich einfach zu bewerkstelligen. Man kann die Datei nicht ohne Weiteres mit Windows-Bordmitteln ANSI-codiert abspeichern, sofern man nicht die Locale auf Deutsch (oder irgend eine andere Sprache bei der die o.g. Umlaute im erweiterten ASCII-Bereich vorkommen) umstellt. Und danach ist natürlich Neustarten angesagt – wie könnte es auch anders sein…

Mit etwas Vertrauen in mich kannst du aber auch einfach meine umlauts.exe herunterladen, die ich mit AutoHotKey erstellt habe. Nach dem Ausführen befindet sich das AutoHotKey-Logo im System-Tray und man kann Umlaute wie oben beschrieben tippen. Ich habe keine Trojaner oder sonstige Schädlinge eingebaut (zumindest nicht wissentlich).

Update (2009-05-17): Es hat sich herausgestellt, dass diese ganze Sache in GTK-für-Windows-Anwendungen wie Pidgin nicht funktioniert. Ich habe nun einen Workaround gebastelt, der in Pidgin funktioniert – aber schön ist was anderes. Die AHK-Datei ist dadurch etwas länger geworden: umlauts.ahk

Die umlauts.exe habe ich aktualisiert.

Update (2010-03-12): Als (verspätete) Reaktion auf jan und Daniels Kommentare habe ich nun das Script umlauts.ahk verbessert, und auch eine neue umlauts.exe gebaut. Ich verwende weiterhin die [Windows]-Taste. AltGr ist keine Option, da es diese Taste auf vielen Tastaturen (z.B. US-Layout) nicht gibt.

Update (2011-04-09): Auf mcmusics Wunsch habe ich eine Version erstellt, die zusätzlich noch die Y und Z Taste vertauscht, für Leute die sich schwer tun, sich an diese Vertauschung beim QWERTY-Layout zu gewöhnen. Hier ist das umlauts-yz-swapped.ahk Script, und hier die umlauts-yz-swapped.exe.
Übrigens, beim Herunterladen von AutoHotKeys habe ich gesehen, dass es jetzt eine neue Version gibt, die auch mit Unicode klarkommt – vermutlich ist es damit möglich, eine umlauts.exe zu bauen, die auf den Clipboard-Hack verzichtet. Kann ja mal jemand mit mehr Zeit testen und dann hier berichten.

Update (2012-02-14): Die alte umlauts.exe funktionierte in Lotus Notes recht unzuverlässig: Manchmal kam der richtige Buchstabe (vor allem beim ß), aber manchmal kam irgend ein anderes Sonderzeichen. Daraufhin habe ich mal versucht, das selbe Script mit dem neuen AutoHotKey L (mit Unicode-Unterstützung) zu compilen, und nach einer Konvertierung des Scripts nach UTF-8 hat das auch gleich perfekt funktioniert. Bisher konnte ich damit in Lotus Notes noch keine Fehlfunktion feststellen. Der Clipboard-Hack ist übrigens für GTK-Anwendungen weiterhin notwendig. Die UTF-8-Variante des AHK-Scripts gibt’s hier: umlauts2.ahk, und gebaut als EXE (nun knapp 800 anstatt früher 200 KB) hier: umlauts2.exe.

Update (2013-01-04): umlauts2.exe funktionierte nicht mehr in Thunderbird, weil Mozilla die Window Class geändert hat. Ich habe nun den Check auf die Window Class rausgeworfen, und benutze immer den Umweg über die Zwischenablage, was bisher in allen getesteten Programmen zuverlässig funktioniert hat. Weiterhin habe ich [Windows]-e mit dem Euro-Zeichen (€) belegt, und [Windows]-y mit dem Yuan/Yen Zeichen (¥). Zu guter Letzt habe ich den Code etwas umstrukturiert und kommentiert. umlauts3.ahk, umlauts3.exe

Fresh vs. rotten ext3

Did you ever hear sentences like “Linux/Unix filesystems are superior, to stuff like NTFS, let alone FAT32 – you don’t even need a defragmentation tool.”?

That statement may be technically correct, since fragmentation is really rare with ext3 – but what about spatial locality of reference – files that are often accessed at nearly the same time being spread over the whole disk, thus causing long access times due to head positioning?
There is (AFAIK) no way to (programmatically) optimise / sort a Linux filesystem in a way that for example all init scripts, binaries, libraries, etc. reside in nearby sectors on a harddisk. Those tools do exist in the Windows world (built into those 3rd party defragmenters).

The only way to do this optimisation is “by hand”: make a backup, mkfs and restore the backup – but that’s something you only do when you have a lot of time, or when I/O finally got painfully slow.

One factor that probably plays an important role, is, that I usually only have one partition (+swap) that contains everything – etc, usr, usr/portage, var, home, …
With such a setup, after only a few months of updating the system, downloading stuff from the net, copying pictures from the DSLR to the harddisk, updating the system again, etc. will lead to all kinds of files being well spread throughout the whole disk. Imagine some init scripts and binaries they call still being at the “beginning” of the disk, some others, due to updates, at the “end”. And that’s what makes I/O slow… see for yourself:

From loading the kernel to KDM being ready for login on a

(sorry for the poor video quality)

That is an ~80% performance decrease.

How I got the videos:

  1. Capture startup of my system stored on a months old ext3 partition
  2. Backup (with dar)
  3. mkfs.ext3
  4. Restore
  5. Capture startup of my system on a freshly made ext3 partition
  6. Trim the videos so that frame 1 is the first frame on which kernel output is visible and the last frame is the first frame on which KDM shows the input widgets

Hoping that this situation will improve with ext4 – I heard online defragmentation will be possible at some point, and that probably also makes “sorting” the filesystem possible.