AMIGA-Magazin · Ausgabe 12/99 · Programmierung: AmigaOS 3.5 (Teil 1)

Aktuelles Heft 12/99

Inspektor Gadget

Es ist soweit - AmigaOS 3.5 ist erhältlich und bringt aus Programmiersicht eine Vereinfachung beim Erstellen von Oberflächen mit: ReActor. Was es damit auf sich hat und wie Ihnen die Arbeit erleichtert wird, erfahren Sie hier.

von Michael Christoph

Bisher bot der Amiga lediglich die große Vielfalt an GadTools-Gadgets, die jedoch den Nachteil hatten, daß sie eine fixe Größe verwendeten. Nur durch viel Programmieraufwand war es möglich, diese an den aktuellen Font oder unterschiedliche Landestexte anzupassen.

Taschenrechner:
Reaction unterstützt Grafiken und Karteikarten mit Hilfe der neuen Reaction-Klassen von AmigOS 3.5.

Neue Gadgets:
File/Font/Screenmode-
Requester bieten ein Anzeige- bzw. Auswahlgadget an - die Bedienung ist noch komfortabler.

Schritt-für-Schritt:
Das Beispiel zeigt, wie man einen String-Requester erzeugt.

Struktur:
Der Aufbau eines Fensters in ReActor.

Neu und alt:
Die grafischen Elemente der Oberfläche von AmigaOS 3.5 im Überblick.

Viele Programmierer gingen daher den bequemen Weg und erstellten die Oberfläche auf einen fixen Font hin. Gab es früher nur einen HighRes und LoRes-Modus, so bringen die heutigen Grafikkarten eine wahre Flut an möglichen Auflösungen mit. So kann sich jeder Benutzer, in Abhängigkeit von seinem Monitor, die bestmögliche Auflösung und den dazu passenden Zeichensatz aussuchen. Um die einzelnen Programm an diese Auflösungen anzupassen, existier(t)en unterschiedliche Möglichkeiten, das Erstellen der Oberflächen zu vereinfachen:

Und auch verschiedene Programme zum Erstellen der Oberflächen existieren, die jedoch meist wieder auf einen einzigen Font hin ausgerichtet waren (abgesehen vom MUI-Builder).

Bereits seit AmigaOS 2.0 Bestandteil von Intuition ist BOOPSI (basic object-oriented programming system for Intuition, zu deutsch Grundlagen objektorientierte Programmierung für Intuition) was jedoch eher unbeachtet blieb. Bot es doch nur einen »Ersatz« für den Button, String und Slider-Gadget. Mit AmigaOS 3.x folgte dann noch ein Colorwheel (Farbrad) und ein dazupassender Gradientslider (Helligkeitsschieber). Diese unvollständige Umgebung, mit der andersartigen Programmierung kam daher bei mir nie zum Einsatz. Trotzdem sind diese Gadgets bereits mehr oder weniger selbstlayoutend und durch die Ableitungstechnik lassen sich leicht und schnell neue Gadgets erstellen. Dabei sind nur neue Funktionen zu implementieren, das bekannte »Standardverhalten« ist bereits in den Grund-Gadgets enthalten und muß nicht erneut programmiert werden.

* Alt und neu

Setzten die GadTools-Gadget noch auf den »alten« Gadget-Strukturen auf, sind bei den BOOPSI-Gadgets keinerlei Verwaltungsstrukturen mehr bekannt. Das erfordert ein gewisses Umdenken, da die einzelnen Werte nicht mehr einfach aus der Gadget-Struktur ausgelesen bzw. umgekehrt manipuliert/verändert werden können. Man spricht im objektorientierten Bereich auch von einer »Black Box«. Dafür bieten die BOOPSI-Gadgets jedoch eine standardisierte Möglichkeit zum Setzen/Erfragen der Werte an und es ist nicht, je nach Gadgettyp, der Wert woanders auszulesen. Entwicklerseitig können somit beliebige Änderungen an den internen Verwaltungsstrukturen der Gadgets vorgenommen werden, ohne daß hierdurch ein »älteres« Programm nicht mehr funktionieren würde. Zusätzlich wird hierdurch auch die einfache Ableitung/Vererbung von Eigenschaften ermöglicht. Alle gleichen zentralen Daten werden in einem Root-Gadget gesammelt, von dem dann z.B. ein Button oder ein String-Gadget »abgeleitet« werden. Bei Verbesserungen im Root-Gadget profitieren alle abgeleiteten Gadgets automatisch. Auf der anderen Seite wird der Verwaltungsaufwand und somit das Fehlerrisiko innerhalb der abgeleiteten Gadgets minimiert.

* AmigaOS 3.5 bringt Reaction mit

Das brandneue AmigaOS-Update bringt nun eine ganze Flut neuer Gadgets mit, teilweise GadTools bekannte Arten, aber auch viel neues. Diese Sammlung von BOOPSI-Gadgets laufen unter dem Begriff Reaction-Klassen. Das Programm »ReActor« dient zum komfortablen Erstellen der Oberflächen, unter Benutzung dieser (aber auch anderer) Klassen. Die Klassen stammen aus der Feder von Christopher Aldi (1) und waren bereits teilweise unter dem Namen »ClassAct« als Public Domain erhältlich. Der Vorteil dieser BOOPSI-Gadgets liegt im selbstlayouten, was jedoch auch ein Umdenken beim Erstellen der Oberflächen verlangt.

Wurde bisher »traditionell« jedem Gadget seine Position und Größe in Pixeln absolut vorgegeben, passen sich diese BOOPSI-Gadget automatisch dem Font oder der aktuellen Fenstergröße an. Hier funktioniert das Pixelsystem nicht mehr. Wie lassen sich aber die Gadgets sonst positionieren? Die Reaction-Gadgets verwenden das stark verbreitete System, die Oberfläche in (horizontale und vertikale) Gruppen aufzuteilen. Innerhalb der Gruppen darf der Entwickler weitere Gruppen und/oder Gadgets mischen. Dabei kann man wieder universell vorgehen:

  1. Das Gadget kann links/rechts/zentriert innerhalb der Gruppe angeordnet sein.
  2. Es darf eine fixe Größe haben.
  3. Das Gadget soll den vollen Bereich der Gruppe in Anspruch nehmen.

Das Ausrichten mehrerer Gadgets anhand der Labels ist ebenso möglich, wie die Größenanpassung mehrerer Gadgets zueinander. Die Gruppen können mit sichtbaren Rahmen versehen werden, so daß auch mehrere Gadgets für den Benutzer »sichtbar« zusammenfassbar sind (s. »Taschenrechner«). Bevor diese Layouts Schritt-für-Schritt mit ReActor erstellt werden, soll zuerst ein Überblick der vorhandenen Elemente erfolgen.

* Komfortabel edtieren

Bisher wurden normalerweise die Gadgets »von Hand« per Parameterlisten erzeugt, was auch weiterhin möglich wäre. Doch das Programm »ReActor« bietet eine wesentlich komfortablere Umgebung zum Aufbau der Oberfläche. In der Programmumgebung wird sofort das endgültige Fenster-Layout angezeigt und Änderungen der Position, Texte oder anderer Parameter lassen sich ohne zeitaufwendiges compilieren betrachten. Dadurch ist die Oberfläche sehr schnell entworfen und der Programmierer kann sich mehr Zeit nehmen für die eigentlichen Aufgaben des Programms. Wenn Sie ReActor starten, sehen Sie ein zweigeteiltes Fenster (beachten Sie bitte die »Information für Developer«). In der linken Liste werden die erstellten Window-Objekte eingetragen, rechts befindet sich ein schmaler Streifen mit den Steuerelementen, um z.B. ein neues Fensterobjekt zu erzeugen (New) oder deren Reihenfolge zu verändern (Up/Down). Über die Karteikartenreiter kann auf die anderen Seiten umgeschaltet werden, wobei die zweite Seite mit den Gadget-Objekten nachfolgend noch ausgiebig genutzt wird. Zur detailierten Erklärung dieser und der anderen Möglichkeiten lesen Sie bitte auch die Anleitung zu ReActor.

* Elemente von ReActor

Zuerst sollen die drei Arten von Elementen unterschieden werden: Images, Gadgets und Gruppen. Diese werden in der Tabelle »Die ReActor-Elemente« gezeigt. Zusätzlich zeigt die kleine Grafik das Aussehen an (was jedoch teilweise durch die Benutzereinstellungen im ReActor-Prefs-Programm verändert werden kann, siehe Infobox »Reaction hat einen Voreinsteller«). Weitere Elemente in ReActor sind Windows und ARexx, zum Definieren der Fensterdaten bzw. der unterstützten ARexx-Kommandos.

* Die neuen Reaction-Gadgets

ReActor: Beispiel-Tags
WA_Title,"Input Request" (LocaleID MSG_WIN_Title)
WA_Width,340
WA_Height,50
WA_NoCareRefresh,TRUE
WA_DepthGadget,TRUE
WA_SizeGadget,TRUE
WA_DragBar,TRUE
WA_Activate,TRUE
WA_SizeBBottom,TRUE
WINDOW_Position,Center Screen
WINDOW_Layout,GROUP_ID_Main
textfield Mehrzeiliges Text-Eingabefeld mit automatischem Zeilenumbruch und Cut/Copy/Paste-Clipboardunterstützung. Kann einfach als Editierfeld verwendet werden und bietet vielfälltige Möglichkeiten (TEXTEDITOR_xxx + GA_xxx).

getfile ist eine Anzeige für Datei- oder Verzeichnisnamens. Das Anzeigefeld kann auch editierbar gemacht werden. Über das Symbol läßt sich der FileRequester zur Auswahl öffnen. Die Auswahl wird automatisch in das Anzeigefeld übertragen (GETFILE_xxx + GA_xxx).

getfont Hier wird über das linke Symbol der FontRequester geöffnet. Der gewählte Zeichensatz wird automatisch in das Anzeigefeld übertragen. Bisher besteht keine Möglichkeit, den Namen bzw. Größe im Anzeigefeld zu verändern ( GETFONT_xxx + GA_xxx).

getscreenmode Über das linke Symbol wird der ScreenmodeRequester geöffnet. Der gewählte Screenmode wird wieder automatisch in das Anzeigefeld übertragen (GETSCREENMODE_xxx + GA_xxx).

clicktab sind die Karteikarten, per PageGroup wird die Liste der Seiten eingehängt, wobei die Liste vom Typ »Page« sein muß. Alle Untergruppen von Page bilden jeweils eine neue Karteikartenseite. Die Namen und Reihenfolge der Karteireiter sind in clicktab zu definieren (CLICKTAB_xxx + GA_xxx).

fuelgauge (horizontale/vertikale) Füllstandsanzeige, optional mit Teilstrichen. Wird z.B. in den Laufwerksfenstern der Workbench verwendet, um die Belegung der Festplatte grafisch anzuzeigen. Kann auch als Fortschrittsanzeiger mit Prozentangabe verwendet werden (FUELGAUGE_xxx + GA_xxx).

speedbar dient als Gruppe für Grafik-Buttons, die als Toolbar verwendet werden; z.B. für Neu, Laden, Speichern, Drucken usw. Ein passender Hilfetext ist möglich. Die Gruppe kann horizontal oder vertikal im Programmfenster oder im eigenen Fenster angeordenet sein. Bei zu vielen Einträgen ist die Liste scrollbar. Eine einfache Möglichkeit für Benutzer die persönliche Toolbar zusammenzustellen (SPEEDBAR_xxx + GA_xxx).

* Gruppen in Reaction

Information für Entwickler
Die aktuelle Entwickler-CD wird bei Haage & Partner vorbereitet und soll spätestens zu Messe in Köln verfügbar sein. Sie enthält neben den neuen und überarbeiteten Includes auch die zugehörigen Autodocs und viele Beispielsourcen zu den neuen Funktionen. Auch das Programm »ReActor« ist mit Anleitung und Beispielen auf der CD zu finden.

Informationen:
Haage & Partner, Postfach 1104,
61477 Glashütten,
Tel. (0 61 74) 96 61 00, Fax: (0 61 74) 96 61 01,
WWW: http://www.haage-partner.com

Anhand der Gruppen wird die Anordnung der Gadgets und somit das Aussehen der Oberfläche bestimmt. Die Elemente können vertikal oder horizontal gruppiert werden. Wahlweise kann ein Rahmen und eine Gruppenbeschriftung erfolgen. Über vielfälltige Tags läßt sich beispielsweise der Abstand der Gadgets zum Rand definieren. Es stehen unterschiedliche Gruppen zur Auswahl, wobei es sich immer um das selbe layout.gadget handelt. Eine Ausnahme bildet page ­ allerdings mit unterschiedlichen vorgesetzten Tagwerten:

root (Layout) ist die Basis-Layoutklasse, und der Aufhänger, der in das Fenster »eingehängt« wird (LAYOUT_xxx + GA_xxx).

gadget zum horizontalen Gruppieren von Buttons (z.B. Save-Use-Cancel-Leiste) gedacht.

vlayout/hlayout vorbelegte Ausrichtung für vertikale/horizontale Gruppe.

page kommt bei Karteikarten zum Einsatz und ist (wie Root) die Basis. Eingefügt werden jeweils wieder Gruppen, wobei jede Gruppe einer einzelnen Seite entspricht, die per Karteikarte oder programmseitig umgeschaltet werden können. Soll es als Karteikarte verwendet werden, muß es in ein clicktab.gadget integriert werden ­ per CLICKTAB_PageGroup (PAGE_xxx + LAYOUT_xxx + GA_xxx).

Spacer sind weder Gruppen noch interactive Gadgets, sondern nehmen lediglich Platz in Anspruch ohne dabei etwas anzuzeigen. Sie können z.B. dazu verwendet werden, die Position (oder Zwischenräume) anderer Gadget zu beeinflussen (SPACE_xxx + GA_xxx).

* Erstellen der Oberfläche

Das Erstellen von BOOPSI-Gadgets verlangt einige Vorarbeit und Überlegung, wenn bisher nur mit den »traditionellen« Gadget-Strukturen (Intuition/GadTools) gearbeitet wurde. So besteht ein Reaction-Gadget aus bis zu drei Elementen:

Leider nimmt uns bisher ReActor beim Erstellen keine Arbeit ab, so daß immer alle benötigten Elemente selber erstellt werden müssen. Am einfachsten ist es dabei, die Elemente »rückwärts« zu erstellen. Also zuerst Label und Image und erst dann das Gadget. In diesem sind nämlich noch das Label und das Image als Verknüpfung festzulegen. Wird die Zuordnung vergessen, erscheint das Label, je nach Listenposition, an einer anderen Stelle im Fenster oder wird gar nicht angezeigt (wenn es als Unterobjekt z.B. eines Buttons in der Liste liegt).

Kursübersicht
Grafische Benutzeroberflächen unter AmigaOS 3.5 entwerfen
Teil 1: Vorstellung der neuen Reaction-Gadgetklassen, Vorstellung von ReActor zum Erstellen der selbstlayoutenden Oberflächen
Teil 2: Der Sourcecode zur Oberfläche wird erstellt und dabei die resource. library vorgestellt. Abfrage und Setzen der Gadgetwerte.
Teil 3: Eigene Reaction-Gadgets/Images erstellen und deren Einbindung in das ReActor-Programm.
Die nachfolgende Schritt-für-Schritt-Anleitung zeigt ausführlich, wie ein komplettes Fenster entworfen werden kann. In unserem Beispiel handelt es sich um eine vertikale Gruppe im Fenster, diese enthält das String-Gadget, darunter die Trennlinie und eine horizontale Gruppe. Innerhalb der horizontalen Gruppe befinden sich die beiden Gadgets »Ok« und »Cancel«. Genau in dieser Reihenfolge sind auch die Einträge in ReActor zu erstellen. Unser Beispiel sehen Sie in »Schritt-für-Schritt«. Doch nun geht es in die Praxis:

Zu setzen sind für unser Beispiel die Tags wie in Tabelle »ReActor: Beispiel-Tags« aufgelistet ­ sie werden durch »Add« oder Doppelklick aus der linken Auswahlliste übernommen.

Das letzte Tag kann allerdings erst gesetzt werden, wenn die Gadgetgruppe erzeugt wurde. Per WA_Width/WA_Height wird die Größe des Fensters beim Öffnen festgelegt. Bei Bedarf wird das Fenster allerdings automatisch größer geöffnet, z.B. wenn nicht alle Elemente hineinpassen würden. Ohne die beiden Tags wird das Fenster hingegen in der Minimalgröße geöffnet. Per WINDOW_Position läßt sich eine relative Fensterposition beim Öffnen festlegen. In unserem Beispiel wird das Fenster mittig im Bildschirm geöffnet.

Wechseln Sie anschließend auf die Karteikarte »Gadget Groups«. Per »Add« wird die neue Gruppe erzeugt und sofort ein leeres Fenster zur Definition des Gadget Layouts geöffnet. In der rechten Liste sind alle Gruppen/Gadgets/Images aufgelistet. Diese übertragen Sie durch Doppelklick in die Layoutliste. Dabei öffnet sich automatisch das Fenster zur Tagdefinition. Sie können es später per Doppelklick auf den Eintrag erneut öffnen.

Bei der Erstellungsreihenfolge ist darauf zu achten, daß das String-Label vor dem String-Gadget erstellt wird. Das Label wird dem String-Gadget per CHILD_Label bekannt gegeben. Ansonsten sind die String-Tags zweimal zu editieren.

Sie können aber auch »in einem Rutsch« alle Objekte in die Liste eintragen und erst danach die Tags für jedes einzelne Objekt definieren (den Aufbau sehen Sie in »Struktur«).

Damit die beiden Buttons (OK bzw. Cancel) immer die selbe Breite und Höhe besitzen und nicht dynamisch der Fenstergröße angepaßt werden, dient die Definition von CHILD_WeightedWidth/Height. 0 bedeutet dabei keine Änderung. Mit größeren Werten kann das Verhältnis mehrerer Gadgets in einer Gruppe festgelegt werden. Beispiel: der Button erhält 30 Prozent der Höhe, das String-Gadget 60 Prozent der Breite).

Per LAYOUT_EvenSize, TRUE in der übergeordneten Gruppe wird festgelegt, daß alle Members die selbe Größe bekommen. Das OK-Gadget wird also hier in der Größe des Cancel-Gadget erzeugt. LAYOUT_HorizAlignment, Center zentriert die Gadgetgruppe über die Fensterbreite. In der Root-Gruppe legt LAYOUT_FixedVert, FALSE fest, daß das Fenster in der Höhe nicht veränderbar ist. Genauer gesagt ist die im Fenster integrierte Gruppe nicht höhenänderbar und daraus ergibt sich, daß auch die Fensterhöhe nicht verändert werden kann. Ohne den Tag würde lediglich mehr Luft zwischen den Elementen gelassen, wenn das Fenster in die Höhe gezogen würde. Die Breitenänderung dagegen wird zugelassen, da sich hierbei das String-Gadget immer auf die volle Fensterbreite ausdehnt und somit mehr Zeichen der Eingabe zu sehen sind. Bei den Buttons wiederrum wird lediglich die »Luft« gleichmäßig links/dazwischen/rechts aufgeteilt.

Reaction hat einen Voreinsteller
Die Reaction-Gadgets haben den weiteren Vorteil, daß sie zum Teil konfigurierbar sind. So kann sich jeder Benutzer sein bevorzugtes Erscheinungsbild zusammenstellen ­ z.B. die Hintergrundgrafik, Rahmenabstände, Aussehen der Slider und mehr.
Die Tags LAYOUT_FixedVert/Horiz können aber nicht nur in der Root-Gruppe verwendet werden, sondern in allen Gruppen. So werden gezielt einzelne Gruppen von Größenänderungen ausgeschlossen. Der »überschüssige« zur Verfügung stehende Platz wird einfach den anderen Gruppen zugeteilt. LAYOUT_SpaceOuter läßt außerhalb der Gruppe einen Abstand, LAYOUT_SpaceInner entsprechend innerhalb der Gruppe. Am besten läßt sich der Zusammenhang erkennen, wenn der Gruppenrahmen aktiviert wird (per LAYOUT_BevelStyle). Werden mehrere Gruppen ineinander geschachtelt, reicht meist SpaceInner aus. Auch die Gruppe im Fenster würde mit einem Spacing auskommen, solange kein Gruppenrahmen aktiviert wird. Durch beide Spacing-Tags wird lediglich der Abstand der Elemente zum Fensterrahmen verdoppelt. Über LAYOUT_InnerSpacing ist der Abstandswert veränderbar. Dieser Schritt sollte jedoch nicht programmseitig geschehen, da dieser Wert vom Benutzer in den Prefs-Einstellungen verändert werden kann.

GA_ID ist bei den einzelnen Gadgets zwar anzugeben, die tatsächliche ID wird allerdings von ReActor vergeben (Erstellungsreihenfolge) und kann leider nicht beeinflusst werden. Der Definename ist dazu unter »Object Name« einzutragen. Dieser Tag ist trotzdem notwendig, damit bei Gadgetereignissen (z.B. IDCMP_GADGETUP) unterschieden werden kann, welches Gadget der Auslöser war.

Nach diesen Schritten sollten Sie den, wie in »Neue Gadgets« abgebildeten Baum sehen. Ist das nicht der Fall, können Sie über die »Up« und »Down«-Schalter die Reihenfolge und Einrückung (entspricht der Zugehörigkeit) der einzelnen Elemente beeinflussen.

Labels sind normalerweise immer mit einem Gadget gekoppelt und werden in der Gadgetbeschreibung per LAYOUT_Label definiert. Damit diese Angabe nicht in die eigentliche Größenberechnung einfließt bzw. falsche gezeichnet wird, wird es als Unterpunkt des Gadgets »versteckt«.

Wechseln Sie zurück in die »Window«-Karteikarte und klicken dort auf »Test«. Dann wird das Fenster geöffnet, welches die Gadgets enthält. Ändern Sie die Fenstergröße, passen sich die Positionen und die Breite des Eingabefelds automatisch der aktuellen Fenstergröße an. Die Buttons hingegen behalten ihre Größe.

Bis zur nächsten Ausgabe können Sie ausgiebig mit ReActor spielen. Dann werden wir uns mit einem komplexeren Layout und verschiedenen Gadgets beschäftigen. Dabei wird dann auch ausführlich darauf eingegangen, wie der Sourcecode aussehen muß, um die Oberfläche zu beleben. Wir zeigen ebenfalls, wie die Gadgetdaten gesetzt und ausgelesen werden können.

Alle Beispieldateien finden Sie direkt auf der Homepage des Autors:

http://www.meicky-soft.de/amiga-magazin/reaction.html

lb

Informationen:
ClassAct: Christopher Aldi, Timothy Aston, Osma Ahvenlampi,
Petter Nilsen (published by Finale Development Inc.), WWW: http://www.warped.com/~timmer/classact/

Literatur:
[1] M. Steigerwald, Skriptgestützte Kreativität, AMIGA Magazin 9/99, S. 26

ELEMENTE DES GUI

Images bilden den sichtbaren Teil der Oberfläche, ohne sie wäre nichts zu sehen.
bevel sind (Gruppen) Rahmen (oder Linien) mit wählbarem Aussehen und können optional mit einem (frei plazierbaren) Text beschriftet werden (BEVEL_xxx + IA_xxx) frameiclass sind GadTools-Bevelrahmen ­ also Einfachrahmen (Button), Doppelrahmen (String) und IconDropbox. (IA_xxx).
bitmap dient zur Anzeige von Grafiken, z.B. für Image-Buttons (Schalter mit Grafiken statt einem Text). Die Grafik wird automatisch per Datatype-System geladen und unterstützt transparente Darstellung. Alternativ können die Grafikdaten auch direkt vom Programm als Bitmap übergeben werden. (BITMAP_xxx)
penmap eignen sich ähnlich wie Bitmaps zur Anzeige von Grafiken. Hier sind die Grafikdaten aber fest in der Beschreibungsdatei verankert sind. Das Objekt kann frei skaliert werden und unterstützt »color remapping« (PENMAP_xxx + IA_xxx).
fillrectclass füllt eine rechteckige Fläche optional mit Füllmuster und Rahmen ( IA_xxx). glyph stellen eine definierte Menge an frei skalierbaren Symbolen zur Verfügung, z.B. Pfeile (GLYPH_xxx + SYSIA_xxx).
sysiclass oder system glyph fungieren wie das normale Glyph, jedoch handelt es sich hierbei um die systemeigenen Symbole, z.B. für die Fensterelemente wie das »Close/Depth/...«-Symbol ( SYSIA_xxx).
drawlist damit können eigene, frei skalierbare Objekte erstellt werden. Zu übergeben ist eine Liste mit Zeichenkommandos ( DRAWLIST_xxx + IA_xxx).
label kommen zur Erzeugung von Textobjekten zum Einsatz. Sie sind normalerweise als Beschriftung für die Gadgets gedacht. Es ist ein alternativer Font möglich (LABEL_xxx + IA_xxx).
Gadgets verwenden ein Image (das auch einen Text representieren kann) zur Visualisierung. Sie übernehmen die unterschiedlichen Interaktionen mit dem Benutzer. button das »Grundgadget« ist der altbekannte Schalter. Wird dieser angeklickt, löst er eine Aktion aus. Dabei können Texte oder Grafiken als Schalterfläche verwendet werden. Grafiken lassen sich auch mit transparentem Hintergrund darstellen und ohne Gadget-Rahmen. Im ReadOnly-Modus wird es mit einem Label versehen und kann es auch als Anzeigefeld verwendet werden (BUTTON_xxx + GA_xxx).
listbrowser entspricht dem GadTools-Listview-Gadget, allerdings mit mehr Möglichkeiten. Die Auswahlliste kann mehrere Spalten besitzen (die getrennt ausgerichtet werden können) und auch Überschriften besitzen können. Die Liste kann ReadOnly sein; es wird Einfach- und Mehrfachselektion unterstützt. Bei Bedarf wird die Liste dynamisch mit einem horizontalen Scroller versehen, um die Liste nach links/rechts zu verschieben. Die Liste kann auch Grafiken als Einträge enthalten ­ auch gemischt mit Text in einer Zeile (LISTBROWSER_xxx + GA_xxx)
chooser entspricht dem GadTools-Cycle-Gadget, wobei zwei Varianten existieren:
  - normales Cycleverhalten, hierbei klappt eine Liste auf und ein Eintrag kann gewählt werden. Wird dagegen auf das linke Cycle-Symbol geklickt, wird der nächste (mit Shift vorherige) Eintrag aktiviert, ohne daß die Liste geöffnet wird (CycleToMenu-Verhalten).
  - es wird immer der selbe Text im Ausgabefeld angezeigt. In der aufgeklappten Liste ist der gewählte Eintrag abgehakt. Alternativ kann der Anzeigetext entfallen und nur das DropDown-Symbol angezeigt werden. (CHOOSER_xxx + GA_xxx)
checkbox dienen zum Ein/Ausschalten von Optionen (CHECKBOX_xxx + GA_xxx).
radiobutton wie Checkboxen, aber als MutualExclude-Auswahl. In der Praxis: Es ist immer einer (und nur einer) der Punkte auswählbar. Wird zur Auswahl aus einer kleinen, definierten Menge benutzt (RADIOBUTTON_xxx + GA_xxx).
colorwheel (Farbrad) zur direkten Auswahl eines Farbwertes. Dieses Element wird sehr oft in Kombination mit Scrollern eingesetzt. Diese können die Rot/Grün/Blau- Anteile der gewählten Farbe anzeigen bzw sie lassen sich verändern ( WHELL_xxx + GA_xxx).
gradientslider damit kann der Helligkeitswert eingestellt werden. Kommt normalerweise in Kombination mit dem Colorwheel zum Einsatz (GRAD_xxx + GA_xxx + PGA_Freedom).
palette Auswahl von Farbregistern. Es kann die ganze oder eine Teilpalette zur Auswahl angeboten werden. Es ist immer eine Farbe gewählt. Kann auch als Einzelfarb-Vorschaufeld »mißbraucht« werden (PALETTE_xxx + GA_xxx).
slider sind Schieberregler, die wie »Lautstärkereglern« aussehen. Optional sind Trennstrichen zur Unterteilung möglich. Der Slider »rastet« optisch nicht ein, sondern sie können auch zwischen den Positionen stehen. Deshalb erfolgt normalerweise keine Zahlen-Anzeige der aktuellen Position (SLIDER_xxx + GA_xxx).
scroller sind ebenfalls Schieber. Sie kommen oft zur Auswahl von Zahlenwerten (bei einem definierten Bereich) zum Einsatz. Optional können sie rechts Pfeiltasten besitzen, über die der Knopf schrittweise bewegt wird. Im Gegesaz zu den Slidern rastet der Scroller beim Loslassen ein ( SCROLLER_xxx + GA_xxx). string Einzeiliges Text-Eingabefeld, optional mit Eingabefiltern z.B. für Hexzahlen oder Paßwörter ­ die Eingaben werden dann »*« angezeigt (STRINGA_xxx + GA_xxx).
integer Zahleneingabefeld, der Zahlenbereich ist definierbar (Minimun/Maximum). Optional sind wieder Pfeile einblendbar, um den Zahlenwert per Klick zu verändern (INTEGER_xxx + STRINGA_xxx + GA_xxx).


 Hauptseite © 1999 All Rights Reserved. Alle Rechte vorbehalten Franzis' Verlag GmbH
Veröffentlichung und Vervielfältigung nur mit schriftlicher Genehmigung des Verlags

Kommentare, Fragen, Korrekturen und Kritik bitte an Webmaster AMIGA schicken.
Zuletzt aktualisiert am 23. November 1999, Michael Christoph.