Kleine Einführung in Tk (unfertige Arbeitsversion)

Transkript

1 Kleine Einführung in Tk (unfertige Arbeitsversion) Inhaltsverzeichnis 1 Warum Tk? 3 2 Aufruf Ausführbare Dateien erzeugen Interpreter interaktiv aufrufen Ablauf grafischer Programme Syntax Kommandos für GUI-Elemente Mini-Beispielprogramm Ein weiteres kleines Beispielprogramm Widgets Liste aller Standard-Widgets Frames Eingabefelder Einzeilige Eingabefelder Mehrzeilige Eingabefelder Auswahlfelder Radiobuttons Checkbuttons Gemischte Felder Combobox Grundlegende Bildschirm-Anordnung Die Geometry-Manager Der Geometry-Manager pack Der Geometry-Manager grid Layout-Beispiele

2 INHALTSVERZEICHNIS INHALTSVERZEICHNIS Layout-Beispiele mit pack Layout-Beispiele mit pack und Frames Layout-Beispiel mit grid Anbindung von Code an Widgets Spezielle Anbindungen Verwenden von -command (unfertige Arbeitsversion) 2

3 2 AUFRUF 1 Warum Tk? Die Frage müsste eigentlich heißen Warum Tcl?. Diese Frage wird in Kleine Einführung in Tcl bereits beantwortet. Wer sich aufgrund der Argumentation dann für Tcl als Scriptsprache entschieden hat, bekommt Tk, das grafische Toolkit zum Schreiben von plattformübergreifenden Programmen mit grafischen Oberflächen, quasi dazu. Es wird übrigens auch aus Perl- und Pythonprogrammen verwendet, weil diese Sprachen keine eigenen grafischen Toolkits haben. Im folgenden wird von soliden Grundkenntnissen in Tcl ausgegangen. Zum Erwerb diese Grundkenntnisse eignet sich beispielsweise die Kleine Einführung in Tcl. Dort ist auch beschrieben, wie man an Tcl/Tk kommt. 2 Aufruf 2.1 Ausführbare Dateien erzeugen Unter dem Namen tclsh kann man die textorientierte Tcl-Shell aufrufen, mit wish bekommt man die Windowing Shell mit der grafischen Oberfläche. In UNIX-Scripts baut man den Aufruf von wish am besten so ein: #!/bin/sh # Aufruf von wish \ exec wish $0 "$@" # Es folgt der Tcl/Tk-Code Dieser Kopf aller Tcl/Tk-Programme wird im folgenden nicht mehr bei den Beispielen wiederholt, sondern ist genauso selbstverständlich wie die Notwendigkeit, die Datei ausführbar zu machen mit chmod. Bei Windows werden bei der Installation alle Dateien mit der Endung.tcl sowieso mit wish assoziiert, so dass man sie im Explorer doppelklicken kann. Beim Mac muss man den Interpreter kopieren und das Script in der Resource Fork unterbringen. Näheres dazu bitte in den Originalunterlagen nachlesen, z. B. in Practical Programming in Tcl and Tk von Brent Welch, Second Edition, Seite Interpreter interaktiv aufrufen Den Interpreter wish kann man auch interaktiv aufrufen und dann mittels des source-kommandos ein Script aufrufen und ausführen. Dabei öffnet sich sofort ein kleines grafisches Fenster, während in der Shell Kommandos eingegeben werden können, die sich dann auch unmittelbar auf die grafische Oberfläche auswirken können. In Windows wird eine separate Text-Shell neben dem grafischen Fenster geöffnet, während bei Unix das Aufruf-Terminalfenster weiter verwendet wird. (unfertige Arbeitsversion) 3

4 2.3 Ablauf grafischer Programme 3 SYNTAX 2.3 Ablauf grafischer Programme Es gibt einen grundsätzlichen Unterschied zwischen gewöhnlichen, prozeduralen Programmen mit Textoberfläche und Applikationen mit grafischer Oberfläche: Programme mit Textoberfläche beginnen und enden mit dem Ablauf des Hauptprogramms (in C/C++ ist das die main()- Funktion, in Tcl der Code außerhalb von Prozeduren). Beim Verlassen des Hauptprogramms ist der Prozess zu Ende. Bei grafischen Programmen baut der Code des Hauptprogramms dagegen lediglich die grafische Oberfläche auf. Danach ist der Prozess aber nicht zu Ende, sondern geht in eine Schleife, innerhalb derer Ereignisse verarbeiten werden. Daher werden diese Programm auch ereignisgesteuert (event-driven) genannt. Ereignisse sind typischerweise Maus- und Tastatureingaben, wobei auch schon das Bewegen des Mauszeigers als Ereignis gilt, nicht erst das Anklicken von Elementen. Ein grafisches Programm wird erst dann beendet, wenn ein Ereignis die Programm-Beendigungsroutine aufruft (Kommando exit in Tcl. Damit dies funktionieren kann, werden den GUI-Elementen Ereignis-Behandlungsfunktionen (event handlers) hinterlegt. Damit wird festgelegt, was passieren soll, wenn ein GUI-Element von einem bestimmten Ereignis ereilt wird. Oft wird dem Aufruf einer solchen Funktion dann noch Zusatzinformation mitgegeben, beispielsweise die Mausposition. Viele Prozeduren werden also gar nicht vom Hauptprogramm aufgerufen, sondern nur als Event Handlers für bestimmte Ereignisse registriert. Erst bei Eintreten des Ereignisses laufen die Prozeduren dann ab. Daher ist auch nicht vorhersehbar, wann welche Prozedur abläuft. Dies verlangt besondere Umsicht beim Programmieren, damit der Zustand der Datenstrukturen immer konsistent bleibt. Dem Programmieren mit grafischen Oberflächen kommt das objektorientierte Programmieren besonders entgegen, weshalb sie besonders gerne mit Sprachen wie C++ oder Java erstellt werden. Tcl/Tk ist allerdings auch in gewissem Maße objektorientiert, was die grafische Programmierung angeht. Für volle Objektorientierung kann man [incr Tcl] 1 oder stooop 2 verwenden. 3 Syntax Beim Arbeiten mit Tcl/Tk steht einem die gesamte Syntax von Tcl zur Verfügung hinzu kommen die ganzen GUI 3 -Elemente von Tk. Diese sehen nicht auf allen Plattformen völlig identisch aus, weil der Ansatz des native look and feel verfolgt wird, d. h. die Programme sollen unter X aussehen wie ein X-Programm, auf einem Mac wie ein Mac-Programm und unter Windows wie ein Windows-Programm. Ähnliches verfolgt Sun seit Java 1.2 mit den Swing-Klassen. Daher hat bei Windows und X ein Tk-Programm ein Menü im Applikationsfenster; auf dem Mac dagegen 1 siehe 2 siehe 3 GUI = graphical user interface (unfertige Arbeitsversion) 4

5 3 SYNTAX 3.1 Kommandos für GUI-Elemente befindet sich das Menü immer am oberen Bildschirmrand völlig losgelöst vom Applikationsfenster. Die Syntax von Tk-Kommandos ist vom Prinzip her mit den Tcl-Kommandos identisch, aber natürlich gibt es eine ganze Reihe völlig neuer Kommandos. 3.1 Kommandos für GUI-Elemente Die GUI-Elemente, ab jetzt Widgets genannt, sind in Klassen eingeteilt, z. B. Textfelder, Labels (Beschriftungen), Checkbuttons, Knöpfe (Schaltflächen), Scrollbars usw. Für jede Klasse gibt es ein gleichnamiges Kommando, das ein solches Widget erstellt. Im Zuge der Weiterentwicklung von Tcl/Tk und auch durch Zusatzpakete können weitere Widget-Klassen und -Kommandos hinzukommen. Näheres hierzu siehe Abschnitt 4 auf Seite 7. Beim Erzeugen eines Widgets gibt man dem Kommando einen Pfad mit, der vom Hauptfenster (Toplevel Window) bis hin zum eigentlichen Widget-Namen führt. Hier liegt eine Hierarchie wie in einem Verzeichnisbaum vor. Als Verzeichnisse fungieren hier sogenannte Container- Widgets; andere können nur Blätter im Baum sein analog gewöhnlichen Dateien in einem Verzeichnisbaum. Der Rückgabewert des Kommandos ist genau dieser Pfad, denn der identifiziert das Widget eindeutig. Oft weist man den einer Variablen zu, um anschließend diese zu verwenden. Dadurch kann man leicht einen ganzen Teilbaum in der Hierarchie umhängen ähnlich wie ein mv-kommando auf ein Verzeichnis angewendet werden kann. Das kann nötig werden, wenn man ein Programm weiterentwickelt und eine neue Hierarchie-Ebene einfügen möchte, um das Bildschirm-Layout zu ändern. Es gelten einige weitere feste Regeln, an die man sich erst etwas gewöhnen muss: 1. Widgets sind eigene kleine Fenster. 2. Widgets müssen explizit auf dem Bildschirm platziert werden, sonst erscheinen sie nicht. 3. Ein Widget wird mit einem Kommando erzeugt, das einen Bezeichner für dieses Element zurückliefert. Der Bezeichner ist ein neues Kommando, mit dessen Hilfe später auf das Widget zurückgegriffen werden kann. 4. Einige Widgets sogenannte Container-Widgets können andere Elemente enthalten. Hierzu gehören Frames und Canvases. 5. Widgets tragen Namen, die mit einem Punkt beginnen. Diejenigen auf der obersten Ebene haben einen einfachen Namen. Sind sie in einem anderen Widget enthalten, der sich wiederum auf der obersten Ebene befindet, so setzt sich der Gesamtname aus einem Punkt, dem Namen des Container-Widgets, einem weiteren Punkt und dem Namen des Widgets zusammen. Ähnlich wie sich Dateien in einem Verzeichnis befinden können, können sich Widgets in einem Container-Widget befinden. Während bei Verzeichnissen ein Schrägstrich (bzw. ein Backslash bei Windows, ein Doppelpunkt bei Macintosh) als Trennzeichen verwendet wird, ist es bei Widgets der Punkt. (unfertige Arbeitsversion) 5

6 3.2 Mini-Beispielprogramm 3 SYNTAX 6. Das bei der Erzeugung zurückgelieferte neue Kommando wird mit entsprechenden Optionen verwendet, um etwas mit dem Widget zu tun, z. B. seine Konfiguration zu ändern, es sichtbar oder unsichtbar zu machen oder auch wieder zu löschen. 3.2 Mini-Beispielprogramm Hier ein supersimples Beispielprogramm: set b [button.b -text "Klick"] pack $b $b configure -command {exit} Im ersten Kommando wird der Variablen b der Rückgabewert des Aufrufs von button zugewiesen. Das button-kommando benötigt eine zwingenden Parameter, nämlich den Fensternamen, hier.b. Weitere Optionen sind benannt und beginnen mit einem Bindestrich und haben oft noch eine weitere Angabe, hier -text "Klick". Das legt den auf dem Button (Knopf) erscheinenden Text fest, nämlich Klick. Sichtbar ist noch nichts, aber der Knopf ist definiert. Mittels des pack-kommandos erscheint er auf dem Bildschirm. Ein Klicken darauf bewirkt aber nichts. Wir hätten es schon bei der Erzeugung mitgeben können, konfigurieren es jetzt aber nachträglich, indem wir das neue Kommando $b mit dem Zusatz configure aufrufen und dahinter die neue Konfiguration angeben. Wir möchten das Kommando ändern (war bisher leer), das beim Anklicken ausgeführt wird. Dieses Kommando lautet exit. Es wird also dem Widget-Objekt, das zu einem neuen Kommando wurde, die Nachricht geschickt, es möge doch bitte exit ausführen, wenn es einen Klick der linken Maustaste erhält. Wenn man nun auf den Button klickt, wird wish mittels des Kommandos exit beendet, also verschwindet die gesamte Applikation. Geben Sie die drei Zeilen hintereinander in eine manuell aufgerufene wish ein und beobachten Sie, was sich im grafischen Fenster tut. Klicken Sie dann auf die Schaltfläche. Was passiert mit der Windowing Shell, die als Eingabezeile dient? 3.3 Ein weiteres kleines Beispielprogramm Hier ein weiteres kleiners Beispielprogramm: pack [button.knopf1 -text "OK" -command { tk_messagebox -icon info -type ok -title "Begrüßung" \ -message "Hallo $name" }] -side bottom pack [label.label1 -text "Name: "] -side left pack [entry.feld1 -width 15 -variable name] (unfertige Arbeitsversion) 6

7 4 WIDGETS Hier sind Kommandos geschachtelt, d. h. es wird jeweils der Rückgabewert von button, label und entry unmittelbar an pack weitergegeben. button richtet einen Knopf ein, der mit OK beschriftet wird und der bei einem Standard-Klick (also Mausknopf 1 üblicherweise links) das Kommando ausführt, das in der geschweiften Klammer hinter -command steht. Dies öffnet eine standardisierte Message-Box von Tk, mit der der Anwender begrüßt wird. Der Knopf wird im Fenster unten angeordnet. label erzeugt eine Beschriftung Name:, die anschließend mit pack links angeordnet wird. Das mit entry erzeugte Eingabefeld mit 15 Zeichen kommt dann rechts daneben. Diesem Eingabefeld wird die Variable name zugeordnet, die auch oben im tk_messagebox-kommando verwendet wird. Diese Art der Verwendung globaler Variablen gilt in grafischen Programmen als normal. Zum Beenden des Programms muss man den Standard-Schließen-Knopf oder das System- Menü des Fenstermanagers verwenden. 4 Widgets Tk enthält eine ganze Reihe von Widgets. Für jede Widget-Klasse gibt es ein gleichnamiges Kommando, das ein solches Widget erzeugt. In Tabelle 1 sind die Standard-Widgets aufgeführt und erläutert. 4.1 Liste aller Standard-Widgets Widgetname Beschreibung Tabelle 1: Tk-Standard-Widgets Button Label Entry Knopf oder auch Schaltfläche genannt. Kann meist mit der linken Maustast angeklickt werden. Wenn der Button mit der Tab-Taste ausgewählt wurde, kann man ihn durch Drücken der Leertaste auslösen, was eine Programmbedienung auch ohne Maus möglich macht. Buttons können mit Text beschriftet sein oder ein Bild enthalten. Ein Label ist ein angezeigter Text, meist als Beschriftung anderer Widgets. Ein Label kann an eine Variable angebunden werden, so dass jede Änderung des Variableninhalts sofort sichtbar wird, wenn der Bildschirm aktualisiert wird. Ein einzeiliges Eingabefeld. Es kann aktiv sein, so dass man etwas eingeben kann, oder aber inaktiv, so dass es nur zur Anzeige dient. Zwischen diesen beiden Status kann man hin- und herschalten. (unfertige Arbeitsversion) 7

8 4.1 Liste aller Standard-Widgets 4 WIDGETS Widgetname Beschreibung Text Ein Textfeld enthält mehrere Textzeilen. Tatsächlich ist das Text-Widget von Tk extrem leistungsfähig, weil man andere Widgets einbetten kann, ein Zeilenumbruch stattfinden kann, Text verschiedene Schriftarten und -größen haben kann usw. usf. Das Text-Widget macht einen sehr großen Anteil des gesamten Codes von Tk aus. Radiobutton Unter Windows sind Radiobuttons meist rund, bei X-Window gelegentlich auch eckig, aber sie stehen auf der Spitze, d. h. sind im Vergleich zu Checkbutton um 45 gedreht. Aus einer Gruppe von Radiobuttons kann immer nur einer ausgewählt werden. Das ist beispielsweise bei der Absatzformatierung sinnvoll: Ein Absatz kann nur links- oder rechtsbündig, auf Block ausgetrieben oder zentriert sein, aber nicht mehreres gleichzeitig. Checkbutton Checkbuttons sind ähnlich Radiobuttons, nur dass man aus einer Gruppe auch mehrere gleichzeitig auswählen kann. Das ist beispielsweise bei Textauszeichnungen sinnvoll: Fett und kursiv sind auch gleichzeitig möglich. Frame Frames dienen als Container für andere Widgets, sind selbst aber unsichtbar, solange sie keinen Rand haben. Mit ihnen kann man eine grafische Oberfläche schön gliedern. Solange man ihnen keine Größe zuweist, sind sie automatisch immer gerade groß genug, um ihren Inhalt (andere Widgets) darstellen zu können d. h. sie passen sich an die Notwendigkeiten an. Canvas Ein Canvas dient auch als Container, aber auf ihm platziert man andere Widgets wie auf einer Leinwand daher der Name (canvas=leinwand). Auf einem Canvas kann man auch geometrische Figuren zeichnen. Den Inhalt eines Canvas kann man im EPS-Format exportieren, so dass die Toplevel Ergebnisse leicht weiterverarbeitet werden können. Ein Toplevel ist ein neues Hauptfenster, z. B. um Dialogboxen oder aufleuchtende, vom Applikationsfenster unabhängige Fenster zu erzeugen. Auch Dialogboxen sind eigene Toplevel-Fenster. Toplevel deshalb, weil sie nicht in anderen Widgets enthalten sind, sondern direkt auf der Fensteroberfläche liegen, also auf der obersten Ebene (=top level). MessageBox Message-Boxen sind Meldungsfenster, die man mit ja/nein oder ok/abbrechen beantworten muss. Dafür gibt es einfache Prozeduraufrufe, so dass man sie nicht selbst zusammenbauen muss (tk_messagebox). Image Mit Image kann man Bilder laden. Durch entsprechende Zusatzpackages sind viele Bildformate verwendbar. Das geht aber über diese kleine Einführung in Tk hinaus. (unfertige Arbeitsversion) 8

9 4 WIDGETS 4.2 Frames Widgetname Beschreibung Scrollbar Sind Widgets (insbesondere Text- und Bild-Widgets oder Tabellen) größer als der verfügbare Platz, so muss man Scrollbars verwenden, um den gesamten Inhalt sichbar machen zu können. Sie müssen an das entsprechende Widget (oft Frame oder Canvas) mittels Kommandos angebunden werden, damit das Scrolling einwandfrei klappt. Scrollbars können horizontal oder vertikal sein. Darüber hinaus gibt es noch viele weitere Widgets, zum Teil in Erweiterungen wie in dem in reinem Tcl geschriebenen BWidget Toolkit 4 oder dem in C geschriebenen Kit [incr Widgets] 5, um nur zwei Beispiele zu nennen. 4.2 Frames Frames sind einfache Rahmen, die zur Aufteilung des Platzes und zur Gruppierung anderer Widgets, d. h. Gestaltung des Bildschirms dienen können, ohne selbst Platz einzunehmen oder als solches überhaupt sichtbar zu werden. Wenn sie eine Umrandung haben, wird diese allerdings sichtbar. Sie gehören zu den sogenannten Container-Widgets, weil sie andere Widgets enthalten können natürlich auch andere Frames oder andere Container-Widgets wie Canvases. Möchte man mehr als ganz einfache Bildschirm-Layouts mittels des Geometry Managers pack (siehe Abschnitt 5.1 auf Seite 11) machen, muss man meist mehrere Frames ineinander schachteln (siehe Abschnitt auf Seite 14). 4.3 Eingabefelder Einzeilige Eingabefelder Mehrzeilige Eingabefelder Auswahlfelder Radiobuttons Checkbuttons... 4 Bestandteil der TclLib, 5 Bestandteil von [incr Tcl], (unfertige Arbeitsversion) 9

10 4.5 Gemischte Felder Combobox 5 GRUNDLEGENDE BILDSCHIRM-ANORDNUNG 4.5 Gemischte Felder Combobox Diese gehört nicht zu den Standard-Widgets, sondern wird über Zusatzpakete zur Verfügung gestellt, z. B. über BWidget 6 oder Brian Oakleys Version 7 Daher wird es hier nicht weiter besprochen, sondern nur ein Screenshot gezeigt. 5 Grundlegende Bildschirm-Anordnung Die Anordnung der einzelnen Widgets am Bildschirm geschieht in vielen Entwicklungssystemen interaktiv am Bildschirm. So etwas gibt es auch für Tk (Visual Tcl 8 ), aber es ist wesentlich besser, so etwas nicht zu benutzen. Nachteil dieser Screen Designer ist die geringe Flexibilität bei Änderungen und oft unglückliche Benennung von Elementen. Zudem werden die Layouts oft pixelgenau vorgenommen und können sich daher nicht an verschiedene Fenster- und Bildschirmgrößen anpassen. Der Riesenvorteil von Tk-Applikationen ist aber, dass man einen gewissen Programmieraufwand vorausgesetzt eine gute Anpassung an wechselnde Bildschirmauflösungen und Fenstergrößen haben kann. Bei einfachen Programmen kann man die Veränderung der Fenstergröße durch den Anwender unterdrücken, aber wenn sie Beschriftungen (z. B. durch Übersetzung in eine andere Sprache) ändern, hat man mit pixelgenauem Layout schon verloren. Tk ist in der Lage, die Größe aller Elemente an die Notwendigkeiten anzupassen, wobei man trotzdem die Kontrolle behält sogar besser! Man muss sich um viel weniger kümmern und hat trotzdem immer ein ordentliches Layout. 5.1 Die Geometry-Manager Die Anordnung der Widgets untersteht den diversen Geometry-Managern von Tk. Es gibt mehrere davon, weil es unterschiedliche Ansprüche an die Gestaltung von Bildschirmen gibt. Glücklicherweise kann man die Verwendung sogar in einem einzigen Programm mischen! In jedem 6 Bestandteil der TclLib, oakley/tcl/combobox/index.html 8 (unfertige Arbeitsversion) 10

11 5 GRUNDLEGENDE BILDSCHIRM-ANORDNUNG 5.2 Der Geometry-Manager pack Frame kann man einen anderen Manager verwenden. Das macht die Programmierung so einfach und übersichtlich! Allerdings muss angemerkt werden, dass das Verhalten des Programms unvorhersagbar wird, sobald man versuchen sollte, in einem einzigen Frame mehrere Geometry- Manager zu verwenden. Da gibt es auch keine Fehlermeldung! Hier werden die Geometry-Manager pack und grid erläutert, weil diese für die meisten Anwendungen verwendet werden und ausreichen. Der Geometry-Manager place ist in den meisten Fällen wenig hilfreich, weil sich bei ihm die Elemente nicht bei Bedarf neu anordnen oder in der Größe anpassen können. 5.2 Der Geometry-Manager pack pack ist der einfachste Geometry Manager. Man muss sich ein bisschen Zeit nehmen, um seine Mechanismen zu verstehen, aber dann nimmt er einem viel Arbeit ab. Ein erzeugtes Widget kann man dem Kommando pack als Parameter übergeben, woraufhin es auf dem Bildschirm angezeigt wird. Aber wie wird es angeordnet? Im aktuellen Frame wird das Element in die noch verbleibende Lücke gepackt. Ohne Optionen wird es in der Lücke an der Oberseite angebracht, so dass unter ihm wiederum eine Lücke verbleibt. Würde man es an die linke Seite packen, bliebe rechts eine neue Lücke also immer genau gegenüber. Möchte man also zwei Knöpfe übereinander packen, so schreibt man: pack $button1 pack $button2 pack hat diverse Optionen. Hier sollen die wichtigsten erläutert werden: -side Anordnungsseite in der Lücke. Als Wert für diese Option kann angegeben werden: left right top bottom. Default ist top. Auf der jeweils gegenüberliegenden Seite lässt das Widget dann Platz für weitere Widgets. -anchor Wenn der Platz größer ist als das Widget, wo soll es dann angeordnet werden? Mögliche Werte: n e s w ne nw se sw, die Abkürzungen für die Himmelsrichtungen north, east, south, west, northeast, northwest, southeast und southwest sind. Default ist, es zu zentrieren. -before und -after Möchte man das Widget nicht in die aktuelle Lücke, sondern in der Pack-Reihenfolge vor oder hinter ein bereits gepacktes Element anordnen, so gibt man Namen des Bezugselements hinter einer dieser Optionen an. -expand Diese Option braucht einen logischen Wert (0 oder 1 bzw. yes oder no), um das Expandieren ein- oder auszuschalten. Falls neben einem Widget noch freier, ungenutzter Platz ist, wird das Widget wachsen, um diesen auszufüllen, falls das Expandieren eingeschaltet ist. Default ist 0/no. (unfertige Arbeitsversion) 11

12 5.3 Der Geometry-Manager grid 5 GRUNDLEGENDE BILDSCHIRM-ANORDNUNG -fill stil Der Wert kann entweder none, x, y oder both sein. Gibt an, ob das untergeordnete Fenster gar nicht, nur in x- oder y-richtung oder in beide Richtungen gedehnt werden soll, wenn erforderlich. -padx pixel und -pady pixel geben an, wieviele Pixel rechts und links (in x- Richtung) bzw. oben und unten (in y-richtung) um das Widget Platz gelassen werden soll (to pad = polstern, auffüllen). Ohne diese Angaben werden die Elemente sehr dicht gepackt, was nicht immer übersichtlich ist. Möchte man ein Element wieder vom Bildschirm entfernen, so verwendet man pack forget element Mit pack configure element Optionen kann man die Werte für die obigen Optionen auch nach dem Packen ändern. Durch das geschickte Einsetzen von Frames (siehe Abschnitt auf Seite 14) kann man nicht nur triviale Layouts mit dem pack Geometry Manager erreichen. 5.3 Der Geometry-Manager grid Sobald man ein rasterförmiges Layout benötigt, kommt man mit pack nicht besonders weit. Es wäre äußerst lästig und würde ständig neue Frames erfordern. Zudem wären die einzelnen Rasterzellen nicht leicht ansprechbar. Daher gibt es den Geometry-Manager grid, bei dem alles in Zeilen und Spalten angeordnet wird, die zudem durchnumeriert sind. Das müssen nicht unbedingt Tabellen mit Daten sein (die lassen sich mit der Erweiterung tktable 9 besonders gut handhaben), sondern man kann so auch Bilder, Knöpfe oder Eingabefelder in einem Raster anordnen. Natürlich können auch mehrere Zellen des Rasters zu einer größeren Zelle zusammengefasst werden, ähnlich wie man das auch von HTML her vielleicht kennt. Auch die Ausrichtung von Widgets innerhalb einer Zelle ist beliebig festlegbar. Falls mehrere Widgets in einer Zelle untergebracht werden sollen, so legt man zuerst einen Frame in die Zelle und ordnet die Widgets dann in diesem Frame an mit pack oder aber erneut mit grid. Mittels des Kommandos grid kommuniziert man mit dem Geometry-Manager. Wenn man eine Reihe von Widget-Namen und dahinter Optionen übergibt, werden die angegebenen Widgets in einer neuen Zeile nebeneinander angeordnet. Möchte man Widgets in einer bestimmten Zeile oder Spalte anordnen, so gibt man das in entsprechenden Optionen an: -column, -row, wobei die Zeilen- und Spaltennummern mit 0 beginnen. Mittels columnspan und rowspan gibt man an, wieviele Zeilen bzw. Spalten das Widget beanspruchen soll (default ist natürlich 1). Mit der Option -sticky und einer Himmelsrichtungsangabe (n, e, w, s oder Kombinationen davon) gibt man die Ausrichtung innerhalb der Zelle an und ggf. auch, ob das Widget sich ggf. vergrößern soll also ähnlich den beiden Optionen -anchor und -fill beim Geometry- Manager pack. 9 (unfertige Arbeitsversion) 12

13 5 GRUNDLEGENDE BILDSCHIRM-ANORDNUNG 5.4 Layout-Beispiele 5.4 Layout-Beispiele Layout-Beispiele mit pack a) einige Widgets untereinander Die Kommandos werden nacheinander ausgeführt und verändern jeweils den Zustand der grafischen Oberfläche. Alle 3 Widgets werden erzeugt und anschließend unter den bisherigen angeordnet. Es werden hier noch keinerlei zusätzliche Optionen verwendet. entry.zeile -width 10 pack.zeile button.knopf -text "Schaltfläche" pack.knopf radiobutton.wahl -variable option pack.wahl b) einige Widgets nebeneinander Das Beispiel ist fast identisch mit dem ersten, nur dass beim pack-kommando die Option -side left verwendet wird. Dadurch ordnen sich die Widgets immer an der linken Seite an also von links nach rechts, denn ein links angeordnetes Widget lässt rechts Platz frei für das nächste zu platzierende Widget, d. h. immer genau gegenüber. entry.zeile -width 10 pack.zeile -side left button.knopf -text "Schaltfläche" pack.knopf -side left radiobutton.wahl -variable option pack.wahl -side left (unfertige Arbeitsversion) 13

14 5.4 Layout-Beispiele 5 GRUNDLEGENDE BILDSCHIRM-ANORDNUNG c) Widgets neben- und untereinander Hier sieht man die Auswirkung wechselnder Seitenangabe beim Packen der Widgets. Das erste Widget wird links angeordnet, lässt also Platz für das zweite auf der rechten Seite. Das zweite Widget wird (ohne -side-option!) oben angeordnet und lässt also Platz für das dritte auf der unteren Seite. Die -side-option beim letzten Widget ist übrigens völlig ohne Bedeutung es sei denn, man fügt ein weiteres hinzu. entry.zeile -width 10 pack.zeile -side left button.knopf -text "Schaltfläche" pack.knopf Achtung! Hier keine -side-option! radiobutton.wahl -variable option pack.wahl -side left Damit sind die Möglichkeiten von pack ohne die Verwendung von Frames weitgehend ausgeschöpft. Man könnte höchstens noch ein wenig Platz zwischen den Widgets lassen, indem man -padx und -pady verwendet, aber das ändert nichts an den grundsätzlichen Anordnungsvarianten Layout-Beispiele mit pack und Frames Komplexere Layouts brauchen Frames. In diesem Zusammenhang werden dann auch Widgets auftauchen, die nicht direkt auf der obersten Ebene im top level vorhanden sind, sondern in einem Container-Widget. Es werden zunächst die Frames erzeugt und mittels pack angeordnet und in diesen dann die einzelnen Widgets oder halt erst wieder Frames und darin weitere Widgets. a) beschriftetes Eingabefeld und Schaltfläche darunter In den Frame.f1 werden die Widgets.zeile und.label1 nebeneinander eingefügt. Der Frame selbst wird nach oben gepackt. Darunter wird dann die Schaltfläche gepackt ohne Frame dazwischen. frame.f1 pack.f1 entry.f1.zeile -width 10 pack.f1.zeile -side right (unfertige Arbeitsversion) 14

15 5 GRUNDLEGENDE BILDSCHIRM-ANORDNUNG 5.4 Layout-Beispiele label.f1.label1 -text "Name: " pack.f1.label1 button.knopf -text "Schaltfläche" pack.knopf.f1 configure -relief ridge \ -borderwidth 5 Umkonfigurierung des Frames, um seinen Rand sichtbar zu machen..f1 configure -padx 5 \ -pady 5 Umkonfigurierung des Frames, um ein bisschen Platz um die in ihm enthaltenen Widgets seine Slaves zu chaffen. b) Radiobutton-Gruppe, Checkbutton-Gruppe und Schaltflächen Hier soll eine typische Dialogbox einer Textverarbeitung nachempfunden werden. Mit Radiobuttons soll die Ausrichtung (links, rechts, zentriert, Blocksatz) ausgewählt werden. Die Checkbuttons ermöglichen Textauszeichnungen (fett, kursiv, unterstrichen). Die Schaltflächen ermöglichen es, die Dialogbox mit oder ohne Anwendung der gewählten Optionen zu verlassen (OK oder Abbrechen). Zunächst einmal zur Anordnung der Frames. Oben sollen sich zwei Frames befinden: links die untereinander angeordneten Radiobuttons, rechts die Checkbuttons. Unten soll ein Frame mit den beiden Schaltflächen sein. Wir nennen die Frames rb_f, cb_f und sf_f und ordnen sie mit pack an. Hier verwenden wir auch zum ersten Mal die Rückgabewerte der Widget- Kommandos, um uns von den absoluten Pfaden durch die Container-Widgets unabhängig zu machen. Die Reihenfolge des Packens ist hier sehr wichtig. Hätten wir einen der anderen beiden Frames zuerst gepackt, wäre das gewünschte Layout nicht mehr möglich gewesen. Da die Frames noch nichts enthalten, fällt das Applikationswindow auf quasi Nullgröße zusammen. set rb_f [frame.radiobuttonframe] set cb_f [frame.checkbuttonframe] set sf_f [frame.schaltflächenframe] pack $sf_f -side bottom (unfertige Arbeitsversion) 15

16 5.4 Layout-Beispiele 5 GRUNDLEGENDE BILDSCHIRM-ANORDNUNG pack $rb_f -side left pack $cb_f set li_rb [radiobutton $rb_f.li -value links \ -variable ausrichtung -text links] set re_rb [radiobutton $rb_f.re -value rechts \ -variable ausrichtung -text rechts] set ze_rb [radiobutton $rb_f.ze -value zentriert \ -variable ausrichtung -text zentriert] set bl_rb [radiobutton $rb_f.bl -value block \ -variable ausrichtung -text Blocksatz] pack $li_rb $re_rb $ze_rb $bl_rb -anchor w set ausrichtung links Alle Radiobuttons einer Gruppe haben dieselbe Variable zugeordnet genau das macht sie zu einer Gruppe, so dass bei Wählen einer Option die vorher gewählte abgewählt wird. So ist sichergestellt, dass immer nur eine Option gewählt sein kann. Durch das Setzen der Variablen ausrichtung auf den Wert links wird der entsprechende Knopf ausgewählt und markiert. Die Wahl einer anderen Option ändert die Variable wie auch das Ändern der Variablen die Auswahl einer anderen Option auslöst. Die Widgets und die zugeordnete Variable sind also automatisch miteinander verbunden, ohne dass dafür Programmierarbeit anfällt. set f_cb [checkbutton $cb_f.f -variable fett -text fett] set k_cb [checkbutton $cb_f.k -variable kursiv -text kursiv] set u_cb [checkbutton $cb_f.u -variable ustr -text unterstrichen] pack $f_cb $k_cb $u_cb -anchor w set kursiv 1 Die Checkbuttons werden im Gegensatz zu den Radiobuttons mit jeweils einer eigenen Variablen versehen. Diese bekommt den Wert 0 bei nicht ausgewähltem und den den Wert 1 bei ausgewähltem Checkbutton zugewiesen. Änderungen der Variablen spiegeln sich auch hier im Zustand des Buttons wider, weshalb die Variable kursiv auf 1 gesetzt wurde. Wie schon bei den Radiobuttons ist die Verankerung links (im Westen) mit dem Zusatz -anchor w notwendig, weil sonst die Knöpfe mitsamt ihrer textuellen Beschriftung zentriert würden, wodurch sie dann nicht mehr untereinander stünden. (unfertige Arbeitsversion) 16

17 5 GRUNDLEGENDE BILDSCHIRM-ANORDNUNG 5.4 Layout-Beispiele set sf_ok [button $sf_f.ok -text OK] set sf_abbr [button $sf_f.abbr -text Abbrechen] pack $sf_ok $sf_abbr -padx 20 -side left Nun kommen die Schaltflächen hinzu. Zur Zeit ist ihnen noch keinerlei Funktionalität zugeordnet (was mit der Option -command ginge), sonden sie sind lediglich mit einer Beschriftung versehen. Damit sie nicht direkt nebeneinander stehen, sondern sich einigermaßen ansehnlich horizontal verteilen, ist ein x-abstand von 15 Pixeln vorgesehen. Natürlich werden die Knöpfe nebeneinander angeordnet, wobei es egal ist, ob man sie links oder rechts anordnet, weil sie ohnehin zentriert werden. Damit wäre die Dialogbox eigentlich fertig, aber ein bisschen Platz ober- und unterhalb der Knöpfe wäre ganz prima. Diesen konfigurieren wir einfach nach, wobei es egal ist, welchem der beiden Schaltflächen wir den zusätzlichen Platz zuordnen. pack configure $sf_ok -pady 4 Um die Gruppierung der Radio- und der Checkbuttons deutlich zu machen, könnte man ihren Frames eine sichtbare Umrandung zuweisen. $rb_f configure -borderwidth 2 \ -relief ridge $cb_f configure -borderwidth 2 \ -relief ridge (unfertige Arbeitsversion) 17

18 5.4 Layout-Beispiele 5 GRUNDLEGENDE BILDSCHIRM-ANORDNUNG So ganz überzeugend ist das Ergebnis aus zwei Gründen nicht: Erstens kleben die beiden Umrandungen aneinander, zweitens sind die beiden Rahmen unterschiedlich hoch was nicht verwundert, denn der rechte enthält eine Zeile weniger. Beides konfigurieren wir um. pack configure $rb_f -padx 4 -pady 4 pack configure $cb_f -padx 4 -pady 4 \ -fill y -expand yes Layout-Beispiel mit grid Ein typisches Layout-Beispiel für ein Grid ist ein Eingabeformular. Versucht man, es mit pack hinzubekommen, gelingt die Anordnung nicht. Solange die Eingabefelder gleich lang sind, bekommt man es mit der Verankerung im Osten noch hin: frame.f1 entry.f1.e1 -width 20 label.f1.l1 -text "Name:" frame.f2 entry.f2.e2 -width 20 label.f2.l2 -text "Vorname:" pack.f1.f2 -anchor e -pady 2 -padx 2 pack.f1.e1.f1.l1 -side right pack.f2.e2.f2.l2 -side right Sobald aber ein Feld mit anderer Länge dabei ist, geht es schief: frame.f3 entry.f3.e3 -width 25 label.f3.l3 -text "PLZ/Ort:" pack.f3 -anchor e -pady 2 -padx 2 pack.f3.e3.f3.l3 -side right Hier kommt jetzt der Geometry-Manager namens grid zum Zuge und ordnet die Widgets in einem Zeilen-Spalten-Raster an. (unfertige Arbeitsversion) 18

19 6 ANBINDUNG VON CODE AN WIDGETS entry.e1 -width 20 label.l1 -text "Name:" entry.e2 -width 20 label.l2 -text "Vorname:" entry.e3 -width 25 label.l3 -text "PLZ/Ort:" grid.l1.e1 -padx 2 -pady 2 -sticky w grid.l2.e2 -padx 2 -pady 2 -sticky w grid.l3.e3 -padx 2 -pady 2 -sticky w 6 Anbindung von Code an Widgets An manche Widgets kann man sehr leicht Code (in Form von Prozeduren) anbinden, weil sie typischerweise dazu gedacht sind, eine Verarbeitung auszulösen. Das häufigste Beispiel hierfür sind Knöpfe (Schaltflächen), denen man mittels der Option -command eine Prozedur zuordnen kann. Diese wird bei einem Klick auf den Knopf mit der Maustaste 1 (üblicherweise die linke) aufgerufen. Auch einige andere Bindungen sind von vornherein vorhanden. Beispielsweise wird ein Knopf etwas heller, wenn die Maus drübersteht, und wieder dunkler, wenn die Maus seinen Bereich verlässt. Diese Dinge braucht man nicht mehr zu programmieren, kann sie aber bei Bedarf beeinflussen. 6.1 Spezielle Anbindungen Über diese Standardbindungen hinaus kann man mit dem Kommando bind weitere beliebige Verknüpfungen zwischen Ereignissen und Prozeduren herstellen. Näheres hierzu siehe die Man- Page von bind. Bei entry-widgets gibt es auch noch die Möglichkeit, die Eingaben von einer Prozedur prüfen zu lassen. Auch dies ist eine Art der Anbindung von Code an Ereignisse, die mit einem Widget passieren. 6.2 Verwenden von -command Grundsätzlich muss festgestellt werden, dass alle Ereignisprozeduren im globalen Namensraum ausgeführt werden, d. h. irgendwelche in Prozeduren angelegten und nicht mit global versehenen Variablen sind in den Ereignisprozeduren nicht verfügbar. Um die Liste der Variablen nicht ins Uferlose ansteigen zu lassen, ist es oft hilfreich, ein globales Array anzulegen, das dann mittels global bekannt gemacht wird mit all seinen enthaltenen Werten. Alle global notwendigen Variablen werden dann als Elemente dieses globalen Arrays vereinbart. (unfertige Arbeitsversion) 19

20 6.2 Verwenden von -command 6 ANBINDUNG VON CODE AN WIDGETS Hier das simpelstmögliche Beispiel einer Applikation, die man durch Kicken auf einen Knopf schließen kann: (unfertige Arbeitsversion) 20

21 6 ANBINDUNG VON CODE AN WIDGETS 6.2 Verwenden von -command button.b -text "bye" -command exit pack.b Statt eines Kommandos hier exit darf auch der Name einer beliebigen Prozedur angegeben werden, die ohne Parameter aufgerufen werden kann. Auch ist es möglich, hier direkt längeren Code in geschweiften Klammern einzutragen. Das könnte dann so aussehen wie in diesen beiden Beispielen. button.b -text "bye" \ -command {.b configure -text "soon" update after 2000 exit } pack.b proc soon {} {.b configure -text "soon" update after 2000 exit } ;# proc soon button.b -text "bye" \ -command soon pack.b Beim Entwurf eines Programms muss man immer daran denken, dass jederzeit ein Ereignis eintreffen kann, das den Ablauf einer Prozedur auslöst. Die Zeitpunkte und Reihenfolgen dieser Ereignisse sind in aller Regel nicht vorhersagbar. $RCSfile: einf_tk.tex,v $ $Date: 2001/04/06 12:57:55 $ $Revision: 1.2 $ (unfertige Arbeitsversion) 21