Python als Basis fr 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 fr den Benutzer ist, es nachtr臠lich 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 臧nliche 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" fr 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臧t und langsam an. Wir knen das so nicht nachvollziehen. Sketch, zum Beispiel, das es momentan in vergleichbarer Funktionalit舩 sowohl in einer Tkinter- als auch einer PyGTK-Variante gibt, braucht mit GTK 2.2 deutlich mehr Speicher als mit Tk. Beide Versionen fhlen sich subjektiv auch etwa gleich schnell an.

wxPython

wxPython ist die Anbindung an wxWindows. wxWindows ist eine plattformunabh舅gige GUI Bibliothek die auf den normalen plattformspezifischen Bibliotheken aufsetzt und damit jeweils ein zur Plattform gehendes Look&Feel hat.

wxWindows bietet einerseits Standardelemente wie Mens, Dialoge, Buttons, etc. und auch komplexere Widgets wie etwa das Grid-Widget fr Tabellen. wxWindows bietet darber hinaus aber auch ein Applicationframework und plattformunabh舅gige Schnittstellen fr Dinge, die nicht unmittelbar mit grafischen Benutzeroberfl臘hen 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 darber hinausgehende Dienste knen ber gnome-python genutzt werden.

Zu den von pygtk untersttzten Plattformen geht neben GNU/Linux und anderen Unix-臧nlichen 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lichkeit zum Drucken und andere Features, die nicht direkt an die GUI gebunden sind.

Ein Nachteil von Qt gegenber den anderen hier erw臧nten Toolkits ist, daﾟ es nur in der Version fr das X Window System Freie Software ist. Insbesondere ist die Version fr MS Windows nicht frei. PyQt folgt im wesentlichen dem gleichen Lizenzmodell wie Qt und ist nur fr die GPL-Version von Qt Freie Software

Auswahl der "richtigen" Bibliothek

Welche der vielen Bibliotheken fr graphische Benutzeroberfl臘hen, die mit Python genutzt werden knen, man verwenden sollte h舅gt natrlich immer vom Projekt ab. Daher knen wir hier nur recht allgemeine Hinweise geben.

Ein Applikation-Framework ist fr 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舩en wie etwa Datenbanken sind in der Regel schon unabh舅gig von GUI-Toolkits fr Python verfgbar 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 natrlich 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nen selbst wieder Modelle sein.

Das Modell muss dabei natrlich die Views immer dann informieren, wenn sich sein Zustand 舅dert, so daﾟ sich die Views auf den neuesten Stand bringen knen. Um die Kopplung zwischen Modell und View lose zu halten, sollte das Modell aber nicht wissen mssen, 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舅ger solcher Nachrichten. Die Sender sind normalerweise von einer gemeinsamen Basisklasse, Publisher abgeleitet. Publisher-Instanzen verfentlichen gewissermassen Nachrichten und die Empf舅ger 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臘he 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臘hst einfach die Projektion an die entsprechende Instanzvariable gebunden und dann eine MAP_PROJECTION_CHANGED Nachricht verschickt. Die Nachricht hat einen Parameter, n舂lich die Karte selbst so daﾟ Empf舅ger Nachrichten von verschiedenen Karten auseinanderhalten knen.

Fr die Empf舅gerseite 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.

Fr (noch) nicht Pythonprogrammierer bedarf der Begriff "gebunden Methode" vielleicht noch einer Erl舫terung. Ein Methodenaufruf sieht in Python sehr 臧nlich aus wie in Java oder C++:

	  objekt.methode(arg1, arg2)
	

Bei der Ausfhrung dieses Methodenaufrufs wertet Python zun臘hst den Ausdruck objekt.methode aus. Das liefert, wenn "methode" tats臘hlich der Name einer Methode des Objekts objekt ist, ein gebundenes Methodenobjekt. Ein solches Objekt enth舁t 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舁t, 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 dafr, 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舅dig ist, wie hier im Falle von Thuban, wo hinter einer Karte viele Megabytes an Daten stehen knen, ist es wichtig, das Zeichnen etwas aufzuschieben, bis das Programm wieder auf Ereignisse des Fenstersystems wartet. Die meisten Toolkits bieten hierfr sogenannt Idle-Events an.