AppLaunch: Anwendungen bequemer starten

Hintergrund

Die Idee zu AppLaunch kam mir auf der Arbeit, wo ich eine Vielzahl von Dokumenten, Programmen, Verzeichnispfaden, etc. benötige. Um diese nicht jedes Mal aufwändig heraussuchen zu müssen, fing ich an Verknüpfungen auf dem Windows-Desktop anzulegen. Danach habe ich mich dabei ertappt, wie ich ständig auf dem Desktop nach der passenden Verknüpfung gesucht habe. Zu der Zeit, als AppLaunch entstand, kam hinzu, dass ich öfters Windows-Anwendungen debuggt habe; hält man eine solche im Debugger fest, lassen sich deren Fenster nicht minimieren und man kommt nicht mehr an den Desktop dran...

Von KDE kannte ich Katapult, so etwas wollte ich haben. Aber ich konnte nichts Vergleichbares für Windows XP finden. Also habe ich begonnen AppLaunch zu entwickeln. Obwohl es inzwischen auch für Windows entsprechende Anwendungen gibt, benutze ich auf der Arbeit immer noch AppLaunch. Allerdings ist die mir bekannte "Fanbase" mit derzeit 5 Benutzern (drei Kollegen und ein ehemaliger Kollege) recht überschaubar. Benutzt das noch jemand da draußen?

Was kann es?

In einem Satz: durch Betätigen eines Hot-Keys erscheint ein Fenster, in das Kurzbefehle eingegeben werden können, die vordefinierte Befehlszeilen ausführen und bei Bedarf Parameter übernehmen.

Weiterhin:

• Frei wählbarer Hot-Key (sofern kein Konflikt mit anderen Anwendungen besteht)
• Mapping von Schlüsselwort auf Befehlszeile (Konfigurationsdatei)
• Automatische Vervollständigung von Befehlen per Tab-Taste
• Eingabe zusätzlicher Parameter möglich
• Unterstützung der Zwischenablage sowie Drag & Drop
• Konfigurierbares Erscheinungsbild (Textfarbe, Hintrgrundfarbe)

Die Konfiguration erfolgt über eine einfache Textdatei. Diese kann entweder unter %AppData%\AppLaunch in der lokalen Benutzerkonfiguration abgelegt werden, oder beim Start des Programms als Parameter übergeben werden. Die Konfiguration kann zur Laufzeit neu eingelesen werden, ohne das Programm neu starten zu müssen.

Wozu die vielen Dokumente?

Anfängerfehler. ;-)

Zu der Zeit, als ich AppLaunch entwickelt habe, hatte ich gerade die Artikel von Joel Spolsky (joelonsoftware.com) quasi inhaliert und wollte ausprobieren, ob die von ihm propagierte Vorgehensweise auch für Ein-Personen-Bastelprojekte Sinn ergibt. Also habe ich das volle Arsenal aufgefahren: Versionskontrolle (sowieso), Bugtracking, Bugfixes vor Feature-Entwicklung, und eben auch Erstellung einer Spezifikation. Ergänzt habe ich das noch durch Doxygen-Kommentare im Quellcode, weil ich das eh schon immer mal probieren wollte.

Würde ich das wieder tun? Klares "jain". Die erwarteten Vorteile haben sich eingestellt und es lässt sich schwer beurteilen, ob es anders gelaufen wäre, wenn ich es nicht so getan hätte. Am wenigsten genützt haben die Doxygen-Kommentare. Versionskontrolle habe ich sowieso schon lange praktiziert (ab 2000 CVS, so ab 2008 SVN und seit ca. 2016 Git) und würde nichts mehr ohne anfangen, außer expliziten Fummel- und Wegwerfcode. Bugfixing nicht auf die lange Bank zu schieben ist auch zur Gewohnheit geworden, zur Verwaltung genügt mir in Ein-Personen-Projekten allerdings eine simple Textdatei (oder direkt grep-bare Kommentare im Quellcode).

Bleiben die Spezifikationen. Überlicherweise habe ich immer etwas, das der Erstellung von Quellcode vorausgeht. Meistens ist es ein Dokument mit Beschreibung des Gesamtziels und der Anforderungen (und wenn nur als 10-zeilige Textdatei), wenn es etwas komplexer wird auch ein paar UML-Diagramme, die das Design dokumentieren. Ich habe das als ungemein nützlich empfunden, wenn man nur gelegentlich Zeit findet an einem Projekt weiter zu arbeiten. Es verhindert, dass das ganze Ding in irgendeine Richtung "wegmutiert" oder sich widersprüchliche Features anhäufen. Generell lassen sich Widersprüche auf der Ebene von Text oder Diagrammen mit viel weniger Aufwand erkennen und beseitigen, als wenn da schon mal ein Haufen Quellcode existiert, an dem man hängt ("funktioniert ja schon fast...").

Downloads