DSA4 Werkzeug

Denny Vrandecic beschreibt hier die Entwicklung des DSA4 Werkzeugs. Das DSA4 Werkzeug ist ein Tool, um Spielern und Spielleitern beim Spielen der vierten Edition des Rollenspiels Das Schwarze Auge zu unterstützen. Mehr Spiel, weniger Verwaltung!

Sonntag, Februar 26, 2006

Die GUI - XUL, HTML und CSS

Das Herzstück von Mozilla ist die Renderingengine Gecko. Sie liest zum Beispiel (X)HTML ein und stellt dieses dann auf dem Monitor dar. Damit lassen sich bereits sehr interaktive und sich äußerst dynamisch anfühlende Webseiten erstellen, insbesondere wenn man JavaScript mit verwendet. An Beispielen wie GMail oder start.com kann man erkennen, wieviel heute schon mit HTML möglich ist. Dennoch: viele GUI-Elemente wie Listen, Menüs oder Knöpfe sind in HTML eher umständlich umgesetzt. Darum wurde XUL, die XML User Interface Language, eingeführt, eine XML-Sprache zur Beschreibung von graphischen Benutzerschnittstellen.

Mit XUL ist es dann möglich, zu Beschreiben, wo bestimmte Elemente auftauchen, welche wo auftauchen, etc. Dadurch wird es zum Beispiel leicht fallen, verschiedene Versionen der GUI zu erstellen, eine für Experten und eine für Anfänger. Insbesondere könnte man sich einen Schritt-für-Schritt-Wizard für die Heldenerschaffung vorstellen, wie sie in den meisten anderen Editoren wie Helden praktiziert wird. Meine persönliche Vorliebe bleibt dennoch beim "Immer alles veränderbar"-Modus. Aber die Codebasis wird sehr einfach beides hergeben.

Ein weiterer Vorteil von XUL ist, dass damit das User Interface interpretiert, nicht compiliert wird. Das hat den Vorteil, dass, wenn man das Aussehen des Programms verändern will, man nicht eine ganze Programmierumgebung mit Compiler etc. braucht, sondern einfach nur einen Texteditor und etwas XML- oder HTML-Kenntnisse. Hoffnung dabei: schöne neue Skins und bessere Bedienbarkeit können von wesentlich mehr Leuten beigesteuert werden als bisher.

Apropos Skins: ja, auch das wird möglich sein. Wie von Thunderbird und Firefox gewohnt, sind XUL-basierte Anwendung vollkommen mit CSS und ähnlichem skinbar. Das heißt Farben, Hintergründe, Aussehen der Elemente sind steuerbar. Ich stelle mir jetzt schon ein Horasreich-Skin, ein Myranor-Skin und ein G7-Skin vor. Mal sehen. Es wird letztlich von Eurer Kreativität abhängen.

Auch hier ist das wichtige: man muss dafür keine Programmierumgebung besitzen und keine Programmierkenntnisse haben (auch wenn sie natürlich nicht schaden). Der wichtigste Teil des neuen Designs ist es, die einzelnen Teile der Architektur orthogonal zu gestalten, so dass man an einem bestimmten Teil arbeiten kann, ohne das man ein Experte in allen sein muss. Etwas, was bei der ersten Version sträflichst vernachlässigt wurde.

Nächstes Mal: zum Datenmodell und der Datenhaltung.

Freitag, Januar 27, 2006

Architektur

Die bisherige Version des DSA4 Werkzeugs ist in C++ programmiert. Für die Daten entschied ich mich damals für ein XML-Datenformat, was zu der Anbindung von Xerces führte. Die GUI wurde mit wxWindows gemacht (die ersten Versionen, falls sich noch jemand erinnert, beruhten auf MSXML und native Windows GUI Elemente). Der Wechsel auf Xerces und wxWindows wurde durchgeführt, um Plattformunabhängig zu sein. Und tatsächlich: der Code compilierte auch unter Linux (dank hier an die Portierer). Aber richtig laufen tat er nie, es waren immer irgendwelche Bugs in der Linuxversion, die ich nicht in der Windowsversion nachvollziehen konnte.

Außerdem war das verwendete C++ viel zu kompliziert. Ich benutzte massig Templates (vor allem für die Rassen, Kulturen und Professionen), was den Code sehr schwer lesbar und bearbeitbar machte. Auch das ein schlichtes compilen war eine recht anspruchsvolle Prozedur. Ich gehe davon aus, dass deswegen nie im größeren Maße Entwicklungsarbeit von anderen als von mir geleistet wurde: mein Code war schlicht zu kompliziert. Aus de selben Grund habe ich selber ja in den letzten Monaten den Code nicht angefasst.

Dies ist die wichtigste Lektion für die neue Version: deutlich einfacherer Code. Änderungen müssen auch ohne sich extrem reinzuarbeiten möglich sein. Idealerweise sollte das ganze Werkzeug interpretiert sein. Kein compilen mehr. Ändern. Neustart. Fertig.

Wie ich das erreichen will verrate ich in den nächsten Blogeinträgen genauer (deswegen habe ich auch nicht so viel geschrieben die letzten Tage -- und weil ich auf Dienstreisen in Kaiserslautern und Düsseldorf war -- ich wollte zunächst ein halbwegs tragbares Konzept haben. Das kommt jetzt die nächsten paar Tage. Hier schonmal eine grobe Übersicht -- ich werde im Folgenden genauer auf die Begriffe und den Aufbau eingehen.

Mozilla, die Open Source Gruppe die uns nicht nur Firefox und Thunderbird beschert hat, hat, was die Basis ihrer Tools ist, ein umfangreiches, so genanntes Mozilla Application Framework erstellt. Im Großen und Ganzen ist es ein supermächtiges Biest -- ich will es soweit zähmen, damit das DSA4 Werkzeug darauf läuft. Hierbei gibt es eine Hauptengine, die XULRunner heißt. XUL ist so etwas wie HTML, bloß für GUIs von Anwendungen (und man kann tatsächlich auch HTML und JavaScript in XUL mit benutzen). Das bedeutet, das User Interface des neuen DSA4 Werkzeugs zu ändern wird so leicht sein wie HTML-Seiten schreiben, ja, sogar mit CSS arbeitet das ganze zusammen. Interessant ist hierbei vor allem das Verwenden von JavaScript, das eine dynamische GUI erlaubt. Die Applikationslogik hingegen kann entweder in JavaScript implementiert werden, oder auch in C++ oder Java (oder Python), um dann über XPCOM (oder PyXPCOM) darauf zuzugreifen. Potenziell also kann man auch Teile des bisherigen Codes wiederverwenden! Schließlich, die Daten werden in RDF gespeichert, einer XML-basierten Sprache, die aber deutlich Vorteile zu XML (und ein paar Nachteile) aufweist.

All dies unterstützt das Mozilla Application Framework von Haus aus. Anhand von Thunderbird und Firefox sieht man ja, dass das durchaus zu brauchbaren Applikationen führen kann. Ich hoffe, dass es auch hier aufgeht.

Sonntag, Januar 15, 2006

Ein neuer Anfang

Alles, was aufwändiger ist als ein Blog scheint zur Zeit nicht zu funktionieren.

Wie viele von Euch wissen, verfolge ich seit langem das Ziel, ein Programm zu erstellen, welches beim Spielen von DSA in der vierten Edition Spielern und Spielleitern zur Hand geht. Wie ebenfalls die meisten wissen, war das Projekt leider die letzten Monate tot. Dies hatte mehrere Gründe: einerseits habe ich schlichtweg viel weniger Zeit als früher, und schließlich habe ich mich mit den Aufgaben beim DSA4 Werkzeug übernommen. Ich wollte sowohl das Programm erstellen - in allen Aspekten, Datenhaltung, User Interface, Logos, als auch die dazugehörige Website betreuen, als auch die Dokumentation schreiben, als auch eine Softwarebibliothek in C++ erstellen, die für DSA4-Tools gedacht ist, als auch die Druckausgabe verfeinern, als auch das XML-Format definieren, als auch die entstehende Community verwalten. Das mageine ganz kurze Zeit funktioniert haben -- aber es musste, als ich meinen Beruf angetreten habe, schief gehen. Dummerweise liebe ich auch noch meinen Beruf, was mich zwar persönlich erfreut, aber der Entwicklung des DSA4 Werkzeugs nicht gut tut.

Ich werde in diesem Blog anfangen, die weitere Entwicklung des DSA4 Werkzeugs nach außen zu präsentieren. Dies ist ein vorläufiger Ersatz für eine echte Website, die einen Community-Prozess erlaubt. Aber diese Website werde ich nicht aufstellen. Ebenso werde ich tatsächlich nur wenige Emails im Zusammenhang mit dem DSA4 Werkzeug ausführlich beantworten. Ich brauche jemanden, der sich bereit erklärt, eine dazugehörige Website zu pflegen, und jemanden, der mir bei der Community helfen will. Ich erinnere mich, dass ich früher teilweise mehr Zeit in die Website und die Beantwortung von Emails investiert habe, als in die eigentliche Entwicklung. Dies muss ich diesmal vermeiden. Die Community war großartig! Ich brauche bloß an Leute wie Twel oder Wolfgang denken, die unglaubliches geleistet haben. Wer sich berufen fühlt, zu helfen, melde sich bitte bei mir.

Damit klar ist: ich werde auch in Zukunft nicht auf magische Weise mehr Zeit haben. Aber meine Erfahrungen in Industrie und Forschung, sowie das Wissen und die Erfahrung, die ich inzwischen über Open Source Community Prozesse und Software Engineering angesammelt habe, erlauben mir -- so die Hoffnung -- einige Fehler der ersten zwei Versionen des DSA4 Werkzeugs zu vermeiden. Die Architektur des alten DSA4 Werkzeugs war sehr durchdacht, und extrem flexibel. Leider war sie auch sehr kompliziert: metatemplate-Programmierung in C++ ist megacool, aber es macht den Einstieg für andere nicht gerade einfach. Einer der Gründe, warum es in den Monaten der aktiven Entwicklung keine 100 Zeilen von anderen Entwicklern in den Quelltext geschafft haben, oder warum niemand das Projekt aufgegriffen hat, nachdem ich offensichtlich nicht mehr weiterarbeitete. Dies wird der Hauptpunkt, den ich angreifen werde.

In den nächsten Tagen - ja, wirklich, Tagen - werde ich hier anfangen, in Blogeinträgen die neue Architektur zu skizzieren, sowie diverse Punkte auflisten. Zu einem Zeitplan möchte ich mich nicht durchringen, wann das Programm fertig wird. Aber ich kann versprechen, dass ein neuer Anfang gemacht ist. Warum? Weil das nicht Absicht ist, sondern auf erstem Code beruht. Zugegeben, bisher nur auf meiner Platte. Aber sobald es vorzeigbar ist, auch wieder auf SourceForge im CVS.