15.3 Komponenten im AWT und in Swing

Obwohl das Abstract Window Toolkit das Problem einer einheitlichen Benutzeroberfläche lösen sollte, ist dies bei Sun nicht ganz gelungen. Das AWT war von Anfang an zusammengepfuscht. So meint auch James Gosling: »The AWT was something we put together in six weeks to run on as many platforms as we could, and its goal was really just to work. So we came out with this very simple, lowest-common-denominator thing that actually worked quite well. But we knew at the time we were doing it that it was really limited. After that was out, we started doing the Swing thing, and that involved working with Netscape and IBM and folks from all over the place.«¹

Doch Sun machte sich mit dem AWT noch mehr Probleme. Da es von Anfang an ungenügend durchdacht war, führten die Entwickler von AWT 1.02 auf AWT 1.1 ein anderes Ereignismodell ein. So kostete die Anpassung von komplexen Programmen an das neue Modell einen erheblichen Programmieraufwand - und nicht alle Firmen gingen darauf ein.²

Da Sun das AWT einfach gehalten hat, aber Entwickler von Oberflächen einen nicht zu stillenden Hunger nach Komponenten haben, konzipierte Netscape kurzerhand die Internet Foundation Classes (IFC), die das AWT in wesentlichen Punkten ergänzen. Auch Microsoft mischt durch Erweiterungen mit. Die Firma bietet die Application Foundation Class (AFC) an, die aber heute keine Rolle mehr spielt.

Im April des Jahres 1997 haben sich Sun, Netscape und IBM auf eine GUI-Bibliothek geeinigt, die auf Netscapes IFC aufbaut und das AWT in der Java-Version 1.2 erweitert. (Für 1.1.x lässt sich die Bibliothek von den Sun-Seiten laden.) Der Name des Toolkits ist JFC (Java Foundation Classes). Ein Teil der JFC sind neue Komponenten, die so genannten Swing-Komponenten. Obwohl Swing mehr ist als die neuen grafischen Elemente, ist Swing zu einem Synonym für die JFC geworden. Als 1997 in San Francisco auf der JavaOne die neuen Komponenten vorgestellt wurden, entschied sich Georges Saab, ein Mitglied des JFC-Teams, für Musik parallel zur Präsentation. Dies war gerade Swing-Musik, denn der Entwickler glaubte, dass sie wieder in Mode käme. So wurden auch die neuen grafischen Elemente im Paket mit dem Namen Swing abgelegt. Obwohl der Name offiziell dem Kürzel JFC weichen musste, war er doch so populär, dass er weiter bestehen blieb.

15.3.1 Peer-Klassen und Lightweight-Komponenten

Die ursprüngliche AWT-Implementierung benötigt so genannte Peer-Klassen, die als native Funktionen auf der speziellen Benutzeroberfläche implementiert sind. Unter X11 sehen wir auf Motif 2.0 basierende Komponenten und auf Windows entsprechend andere. Eine Schaltfläche unter AWT kennt dann einen Partner auf der Betriebssystemseite, der die Visualisierung vornimmt. Die Partner haben Vor- und Nachteile:

Der Vorteil ist, dass durch die nativen Peer-Klassen die Oberfläche schnell wird und der Speicherverbrauch sich im Rahmen hält.

Leider zeigen die Programme unter den verschiedenen Betriebssystemen bisweilen merkwürdige Seiteneffekte. So kann ein Textfeld unter Windows weniger als 64K Zeichen aufnehmen, bei anderen Oberflächen ist dies egal. Da das AWT auch nur Komponenten anbietet, die auf jeder Plattform verfügbar sind, ist das Angebot an Widgets sehr beschränkt. Moderne grafische Elemente, sei es auch nur ein Icon auf einer Schaltfläche, sind vom AWT nicht vorgesehen.

Eine Leichtgewicht-Komponente (engl. lightweight component) besitzt keinen Peer, also keine direkte Repräsentation im Fenstersystem. Somit gibt es keine speziellen Implementierungen des Systems auf beispielsweise Windows, MacOS oder X11. Dieser Weg ist also plattformunabhängiger, aber leider auch langsamer. Alle Komponenten werden mit primitiven Zeichenoperationen gemalt, so etwa eine Schaltfläche aus einem Rechteck mit Schatten und einem Text in der Mitte. Der Vorteil: Eine Leichtgewicht-Komponente kann durchsichtig sein und muss nicht mehr in einen rechteckigen Bereich passen. Da alle Komponenten nun gemalt werden, lässt sich alles ohne Rücksicht auf das unterliegende grafische System zeichnen.

15.3.2 Die Basis aller Komponenten: Component und JComponent

Die Klasse Component bildet die Basisklasse der Objekte, die als grafische AWT-Komponenten auf den Schirm kommen. Sie wird für Swing-Komponenten noch einmal zu JComponent erweitert. Allerdings leitet JComponent nicht direkt von Component ab, sondern erst von Container (und Container dann direkt von Component). Das hat die Konsequenz, dass jedes JComponent automatisch auch ein Container ist.

Ein Component- und JComponent-Objekt verarbeitet schon eine ganze Reihe von Ereignissen, die allen anderen Komponenten zugute kommen.

Die Position der Komponente

Der Klasse Component gehört eine ganz nützliche Funktion an, um die absolute Position der Komponente auf dem Bildschirm zu ermitteln. Diese Funktion ist besonders dann praktisch, wenn die Position eines Fensters gefragt ist.

abstract class java.awt.Component
implements ImageObserver, MenuContainer, Serializable

Point getLocationOnScreen() Liefert die Position der linken oberen Ecke der Komponente als Punkt-Objekt.

Die Arbeitsweise von getLocationOnScreen() ist einfach: Gehe mit der getParent()-Methode so lange zurück, bis wir zu einem Exemplar von Frame kommen.

Component c = this;
while ( (c = c.getParent()) != null )
  if ( c instanceof JFrame )
    break;
if ( c != null )
{
   Point p = (Frame)c.getLocation();
   x += p.x;
   y += p.y;
}

15.3.3 Proportionales Vergrößern eines Fensters

Die Schnittstelle ComponentListener ist Basis für alle Komponenten, die Ereignisse empfangen. Sie definiert vier Methoden, die in der Klasse ComponentAdapter wieder mit leerem Programmblock gefüllt sind.

Hier klicken, um das Bild zu Vergrößern

interface java.awt.event.ComponentListener
extends EventListener

void componentHidden( ComponentEvent e ) Wenn die Komponente versteckt wurde.

void componentMoved( ComponentEvent e ) Wenn die Komponente bewegt wurde.

void componentResized( ComponentEvent e ) Wenn die Komponente in der Größe verändert wurde.

void componentShown( ComponentEvent e ) Wenn die Komponente gezeigt wurde.

Wenn wir auf die Größenveränderung eines Fensters achten wollen, so müssen wir mit addComponentListener() einen Listener an das Fenster hängen, der auf die Veränderung reagiert. Wir implementieren eine Klasse, die sich von ComponentAdapter ableitet - die restlichen drei Methoden müssen auf diese Weise nicht mit leeren Rümpfen gefüllt werden - und überschreiben componentResized(). Wenn wir nur das Frame-Objekt als Ereignishorcher mit dem ComponentListener verbinden, ist klar, wer der Auslöser war. Mit getComponent() auf dem Ereignisobjekt bekommen wir genau diesen Frame. Nun ist es Sache des Algorithmus, wie mit der Größenveränderung zu verfahren ist. Eine Möglichkeit ist, die aktuelle Größe mittels getSize() auszulesen und dann das Minimum aus Höhe und Breite wieder mit setSize() zu setzen. Folgendes Programm macht genau dies:

Listing 15.5 ResizeTheFrame.java

import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
public class ResizeTheFrame extends JFrame
{
  public ResizeTheFrame()
  {
    setSize( 200, 200 );
    setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
    show();
  }
  public static void main( String args[] )
  {
    new ResizeTheFrame().addComponentListener( new ResizeEvent() );
  }
  static class ResizeEvent extends ComponentAdapter
  {
    public void componentResized( ComponentEvent event )
    {
      if ( event.getID() == ComponentEvent.COMPONENT_RESIZED )
      {
        JFrame f = (JFrame) event.getComponent();
        Dimension d = f.getSize();
        int size = Math.min( d.width, d.height );
        f.setSize( size, size );
      }
    }
  }
}

Wenn die Größenveränderung beginnt, haben wir keinen Einfluss mehr auf den Prozess. Hier unterscheiden sich die Betriebssysteme. Unter Windows wird nicht bei jeder Pixeländerung ein Ereignis ausgelöst, sondern nur am Ende einer Größenänderung. Bei Linux werden während der Bewegung Ereignisse ausgelöst, so dass eine flüssige Bewegung entsteht.

15.3.4 Dynamisches Layout während einer Größenänderung

Wird ein Fenster vergrößert, dann kann während der Größenänderung der Inhalt sofort neu ausgerichtet und gezeichnet werden oder auch nicht. Wird er nicht dynamisch angepasst, dann sieht der Benutzer diese Anpassung erst nach dem Loslassen der Maus, wenn die Größenänderung abgeschlossen wurde. Dieses dynamische Vergrößern lässt sich seit 1.4 im Toolkit-Objekt einstellen. Dazu dient die Methode setDynamicLayout(boolean dynamic). Abfragen lassen sich mit isDynamicLayoutSet() und isDynamicLayoutActive() vornehmen.

15.3.5 Hinzufügen von Komponenten

Ein Container nimmt Komponenten auf und setzt sie mit Hilfe eines Layoutmanagers in die richtige Position. Die Container werden in Java über die Klasse Container verwaltet. Ein Container, den wir schon kennen gelernt haben, ist Frame. Komponenten werden mit Hilfe der add()-Methode einem Container hinzugefügt.

Hier klicken, um das Bild zu Vergrößern

Abbildung 15.1 AWT-Container

Hier klicken, um das Bild zu Vergrößern

Abbildung 15.2 Ein Container kann sich selbst aufnehmen.

Da Container selbst ein Component ist, können auch Container wiederum Container aufnehmen. Das ist ein bekanntes Design-Pattern und nennt sich Composite Pattern.

¹ So lässt sich das im Interview vom 24. März 1998 unter>http://java.sun.com/javaone/javaone98/keynotes/gosling/transcript_gosling.html nachlesen.

² Wir haben uns in den vorangegangenen Abschnitten auch gar nicht mit dem älteren Ereignismodell beschäftigt. Damals wurden alle Ereignisse eines Fensters an einer Stelle gesammelt und ausgewertet. Das führte zu einer Riesenmethode, die die Typen der Ereignisse testete und dann weitervermittelte.