Python als Basis für komplexe GUI Anwendungen

Tkinter

Tkinter ist die Anbindung an Tk. Der Hauptvorteil von Tkinter ist, daß es bestandteil der Standardbibliothek ist. Als Entwickler kann man also davon ausgehen, daß es entweder bereits beim Benutzer installiert (es ist zum Beispiel Standardbestandteil des Windows Installers von Python) oder es nicht schwer für den Benutzer ist, es nachträglich zu installieren (die meisten GNU/Linux-Distributionen enthalten ein Tkinter-paket).

Tkinter ist außerdem sehr stabil. Wenn ein Programm Tkinter nicht richtig benutzt, gibt es praktisch immer eine Python-Exception. Speicherzugriffsfehler und ähnliche Probleme sind extrem selten.

Das Angebot an GUI-Elementen, das Tkinter mitbringt ist aus heutiger Sicht etwas mager, so gibt es z.B. kein "Tree-View" für die Darstellung von Baumstrukturen. Es gibt aber Bibliotheken die solche Elemente in Python implementieren, z.B. PMW.

Was von manchen als Nachteil empfunden wird, ist, daß Tkinter nicht nur an Tk selbst gebunden ist, sondern dazu einen kompletten Tcl-Interpreter verwendet. Sie sehen Tkinter daher als aufgebläht und langsam an. Wir können das so nicht nachvollziehen. Sketch, zum Beispiel, das es momentan in vergleichbarer Funktionalität sowohl in einer Tkinter- als auch einer PyGTK-Variante gibt, braucht mit GTK 2.2 deutlich mehr Speicher als mit Tk. Beide Versionen fühlen sich subjektiv auch etwa gleich schnell an.

wxPython

wxPython ist die Anbindung an wxWindows. wxWindows ist eine plattformunabhängige GUI Bibliothek die auf den normalen plattformspezifischen Bibliotheken aufsetzt und damit jeweils ein zur Plattform gehörendes Look&Feel hat.

wxWindows bietet einerseits Standardelemente wie Menüs, Dialoge, Buttons, etc. und auch komplexere Widgets wie etwa das Grid-Widget für Tabellen. wxWindows bietet darüber hinaus aber auch ein Applicationframework und plattformunabhängige Schnittstellen für Dinge, die nicht unmittelbar mit grafischen Benutzeroberflächen zu tun haben, wie etwa Drucken oder das Starten von Subprozessen.

PyGTK und gnome-python

PyGTK ist die Anbindung an GTK+. Es ist Teil von gnome-python, der Anbindung an die Gnome-Bibliotheken. GTK selbst ist im wesentlichen nur ein Toolkit, d.h. es besteht aus den normalen GUI-Elementen sowie einigen Standarddialogen. Drucken und andere darüber hinausgehende Dienste können über gnome-python genutzt werden.

Zu den von pygtk unterstützten Plattformen gehört neben GNU/Linux und anderen Unix-ähnlichen Systemen auch MS Windows.

PyQt und PyKDE

PyQt und PyKDE sind, wie die Namen schon vermuten lassen, die Anbindungen and Qt und KDE. Ähnlich wie wxWindows bietet auch Qt die Möglichkeit zum Drucken und andere Features, die nicht direkt an die GUI gebunden sind.

Ein Nachteil von Qt gegenüber den anderen hier erwähnten Toolkits ist, daß es nur in der Version für das X Window System Freie Software ist. Insbesondere ist die Version für MS Windows nicht frei. PyQt folgt im wesentlichen dem gleichen Lizenzmodell wie Qt und ist nur für die GPL-Version von Qt Freie Software

Auswahl der "richtigen" Bibliothek

Welche der vielen Bibliotheken für graphische Benutzeroberflächen, die mit Python genutzt werden können, man verwenden sollte hängt natürlich immer vom Projekt ab. Daher können wir hier nur recht allgemeine Hinweise geben.

Ein Applikation-Framework ist für ein Python-Programm nicht unbedingt wichtig. Viele Teile eines Applikation-Frameworks, wie zum Beispiel Klassen um das Model-View-Controller-Konzept zu implementieren sind in Python recht einfach selbst zu schreiben (s.u.).

Schnittstellen zu nicht-GUI Funktionalitäten wie etwa Datenbanken sind in der Regel schon unabhängig von GUI-Toolkits für Python verfügbar und spielen daher aus der Sicht eines Pythonprogrammierers eigentlich keine Rolle. wxPython zum Beispiel verzichtet daher auch auf eine Anbindung der Datenbankschnittstelle wxODBC.

Eine Ausnahme bildet hier das Drucken, da man zumindest unter Windows dem Benutzer die Standarddialoge zur Druckerauswahl und -konfiguration anbieten sollte. In dieser Hinsicht sind wxWindows und Qt interessant.

Model-View-Controller

Das Model-View-Controller (MVC) Konzept und seine Geschwister Model-View-Presenter und die Observer Design-Pattern sind wohl die bekanntesten Konzepte bei der Trennung von GUI und Logik. Die Observer-Pattern ist allerdings nicht unbedingt auf GUIs bezogen.

Die Kernidee hinter MVC ist, daß die Logik im Modell implementiert ist, der View lediglich den Zustand (eines Teils) des Modells darstellt und der Controller Benutzereingaben wie z.B. Mausclicks entgegennimmt und in Aufrufe von Methoden des Modells umsetzt.

In Thuban zum Beispiel ist das Modell die Karte mit den verschiedenen Ebenen von Daten. Es gibt mehrere Views, unter anderem die Karte im Hauptfenster und die Legende:

Der Maßstab unten links ist natürlich auch ein View, aber nicht auf die Karte selbst, sondern auf den Skalierungsfaktor der bei der Darstellung der Karte im rechten Teil des Fensters verwendet wird. In einem Programm gibt es also meist nicht nur ein Modell sondern mehrere und Views können selbst wieder Modelle sein.

Das Modell muss dabei natürlich die Views immer dann informieren, wenn sich sein Zustand ändert, so daß sich die Views auf den neuesten Stand bringen können. Um die Kopplung zwischen Modell und View lose zu halten, sollte das Modell aber nicht wissen müssen, welche Views dies sind. In Sketch und Thuban wird diese lose Kopplung durch einen in Python implementierten Benachrichtigungsmechanismus erreicht.

Das Konzept hinter diesem Benachrichtigungsmechanismus ist, daß es meist einige Objekte gibt, die Nachrichten senden und viele Empfänger solcher Nachrichten. Die Sender sind normalerweise von einer gemeinsamen Basisklasse, Publisher abgeleitet. Publisher-Instanzen veröffentlichen gewissermassen Nachrichten und die Empfänger abonnieren sie indem sie mit den Methoden Subscribe und Unsubscribe ihr Abo verwalten. Eine Publisherinstanz verschickt nachrichten über ihre issue Methode.

Als Beispiel hier eine Methode aus Thubans Map Klasse. Ein Kartenobjekt hat in Thuban ein Projektion, durch die definiert ist, wie die Oberfläche der Erde auf eine Ebene abgebildet wird. Die SetProjection Methode weist eine neue Projektion zu:

	  def SetProjection(self, projection):
	      self.projection = projection
              self.issue(MAP_PROJECTION_CHANGED, self)
	

Hier wird also zunächst einfach die Projektion an die entsprechende Instanzvariable gebunden und dann eine MAP_PROJECTION_CHANGED Nachricht verschickt. Die Nachricht hat einen Parameter, nämlich die Karte selbst so daß Empfänger Nachrichten von verschiedenen Karten auseinanderhalten können.

Für die Empfängerseite hier ein Beispiel aus der View-Klasse:

	  def SetMap(self, map):
              if self.map is not None:
                  self.map.Unsubscribe(MAP_PROJECTION_CHANGED,
                                       self.projection_changed)
	      self.map = map
              if self.map is not None:
                  self.map.Subscribe(MAP_PROJECTION_CHANGED, 
	                             self.projection_changed)
	

Die SetMap Methode weist dem View eine neu darzustellende Karte zu. Zuerst muß also die Benachrichtigung bei der eventuell vorhandenen alten Karte abbestellt werden (mit Unsubscribe) und nachdem die Instanzvariable gesetzt wurde wird die Nachricht der neuen Karte abonniert. Der Code hier ist recht stark vereinfacht, da es unter anderem noch einige andere Nachrichten gibt, auf die der View reagieren sollte.

Der erste Parameter von Subscribe und Unsubscribe ist der Nachrichtentyp. Der zweite ein aufrufbares Objekt -- hier eine gebundene Methode. Wenn eine Nachricht gesendet wird, wird das aufrufbare Objekt mit den Parametern der Nachricht aufgerufen.

Für (noch) nicht Pythonprogrammierer bedarf der Begriff "gebunden Methode" vielleicht noch einer Erläuterung. Ein Methodenaufruf sieht in Python sehr ähnlich aus wie in Java oder C++:

	  objekt.methode(arg1, arg2)
	

Bei der Ausführung dieses Methodenaufrufs wertet Python zunächst den Ausdruck objekt.methode aus. Das liefert, wenn "methode" tatsächlich der Name einer Methode des Objekts objekt ist, ein gebundenes Methodenobjekt. Ein solches Objekt enthält eine Referenz auf das Objekt, an das es gebunden ist, und eine Referenz auf das Funktionsobjekt, das die Methode implementiert. Beim Aufruf des Methodenobjekts wird dann die Funktion mit dem Objekt als erstem Parameter aufgerufen.

In unserem Fall ist die Methode folgende:

	  def projection_changed(self, *args):
	      self.FitMapToWindow()
	

Das, heißt, wir ignorieren alle Argumente (args, ein Tuple das alle Parameter der Methode bis auf self enthält, wird in der Methode nirgends mehr verwendet) und passen dann die Skalierung der Kartendarstellung so an, daß die ganze Karte ins Fenster passt. FitMapToWindow sorgt auch dafür, daß die Karte neu gezeichnet wird.

Nun kann es sehr leicht passieren, daß durch eine Benutzeraktion mehrere Nachrichten vom Modell verschickt werden, die alle ein Update des Fensters verlangen. Wenn das Neuzeichnen sehr aufwändig ist, wie hier im Falle von Thuban, wo hinter einer Karte viele Megabytes an Daten stehen können, ist es wichtig, das Zeichnen etwas aufzuschieben, bis das Programm wieder auf Ereignisse des Fenstersystems wartet. Die meisten Toolkits bieten hierfür sogenannt Idle-Events an.