2012-03-03

Ultimate Swing, Teil 20

Sicher erinnern Sie sich noch, dass eines der Ziele meiner losen Folge von Artikeln zu Swing eine “sexy” aussehende Anwendung war. Obwohl wir noch nicht einmal ansatzweise alle technischen Aspekte der Swing-Programmierung hinter uns haben, möchte ich doch ab sofort den einen oder anderen Post zur Gestaltung einfließen lassen.

Warum muss ein Programm eigentlich “sexy” aussehen. Oder, anders formuliert, warum wirken manche Programme optisch ansprechend, andere hingegen nicht? Vor allem aber: warum sehen Programme eigentlich überhaupt unterschiedlich aus? Kaum ein Benutzer wird sich Gedanken darüber machen, dass die Bedienelemente einer Anwendung baumartige Strukturen darstellen. Er nimmt sehr wohl zusammengehörende Bereiche war – Menüleiste, Toolbar, Paletten. Dass sie in einen Rahmen (das Hauptfenster) eingebettet sind, interessiert ihn aber nicht. Wichtig ist, dass die Elemente an Stellen sind, an denen er sie vermutet oder erwartet. Aktuelle Betriebssysteme und GUI-Toolkits bilden die Hierarchiebeziehungen zwischen Bedienelementen zur Laufzeit als Baumstrukturen in Form von Objektgraphen ab. Das bedeutet aber nicht, dass Objektorientierung eine zwingende Voraussetzung für grafische Benutzeroberflächen ist. Ältere Systeme (als ein Beispiel von vielen sei GEM, der Graphics Environment Manager von Digital Research genannt) nutzen hierfür zu Bäumen verbundene Datenstrukturen.

Zurück zur Erwartungshaltung der Anwender: Es mag zunächst wie eine Binsenweisheit klingen, dass man mit vertrauten Dingen sicherer und schneller zurecht kommt, als mit Neuem und Ungewohnten. Gerade beim Bau von Benutzeroberflächen hat aber kaum ein System dies von Beginn an so konsequent umgesetzt, wie der Mac. Die Human Interface Guidelines legen seit mehreren Jahrzenten detailliert fest, wie Programme für den Mac auszusehen haben, wann wofür welche Bezeichnung verwendet wird und was wie zu funktionieren hat. Der Lohn der Mühe ist: einheitliches Aussehen, einheitliche Bedienung, schnelle Einarbeitungszeiten, hohe Konsistenz.

Diesen Grad an Uniformität konnte oder wollte die Windws-Welt bis heute nicht erreichen. Das mag daran liegen, dass Microsoft selbst im Laufe der Zeit einen Zoo an GUI-Klassenbibliotheken geschaffen hat, ohne umfassend aufzuräumen. Da gibt es die klassischen Win32-Controls, dann kamen die “common controls” dazu, später (mit .NET) Windows Forms und Windows Presentation Foundation. Zahlreiche Drittanbieter trugen zu weiterer Vielfalt bei. Als ein Beispiel von Vielen sei die VCL (Visual Component Library) von Borland genannt. Es hätte einen Aufschrei gegeben, wäre Microsoft Apples Vorbild gefolgt und hätte versucht, den Entwicklern das eigene GUI-Toolkit aufzuzwingen.

Jetzt zu Java… Die erste GUI-Komponentenbibliothek (AWT, Abstract Window Toolkit) nutzte native Komponenten. Was zunächst wie ein Vorteil klingt, entpuppte sich schnell als Problem. Da AWT nur Funktionen anbot, die auf allen Mitte der Neunziger verfügbaren Systemen (auf denen Java lief) vorhanden waren, erschienen AWT-basierte Bedienoberflächen spartanisch. Die Schnittmenge von Windows, MacOS und Motif ist einfach nicht sehr groß. Man schuf deshalb mit Swing eine Komponentenbibliothek, die aus so genannten leichtgewichtigen Komponenten bestand. Für das Zeichnen war Swing selbst verantwortlich. Leider hat auch dieser Ansatz Nachteile:

  • um wie native Komponenten auszusehen, muss man diese imitieren – heute wissen wir, dass das nie funktioniert hat
  • damalige Systeme waren langsam – und so hat sich Swing zunächst auch angefühlt

Das Aussehen und (in Grenzen) das Verhalten von Swing-Komponenten wird durch das so genannte Look and Fell bestimmt. Die Architektur von Swing sieht vor, dass nach Belieben Look and Feels hinzugefügt werden können. Sun hat im Laufe der zeit selbst rege Gebrauch davon gemacht.

No comments:

Post a Comment