MUI - MagicUserInterface Ein System zur Gestaltung von grafischen Benutzeroberflächen (c) Copyright 1993 by Stefan Stuntz - ShareWare - Einführung ********** Das Konzept von MUI =================== MagicUserInterface, abgekürzt MUI, ist ein komplettes System zum Erstellen und Verwalten von grafischen Benutzeroberflächen. Das Erstellen solcher Oberflächen war auf dem Amiga schon immer ein großes Problem, weil dem Programmierer vom Betriebssystem dabei relativ wenig Unterstützung geboten wird. Durch die Einführung der `gadtools.library' unter Kickstart 2.0 war zwar ein erster Schritt in die richtige Richtung getan, aber auch damit ist das Erzeugen einer anspruchsvollen Oberfläche schwierig und langwierig. Es gibt zwar mittlerweile zahlreiche Hilfsprogramme, welche die Arbeit mit der `gadtools.library' vereinfachen sollen, doch auch die damit erzielten Ergebnisse sind meist alles andere als befriedigend. Das größte Problem der herkömmlichen Tools zur Erstellung von Benutzeroberflächen liegt in deren relativ unflexiblen Ergebnis. Die meisten Programme arbeiten heute immer noch mit fest eingestellten Zeichensätzen und Fenstergrößen, obwohl das im Zeitalter von hochauflösenden Grafikkarten eigentlich eine Zumutung ist. Aber die Amiga-Benutzer sind ja in dieser Hinsicht leider sowieso nicht allzu verwöhnt, selbst die Preferences-Programme auf der Workbench verwenden alle noch den Standard-Zeichensatz `topaz/8'. Hier will MUI Abhilfe schaffen. Der zentrale Gedanke hinter MUI besteht darin, daß nur der Benutzer (und nicht der Programmierer) einer Applikation weiß, wie diese auf seinem persönlichen Gerät am Besten aussieht. Deswegen enthält ein MUI Programm auch so gut wie keine absoluten Größen- und Positionsangaben, der Programmierer spezifiziert lediglich gewisse Gruppenzugehörigkeiten von Bedienungselementen. Das eigentliche Plazieren der Objekte wird dann während der Laufzeit des Programms nach den Vorgaben des Benutzers vom MUI System übernommen. Eine MUI Applikation bietet ihrem Benutzer demnach viele wesentliche Vorteile gegenüber normalen Programmen: - Zeichensatz-Sensitivität Bei jedem MUI Programm können die verwendeten Zeichensätze frei eingestellt werden. Vorbei sind die Zeiten in denen A2024-Besitzer mit winzig kleinen topaz/8 Programmen kämpfen müssen. MUI schränkt die Auswahl der Zeichensätze in keinster Weise ein, das gilt insbesondere auch für Proportionalschriften. Diese verleihen einem Programm zum einen ein wesentlich hübscheres und professionelleres Aussehen und verringern zum anderen den Platzbedarf erheblich. - Veränderbare Fenstergrößen Alle MUI-Fenster besitzen ein Sizing-Gadget mit dem sich die Größe beliebig bestimmen läßt. Je kleiner das Fenster, desto näher rücken die Bedienungselemente zusammen, je größer, desto mehr Platz ist für die Darstellung von Informationen vorhanden. Größe und Position eines Fensters lassen sich zudem dauerhaft abspeichern, damit man gleich nach dem Start einer Applikation seine Lieblingseinstellungen vor sich hat. - Flexibilität Nahezu alle Elemente einer Oberfläche können in ihrem Aussehen beeinflußt werden. Als Benutzer bestimmt man, wie dick die Rahmen sind, wie die Scrollbalken auszusehen haben, welche Images verwendet werden oder wieviel Platz zwischen den Zeilen eines Listviews eingefügt werden soll. MUI bietet hier eine Fülle von Möglichkeiten, auf die später noch genauer eingegangen wird. - Tastatur-Bedienbarkeit Normalerweise werden grafische Benutzeroberflächen, natürlich auch die von MUI, mit einer Maus bedient. Viele Benutzer würden allerdings auch gerne die Tastatur verwenden, weil das in manchen Fällen einfach schneller und bequemer ist. Deshalb lassen sich alle Objekte einer MUI Oberfläche, seien es nun String-Gadgets, Radio-Buttons oder Listen, ohne weiteres auch mit Tastatur steuern. Die Maus kann man dabei getrost bei Seite schieben, sie wird nicht mehr benötigt. - System-Integration MUI Applikationen arbeiten auf vielfältige Weise mit dem Betriebssystem zusammen. Jedes Programm kann etwa auf Knopfdruck (oder mit dem Commodities Exchange Programm) ikonifiziert und später wieder zum Leben erweckt werden. Außerdem besitzen alle Applikationen einen ARexx-Port, mit dem man unter anderem die komplette Benutzeroberfläche "fernsteuern" kann. - Umgebungsanpassung Einem MUI Programm ist es gleichgültig, ob es auf der Workbench oder einem anderem Public Screen läuft, ob die Auflösung 640x200 oder 1280x1024 Pixel beträgt oder ob 4 oder 256 Farben zur Verfügung stehen. Jede Applikation kann vom Benutzer auf beliebige Bildschirme geschaltet werden und paßt sich dort automatisch an ihre Umgebung an. Alle eben genannten (und noch viele andere) Einstellungen können vom Benutzer einer Applikation mit Hilfe des MUI Preferences Programms vorgenommen werden und zwar je nach Notwendigkeit global oder für jede Applikation einzeln. Systemanforderungen =================== MUI läuft mit allen Betriebssystemversionen ab Kickstart 2.0 und ist so programmiert daß es auch unter allen folgenden Versionen arbeitet. Kickstart 1.3 wird nicht mehr unterstützt, die Zeiten sind endgültig vorbei. Dringend anzuraten ist außerdem eine Festplatte, obwohl MUI sich auch mit Diskettenlaufwerken zufrieden gibt. Bedingt durch das modulare Konzept kann es dabei jedoch beim ersten Starten einer Applikation zu etwas längeren Ladezeiten kommen. MUI stellt keine besonderen Anforderungen an den Prozessortyp, aber auch hier gilt natürlich: je mehr desto besser. Für die Verwaltung und das Layout von Fenstern sind teilweise komplizierte Berechnungen nötig, die auf einem 68000er eventuell etwas langsam sind. Speicher kann man sowieso nie genug haben, ein Megabyte ist zum Betrieb von MUI allerdings mehr als ausreichend. Bei (nur) 512 kByte könnte es je nach Applikation etwas knapp werden. Installation ============ MUI wird mit dem *Note Installer: POL_INSTALLER von Commodore ausgeliefert, deshalb ist die Installation denkbar einfach. Ein simpler Doppelklick auf `MUI-Install' startet den Vorgang, danach wird man vom Script weiter geführt. Besonderheiten von MUI-Applikationen ************************************ Fenster ======= Wie bereits in der Einleitung erwähnt, sind fast alle MUI Fenster in ihrer Größe beliebig veränderbar. Ein Benutzer kann selbst bestimmen, ob die Bedienungselemente eher klein und platzsparend oder größer und übersichtlicher erscheinen. Damit man nicht bei jedem Start einer Applikation seine bevorzugten Fenstergrößen (und Positionen) neu einstellen muß, merken sich MUI Fenster diese Werte automatisch und stellen sie bei einem erneuten Start des jeweiligen Programms wieder zur Verfügung. Das gilt sowohl für die normale Fenster-Position und Größe als auch für die entsprechenden Werte im "Zoomed"-Zustand (nach Betätigen des Zoom-Gadgets). Nach einem Reset sind die gespeicherten Informationen über die Fenster gewöhnlich verloren, es sei denn man hat im *Note Preferences-Programm: PRF_INTRO die Speicher-Funktion aktiviert. Dadurch werden unter anderem sämtliche - die Fenster betreffenden Daten - gespeichert und stehen fortan dauerhaft zur Verfügung. Alle Fenster einer Applikation enthalten außerdem im oberen Rahmen neben dem Depth- und dem Zoom-Gadget noch einen dritten Knopf. Dieser Knopf kann dazu benutzt werden, die gesamte Applikation zu ikonifizieren. MUI schließt daraufhin alle Fenster (und eventuell Screens) die zu der Applikation gehören und erzeugt ein kleines AppIcon auf der Workbench. Ein Doppelklick auf dieses AppIcon bringt die Applikation dann wieder zum Vorschein. Tastatur ======== Alle Bedienungselemente in einem MUI-Fenster sind vollständig mit der Tastatur steuerbar. Die von herkömmlichen Programmen verwendeten Tastatur-Shortcuts (gekennzeichnet durch einen unterstrichenen Buchstaben in dem jeweiligen Gadget) werden natürlich unterstützt, diese Methode stößt jedoch bei Objekten wie Listviews oder Cycle-Gadgets schnell an ihre Grenzen. Für MUI wurde deshalb das von String-Gadgets bekannte Prinzip des `Tab'-Cyclings aufgegriffen und erweitert. In MUI-Fenstern können mit `Tab' neben String-Gadgets auch alle anderen Objekte aktiviert werden. Ein aktives Objekt kann dann jeweils mit der Tastatur bedient werden: - Button-Gadgets `Return' entspricht einem Anklicken des Knopfs mit der Maus, dabei wird zwischen Drücken und Loslassen unterschieden. Ein bereits gedrückter Knopf kann (vor dem Loslassen von `Return') durch `Shift' abgebrochen werden, ohne daß die dazugehörige Aktion ausgelöst wird. - Checkmark-Gadgets Ein aktives Checkmark-Gadget kann mit `Space' oder `Return' beeinflußt werden, der Status kehrt sich dadurch jeweils um. - Slider Die vier Cursor-Tasten, zusammen mit den entsprechenden Qualifiern beeinflussen den Wert von horizontalen oder vertikalen Slidern. - Cycle-Gadgets Bei aktivierten *Note Cycle-Gadgets: USE_CYCLE können die Einträge mit den Cursor-Tasten durchgeschaltet werden. Die `Return'-Taste läßt das zugehörige Popup-Menü aufklappen (falls dieses Feature nicht abgeschaltet wurde). - Radio-Buttons Auch hier dienen die Cursor-Tasten zur Steuerung. - Listviews In einem aktivierten *Note Listview: USE_LISTVIEWS läßt sich der Cursor mit den Cursor-Tasten und den entsprechenden Qualifiern zeilenweise, seitenweise oder ganz nach oben bzw. unten bewegen. Die `Return'-Taste simuliert einen Doppelklick. Falls in dem Listview mehrere Einträge selektiert werden können, kann dazu `Space' verwendet werden. - Fenster Sollte eine Applikation mehrere, gleichzeitig bedienbare Fenster geöffnet haben, dann können mit `Alt-Tab' bzw. `Shift-Alt-Tab' diese Fenster der Reihe nach aktiviert werden. Ein Drücken von `Escape' wirkt wie ein Mausklick auf das Close-Gadget (falls vorhanden). Sämtliche Erklärungen beziehen sich auf die Standard-Einstellungen, mit dem Preferences-Programm lassen sich alle verwendeten Tastenkombinationen beliebig einstellen (siehe *Note Tastaturbelegung: PRF_KEYBOARD). Listviews ========= MUIs Listviews arbeiten pixel-orientiert, es ist also durchaus möglich, daß am oberen oder unteren Rand Zeilen nur teilweise sichtbar sind. Pixel-Listviews werden heute auf allen modernen Betriebssystemen verwendet und vermeiden, daß das Auge beim Scrollen die Bindung zum Text verliert und sich nach Abschluß einer Scroll-Operation erst wieder neu zurechtfinden muß. Leider reicht die Auflösung der Amiga-Mausbewegung nicht aus, um besonders bei Listen mit vielen Einträgen ein Scrollen um nur wenige Pixel zu ermöglichen. Um dieses Manko auszugleichen, bietet MUI für Listviews eine "Nachlauf"-Option an. Mehr darüber findet sich im Abschnitt *Note Listview-Parameter: PRF_OBJECTS_LISTVIEWS im Preferences-Kapitels. Cycle Gadgets ============= In MUI Applikationen verwendete Cycle-Gadgets bieten neben ihrer normalen Funktion (nächster Eintrag durch anklicken, vorheriger Eintrag mit `Shift') auch optional ein Popup-Menü. Dieses Menü klappt auf, sobald der Text-Bereich im Cycle-Gadget angeklickt wird und erlaubt eine schnelle und übersichtliche Selektion eines der vorhandenen Einträge. Das genaue Verhalten dieser Popup-Menüs kann im Preferences-Programm festgelegt werden (siehe *Note Cycle-Gadget Menüs: PRF_OBJECTS_CYCLE). Commodities Interface ===================== Jedes MUI Programm bindet sich als Commodity ins System ein. Dadurch hat man als Benutzer die Möglichkeit, Applikationen mit dem `Exchange'-Programm der Workbench zu kontrollieren. Die Kontrolle besteht dabei im wesentlichen darin, Programme zu ikonifizieren oder ganz zu verlassen. ARexx Port ========== Alle MUI-Applikationen können über einen integrierten ARexx-Port Befehle empfangen. Dabei stehen immer einige Standard-Befehle zur Verfügung, die jedes Programm versteht: - QUIT Die Applikation wird beendet. - HIDE Die Applikation wird ikonifiziert. - SHOW Eine ikonifizierte Applikation wird wieder zum Leben erweckt. - INFO ITEM/A Je nach angegebenem Parameter wird der Ergebnis-String entsprechend aufgefüllt: - "title" Titel der Applikation - "author" Autor der Applikation - "copyright" Copyright-Notiz - "description" Kurzbeschreibung - "version" Versionsstring - "base" Name des ARexx Ports - HELP FILE/A Eine Liste aller ARexx-Befehle wird in die angegebene Datei geschrieben. Zusätzlich zu den Standard-Befehlen kann (und sollte) eine Applikation natürlich noch eine Menge eigener Befehle definieren. Die Help-Liste wird dann auch diese Befehle enthalten. Einige kleine Beispiel-Scripts sind der Distribution beigelegt und finden sich im `Rexx'-Ordner im Hauptverzeichnis. Preferences-Programm ******************** Allgemeines =========== Die Philosophie von MUI besteht darin, daß eine Applikation möglichst wenige Angaben über das Aussehen ihrer Benutzeroberfläche macht. Im Prinzip werden hier nur die einzelnen Bedienungselemente zu Gruppen zusammengefaßt um ihre relative Position zueinander zu bestimmen. Weitergehende Einstellungen, etwa welche Zeichensätze verwendet werden, wieviel Abstand zwischen den Elementen einer Gruppe eingefügt wird, ja sogar welches Aussehen die verwendeten Rahmen und Symbole haben werden dem Benutzer der Applikation überlassen. Diese Einstellungen werden mit dem Preferences Programm vorgenommen. Hauptfenster ============ Das Preferences Programm besteht aus einem Hauptfenster von dem aus man in verschiedene Unterfenster verzweigen kann. Jedes dieser Unterfenster deckt einen bestimmten Aspekt der Konfiguration einer Applikation ab. Alle Fenster arbeiten parallel, d.h. es ist ohne weiteres möglich, mehrere davon zu öffnen und dort gleichzeitig Einstellungen vorzunehmen. MUI bietet die Möglichkeit alle Einstellungen nach Applikationen getrennt vorzunehmen. Das Preferences Programm zeigt hierzu im Hauptfenster eine Liste der Namen aller bereits einmal gestarteten Programme an. Alle Voreinstellungen beziehen sich immer auf die Applikation deren Name gerade aktiv ist. Meist wird man jedoch Parameter global, d.h. für alle Applikationen auf einmal, konfigurieren wollen. Dazu steht am Beginn der Liste der Eintrag `-Global'. Hier getroffene Einstellungen wirken sich auf alle Applikationen aus, d.h. immer dann, wenn eine globale Einstellung verändert wird, überträgt diese sich automatisch auf die entsprechenden lokalen Werte, sofern diese vor der Änderung mit dem globalen Wert übereingestimmt haben. Wenn also zum Beispiel global der Zeichensatz `helvetica/13' und speziell für das MUI-Demo Programm der Zeichensatz `Times/18' konfiguriert ist, dann wirkt sich die globale Änderung von `helvetica/13' auf alle anderen Applikationen, nicht aber auf das Demo-Programm aus. Die Applikations-Liste hat noch eine weitere Funktion. Ein Doppelklick auf einen Eintrag öffnet einen Informations-Requester, in dem einige wichtige Daten über das jeweilige Programm angezeigt werden. So kann man beispielsweise den Namen des ARexx-Ports oder die Versionsnummer herausfinden. Allerdings funktioniert dieses Feature nur, wenn die Applikation gerade läuft. Mit dem `Default'-Knopf unter der Applikations-Liste kann die lokale Konfiguration einer Applikation gelöscht, d.h. an die momentan eingestellte globale Konfiguration angeglichen werden. Am unteren Fensterrand befinden sich die, von den System Preferences Programmen bekannten, `Save'-, `Use'- und `Cancel'-Knöpfe sowie zusätzlich ein `Test'-Gadget. Dieses `Test'-Gadget, dessen Funktion übrigens auch aus jedem Unterfenster mit der Tastenkombination `Amiga-T' über einen Menüeintrag auszulösen ist, ist wohl das am meisten benutzte Gadget im Preferences Programm. Gerade zu Beginn wird man ein wenig mit den vielen Parametern herumspielen, bis man seine ideale Einstellung gefunden hat. Ein Druck auf `Test' veranlaßt alle gerade laufenden Applikationen dazu, sich automatisch an die neu spezifizierten Werte anzupassen. Man kann also, nachdem man eine Applikation gestartet hat, deren Einstellungen einem noch nicht zusagen, parallel dazu das Preferences Programm aufrufen und die neue Applikation sozusagen im direkten Dialog dem eigenen Geschmack anpassen. Es ist übrigens durchaus möglich, daß ein Betätigen des `Test'-Gadgets scheinbar keinerlei Aktion auslöst. Laufende Applikationen werden sich nur dann updaten, wenn sich ihre Parameter auch tatsächlich geändert haben. Das `MUI-Demo' Programm wird also von einer Änderung der Rahmendicke speziell für die Preferences vollkommen unbeeindruckt bleiben. Mit dem `Use'-Gadget werden alle getroffenen Einstellungen temporär (im `env:' Verzeichnis) abgelegt und das Preferences Programm beendet. Diese Einstellungen gehen natürlich mit dem nächsten Reset verloren. Zur dauerhaften Speicherung dient das `Save'-Gadget, alle Parameter werden auf Festplatte gesichert und stehen fortan immer zur Verfügung. Neben den konfigurierten Werten speichert MUI außerdem sämtliche Fensterpositionen aller Applikationen. Durch `Cancel' werden alle Änderungen verworfen, Applikationen die sich eventuell durch die `Test'-Funktion angepaßt haben, nehmen ihr altes Aussehen wieder an. Es erfolgt hier im Einklang mit den System Preferences Programmen keine Sicherheitsabfrage. Objects-Fenster =============== Im `Objects'-Unterfenster sind einige Einstellungen für verschiedene Oberflächenelemente zusammengefaßt: Listview-Parameter ------------------ Der `Leading'-Wert bestimmt die Anzahl der zusätzlichen Pixel, die zwischen den Zeilen eines Listviews eingefügt werden sollen um die Lesbarkeit zu erhöhen. Je nach verwendetem Zeichensatz und persönlichem Geschmack können hier durchaus größere Werte sinnvoll sein, insbesondere bei kleinen Fonts wie `topaz/8' wird die Übersichtlichkeit dadurch erheblich erhöht. Mit `Smoothing' kann der bei vielen Leuten beliebte "Nachzieh-Effekt" eines Listviews eingestellt werden. Dieser Effekt bewirkt, daß die Position einer Liste beim Scrollen nicht unmittelbar an den Scrollbalken angepaßt wird, sondern diesem in, von der Geschwindigkeit der Bewegung abhängigen Schritten, folgt. Dadurch verliert das Auge nicht so leicht die Bindung zum Text und kann der Bewegung besser folgen. Je höher der Wert, desto ausgeprägter ist der Effekt. Eine `0' verhindert das Nachziehen vollständig. Bei Listviews die das gleichzeitige Anwählen von mehreren Einträge gestatten, den sogenannten Multi-Select-Listviews, kann der Benutzer zwischen zwei verschiedenen Selektions-Mechanismen wählen. Bei `Shifted' muß, ähnlich der Workbench, nach der ersten Selektion die `Shift'-Taste gehalten werden, sonst werden die bereits selektierten Einträge wieder deselektiert. Mit `Always' kann das Drücken der Shift-Taste unterbleiben. `Refresh' bestimmt die Art in der eine Liste neu aufgebaut wird: bei `linear' werden die Zeilen wie üblich von oben nach unten gedruckt, `intermixed' verursacht einen ineinander verschränkten Aufbau. Die Position der Pfeil-Gadgets an den Scrollbalken eines Listviews kann mit dem `Arrows'-Gadget beeinflußt werden. Hier stehen drei Möglichkeiten zur Auswahl. Cycle-Gadget Menüs ------------------ MUIs Cycle-Gadgets bieten als Bedienungserleichterung ein Popup-Menü, das bei Betätigen das Gadgets aufklappt und eine einfache und schnelle Selektion des gewünschten Eintrags zuläßt. Mit `Level' kann man bestimmen, ab wieviel Einträgen ein Cycle-Gadget solch ein Popup-Menü zur Verfügung stellen soll. Falls man die Popup-Menüs gar nicht mag, stellt man diesen Wert einfach genügend groß ein und wird sie nie zu Gesicht bekommen. Normalerweise erscheinen die Popup-Menüs immer direkt unter dem Gadget. Zwecks schnellerer Bedienung und Minimierung der Mausbewegung kann man sie aber auch so konfigurieren, daß der gerade aktive Eintrag immer direkt unter dem Mauszeiger erscheint. Dazu dient das `Position' Gadget mit seinen beiden Einstellmöglichkeiten. Fenster ------- Hier kann der Abstand zwischen dem Fensterrahmen und dem Fensterinhalt pixelgenau bestimmt werden. Normalerweise wird man wohl für `Left' und `Right' sowie `Top' und `Bottom' identische Werte einstellen, deswegen sind diese Gadgets einseitig miteinander verbunden. Sobald also der `Left'- bzw. `Top'-Slider bewegt wird, bewegen sich `Right'- bzw. `Bottom'-Slider automatisch mit. Um dennoch getrennte Einstellmöglichkeiten zu gewährleisten, gilt diese Verbindung nicht in der anderen Richtung, ein Verschieben von `Right/Bottom' beeinflußt die Positionen von `Left/Top' nicht. Gruppen ------- Ein Gruppenobjekt dient lediglich dazu, andere Objekte in seinem Inneren zu gruppieren. So eine Gruppe stellen zum Beispiel die Knöpfe für die Unterfenster im Hauptfenster des Preferences Programms dar. Mit den beiden Parametern bei `Group Spacing' kann sowohl der horizontale als auch der vertikale Abstand zwischen zwei Elementen einer Gruppe eingestellt werden. Radio Button Gadgets -------------------- Die Einstellungen hier wirken sich nur auf die (selten benutzten) Radio Button Gadgets aus und legen fest, wieviel Platz zwischen den einzelnen Zeilen (`Vertical') und zwischen dem Knopf und dem beschreibenden Text (`Horizontal') gelassen werden soll. Rahmen ====== Rahmen sind ein wichtiges Element um eine Benutzeroberfläche übersichtlich zu gestalten und einzelne Gruppen von Objekten voneinander abzugrenzen. Rahmen sind aber auch Geschmackssache, deswegen kann man sie alle in ihrem Aussehen beeinflussen. Bei den in herkömmlichen Amiga-Programmen verwendeten Rahmen sind die vertikalen Linien immer doppelt so dick wie die horizontalen Linien. Dies rührt wohl noch aus den Zeiten her, in denen 640 x 256 die übliche Auflösung war, die Pixel waren dabei ungefähr doppelt so hoch wie breit. Im Zeitalter von Flickerfixern und hochauflösenden Grafikkarten etablieren sich jedoch immer mehr Auflösungen wo das Verhältnis von Pixel-Breite zu Pixel-Höhe ungefähr 1:1 beträgt, es besteht also kein Grund mehr, Rahmen unnötig zu verbreitern. MUI bietet deshalb bei `Thickness' die Möglichkeit, von den üblichen dicken Rahmen auf dünne Rahmen umzustellen. Eingerahmte Gruppen können in ihrem Rahmen einen Titel beinhalten. Die Farbe dieses Gruppen-Titels kann mit der `Title Color' Einstellung konfiguriert werden. Drei Möglichkeiten stehen hier zur Auswahl, entweder schwarz, weiß oder dreidimensional. Der Gruppentitel wird im oberen Teil des Gruppenrahmens horizontal zentriert angezeigt. Mit `Title Pos' kann die vertikale Position dieses Titeltexts beeinflußt werden. Bei `centered' erscheint der Titeltext auch vertikal zentriert in der Mitte des Rahmens, bei `above' befindet sich die Grundlinie des Textes genau auf Rahmenhöhe. In Zusammenhang mit dieser Einstellung steht auch der innere Abstand eines Gruppenrahmens, der im nächsten Abschnitt besprochen wird. Beim Erstellen von Rahmen in einer MUI-Applikation spezifiziert der Programmierer nicht das Aussehen sondern lediglich den Typ eines Rahmens. So bekommt zum Beispiel ein Button einen Button-Rahmen oder ein String-Gadget einen String-Rahmen. Wie diese Rahmen dann im Endeffekt aussehen, das bestimmt der Benutzer. Dazu sind alle möglichen Typen in einer Liste aufgeführt, jeweils mit einem kleinen Bild welches das gerade eingestellte Aussehen anzeigt. Die einzelnen Rahmen werden wie folgt verwendet: - Button-Frame für normale Button-Gadgets, wie zum Beispiel der `Edit'-Button unter dieser Liste. - Image-Frame für kleine Buttons die nur ein Image enthalten, zum Beispiel die Pfeil-Gadgets in einem Scrollbalken. - Text-Frame für Text-Felder die weder angeklickt noch editiert werden können und nur zur Information dienen, zum Beispiel Statuszeilen. - String-Frame für String Gadgets. - Read-List für Listviews die lediglich zur Anzeige einer Liste dienen und in denen nichts angeklickt werden kann. - Input-List für Listviews in denen der Benutzer Einträge selektieren kann, zum Beispiel alle Listviews im Preferences-Programm. - Prop-Frame für alle Proportional-Gadgets, unter anderem verwendet in Scrollbalken und Schiebereglern. - Group-Frame zum Gruppieren von Objekten, zum Beispiel sind die Knöpfe für die Unterfenster im Hauptfenster mit einem Group-Frame umgeben. Durch einen Doppelklick auf einen Eintrag in der Liste oder mit dem `Edit'-Gadget wird das Rahmen-Konfigurations-Fenster aufgerufen: Rahmen-Einstellungen -------------------- Im Rahmen-Fenster kann aus einer Liste von vorgefertigten Rahmen einer ausgewählt werden. Die verschiedenen Möglichkeiten werden im `Type'-Gadget angeboten. Jeder dieser Rahmen existiert in zwei Fassungen, entweder `Raised' (herausragend) oder `Recessed' (eingedrückt). Zu einem Rahmen gehört außerdem noch der Abstand, der ihn von seinem inneren Objekt trennt. Dieser Abstand kann mit den vier Schiebereglern bestimmt werden. Auch hier wird man normalerweise für `Left/Right' und `Top/Bottom' identische Werte wählen, deswegen sind auch diese Regler wieder einseitig verkettet. Je nach Zeichensatz kann es aber durchaus sinnvoll sein, zum Beispiel beim Button-Frame den unteren Abstand etwas kleiner als den oberen zu wählen, um damit durch Unterlängen von Buchstaben eventuell verursachte Unsymmetrien auszugleichen. Images ====== Grafische Benutzerobeflächen arbeiten teilweise mit kleinen Bildern, im folgenden auch Images genannt. Die am häufigsten verwendeten Images sind wohl die Pfeile, sichtbar etwa im Scrollbalken eines Listviews. Für viele derartige Positionen stellt MUI Standard-Images zur Verfügung. Das hat zum einen den Vorteil, daß nicht jeder Programmierer selbst solche Images erzeugen muß, zum anderen kann der Benutzer das Aussehen frei einstellen. Hier nun eine Aufstellung der vorhandenen Standard-Images. - `ArrowUp', `ArrowDown', `ArrowLeft', `ArrowRight' Vier Pfeile in die verschiedenen Richtungen. - `CheckMark', `Radio-Button', `Cycle' Die bekannten Images aus den jeweiligen Bedienungselementen. Das Besondere am Checkmark-Image ist, daß es nur im selektierten Zustand sichtbar ist. - `PopUp', `PopFile', `PopDrawer' Images für Popup-Buttons neben String-Gadgets. Wenn Dateien oder Verzeichnisse abgefragt werden sollen, wird `PopFile' bzw. `PopDrawer' verwendet, ansonsten `PopUp'. - `Drawer', `HardDisk', `Disk', `Chip', `Volume' Standard-Images für Einträge in einem File-Requester. - `PropKnob' Schieberegler im Proportionalgadget. Neben der Liste mit den Standard-Images finden sich die Hintergrund-Typen. Bei MUI kann man viele verschiedene Hintergründe einstellen, zum Beispiel einen für Fenster, einen anderen für Button-Gadgets und einen dritten für Listviews. Inwieweit das sinnvoll ist, muß jeder selbst entscheiden. Jedenfalls kommt - wer an einer bunten Oberfläche Geschmack findet - bei MUI voll auf seine Kosten. - `Window' wird überall da verwendet wo sonst kein anderer Hintergrund zutrifft, also insbesondere da wo sich keine Objekte befinden. - `Requester' der Hintergrund für MUI-Requester, findet sich zum Beispiel hier im `About'-Requester. - `Textfield' eingerahmte Text-Felder, zum Beispiel Statuszeilen, werden mit diesem Hintergrund hinterlegt. - `Button' wird für große Buttons die üblicherweise Text enthalten oder auch für Cycle-Gadgets verwendet. - `Active 'Gadget ein mit TAB aktiviertes Gadget bekommt diesen Hintergrund. - `Selected 'Gadget ein mit der Maus angeklicktes Gadget wird (neben der Invertierung des Rahmens) durch diesen Hintergrund kenntlich gemacht. - `Listview' erscheint hinter den Zeilen eines Listviews. - `Listview Cursor' der Cursor in einem Listview. - `Listview Selected' selektierte Einträge in einem Listview. - `Listview Selected+Cursor' der Cursor auf einem selektierten Eintrag im Listview. - `Prop-Gadget Background' entspricht dem Hintergrund in einem Proportional Gadget, also der Bereich auf dem sich der Schieberegler hin und her bewegt. Nachdem die Bedeutung der einzelnen Einträge geklärt ist, nun zu deren Konfiguration. Ein Doppelklick oder der jeweilige `Edit'-Button am Ende der Liste öffnen für den gerade aktiven Eintrag das Image-Konfigurations-Fenster. Für MUI macht es dabei keinen Unterschied, ob ein Hintergrund-Pattern oder ein Standard-Image definiert wird. Image-Einstellungen ------------------- MUI versteht viele verschiedene Image-Typen: - Pattern Ein Pattern ist ein wenig kompliziertes Muster, einige davon sind bereits in MUI eingebaut. Pattern eignen sich hauptsächlich als Hintergrund-Image, können aber auch für einige Standard-Images, etwa für den Prop-Gadget Knopf sinnvoll verwendet werden. - Builtin-Images Für alle Standard-Images ist in MUI jeweils ein Typ fest eingebaut. Diese eingebauten Images sind aus Vektoren zusammengesetzt und können demnach beliebig vergrößert werden. - MBR-Images Das sind in einer speziellen Farbpalette abgespeicherte IFF Brushes. Diese Farbpalette erlaubt MUI, die Images an die Farben des Bildschirms anzupassen, auf dem diese dargestellt werden sollen. Auf der MUI-Diskette werden einige MBR-Images mitgeliefert, natürlich können auch mit einem entsprechenden Malprogramm eigene erstellt werden. MBR-Images sind nicht in der Größe veränderbar. - Boopsi-Images Ein Boopsi-Image ist eigentlich ein Programm, das immer dann aufgerufen wird wenn es gezeichnet werden soll. Solche Images liegen als "shared library" vor und sollten sich im Ordner `sys:classes/Images' auf der System-Partition befinden. Bei MUI liegen einige dieser Images bei die insbesondere für den Schieberegler eines Proportional-Gadgets gedacht sind. - Alien-Images Ab Kickstart 3.0 gibt es im Amiga Betriebssystem die sogenannten `Datatypes'. Damit ist es möglich, beliebige Bild-Dateien, seien es nun IFF, GIF oder sonstige Formate, mit einigen wenigen Befehlen einzuladen. MUI unterstützt diese Datatypes und erlaubt damit die Verwendung von beliebigen Bildern als Hintergrund oder Standard-Image in allen Applikationen. Allerdings ist dieses Feature erst ab Kickstart 3.0 verfügbar. Im `Image-Edit Fenster' kann nun den vorher angewählten Standard-Images oder Hintergründen ein Image aus einer der oben genannten Kategorien zugeordnet werden. Eine Image-Zuordnung besteht für MUI dabei immer aus einem String, in dem bei nachzuladenden Images der komplette Pfadname, bei eingebauten Images ein spezieller Wert steht. Dieser String kann im "Image" String Gadget per Hand eingegeben werden, einfacher ist es jedoch, dafür die unter den beiden Statuszeilen angebrachten Knöpfe zu verwenden. In der `Pattern'-Reihe sind dazu alle eingebauten Pattern, in der `Builtin'-Reihe alle eingebauten Vektor-Images sichtbar. Die drei Knöpfe `MUI Brush', `Boopsi' und `Alien' (nur unter Kickstart 3.0 oder höher verfügbar) rufen jeweils File-Requester auf, in denen die entsprechenden Dateien ausgewählt werden können. Die Default-Pfade für diese Requester können im *Note General-Fenster: PRF_GENERAL eingestellt werden, außerdem wird jeweils der letzte eingestellte Pfad übernommen. Zeichensätze ============ In MUI gibt es fünf Standard-Zeichensätze die von Applikationen genutzt werden können: - `Normal' Dieser Zeichensatz wird für alle Texte benutzt für die nicht explizit ein anderer Zeichensatz konfiguriert ist. - `List' Das ist der Default-Zeichensatz für Listviews. - `Tiny' Der Tiny-Zeichensatz wird verwendet, um kleine relativ unwichtige Beschriftungen anzubringen. Die Skala eines Scale-Objects (siehe `MUI-Demo') benutzt zum Beispiel diesen Font. - `Fixed' Wenn ein Programm einen nicht-proportionalen Zeichensatz benötigt, tritt dieser hier in Aktion. - `Title' In diesem Zeichensatz werden die Gruppentitel angezeigt. Bei einem leeren Feld verwendet MUI entsprechende Standard-Zeichensätze, und zwar für den Fixed-Font den System-Default-Font und ansonsten den Default-Font des Screens. Screens ======= MUI Applikationen können auf beliebigen Public Screens laufen, ohne daß ein Programmierer hierzu irgendwelche Vorkehrungen zu treffen hätte. Der Public-Screen Name wird einfach mit dem Preferences Programm eingestellt. Außerdem enthält MUI auch eine Art Screen-Manager, damit können verschiedene Screens in Größe und Auflösung konfiguriert werden. Zum Einstellen des Public Screens dient wie erwartet das String Gadget am unteren Fensterrand. Wenn der angegebene Screen bereits beim Starten der Applikation vorhanden ist, wird er benutzt. Ansonsten sucht MUI in der Liste des eingebauten Screen-Managers nach dem gewünschten Namen und öffnet im Erfolgsfall den entsprechenden Screen. Falls der eingestellte Public-Screen entweder nicht gefunden oder (z.B. aus Speichermangel) nicht geöffnet werden kann, startet die Applikation auf dem Default Public Screen (das ist normalerweise der Workbench Screen). Der Hauptteil des Fensters wird jedoch vom Screen Manager ausgefüllt. In einer Liste finden sich dabei die Namen aller bereits eingestellten Screens, zuzüglich zweier Elemente die dem Default Public Screen und dem Workbench Screen entsprechen. Um nun einen neuen Screen zu erzeugen, muß einfach das `New'-Gadget gedrückt werden. In der Liste erscheint daraufhin ein neuer Bildschirm, dessen Parameter durch Doppelklick oder Betätigen des `Edit'-Gadgets in einem neuen Fenster eingestellt werden können. Screen Einstellungen -------------------- In diesem Fenster werden die bestimmenden Parameter eines Screens eingestellt. Dazu gehört natürlich zunächst der Name mit dem der Screen referenziert wird. Dieser Name kann im `Public Name' String Gadget eingegeben werden. Alle im System verwendeten Public Screens müssen unterschiedliche Namen haben. Hinter `Title' verbirgt sich wie erwartet der Text, der in der Titelzeile angezeigt wird und bei `Font' läßt sich der Default-Zeichensatz einstellen, mit dem der Bildschirm und die darauf geöffneten Fenster dargestellt werden sollen. In der `Screen Mode' Gruppe wird der Display-Modus sowie Auflösung und Farbzahl des Bildschirms angezeigt. Ein Druck auf den `Adjust' Knopf öffnet einen ScreenMode-Requester, in dem diese Parameter verändert werden können. Neben diesen essentiellen Werten kann ein Bildschirm noch einige andere Eigenschaften besitzen, die im folgenden aufgezählt werden: - `Auto Scroll' Wenn der Screen größer als der sichtbare Bereich definiert wurde, dann wird er automatisch gescrollt sobald die Maus an einen Rand stößt. - `Draggable' Screens ohne dieses Attribut können nicht verschoben werden. - `Exclusive' Der Bildschirm kann das Display nicht mit anderen Bildschirmen teilen, er wird immer alleine dargestellt (erst ab Kick 3.0). - `Interleaved' Dieses Attribut vermindert falls gesetzt das Flimmern das besonders beim Scrollen von Listen auf vielfarbigen Screens auftritt (erst ab Kick 3.0). - `Open Behind' Der Screen wird unauffällig hinter allen anderen Screens geöffnet. - `System Default' Der Screen wird zum System Default Screen erklärt. Alle Fenster die auf dem System Default Screen aufzugehen wünschen (z.B. Shell-Fenster) werden dadurch umgelenkt. Tastaturbelegung ================ Alle Tasten die zum Steuern von MUI Applikationen verwendet werden, können hier konfiguriert werden. Die Einträge in der Liste sprechen für sich, das Format ist wie üblich das Standard-Format für die Input Event Beschreibungen der `commodities.library'. Besondere Beachtung verdient der `Press'-Key. Bei dieser Taste ist MUI darauf angewiesen, auch beim Loslassen entsprechende Aktionen durchführen zu können. Deswegen muß diese Taste als Qualifier-Beschreibung unbedingt den String `-upstroke' enthalten. System ====== Im System-Fenster finden sich einige Einstellungen, welche die Zusammenarbeit von MUI mit dem Betriebssystem betreffen. Zum Refresh von MUI-Fenstern stehen zwei Möglichkeiten zur Auswahl, die mit dem `Window Refresh' Gadget eingestellt werden können. Der `smart' Refresh braucht mehr Chip-Memory, ist dafür aber schneller als der `simple' Refresh. Bei `Startup'- und `Shutdown'-Command können zwei Befehle eingetragen werden, die automatisch vor dem Start bzw. nach dem Ende einer Applikation ausgeführt werden sollen. Hier könnte zum Beispiel mit einem externen Screen-Manager ein Public-Screen für die Applikation geöffnet werden, sofern die Fähigkeiten des integrierten Screen-Managers nicht ausreichen. Oder ein simpler echo-Befehl könnte in einem Logfile mitspeichern, wann eine Applikation gestartet und beendet wurde. Mit dem `Iconify-Hotkey' kann man eine Tastenkombination festlegen, mit der eine bestimmte Applikation ikonifiziert (und wieder hervorgeholt) werden kann. Das Format für den Eintrag entspricht dem Standard Input-Description Format der commodities.library. Wenn `Iconify-Gadget' angeschaltet ist, dann bekommt jedes Fenster der Applikation im Rahmen ein zusätzliches Gadget, das dann bei Betätigung den Iconify-Prozeß auslöst. Normalerweise wird für eine ikonifizierte Applikation auf der Workbench ein AppIcon erzeugt. Durch Doppelklick auf dieses AppIcon kann dann die Applikation wieder aktiviert werden. Bei ausgeschaltetem `Iconify-Icon' erscheint kein solches Icon, zum Aktivieren bleibt nur noch die Möglichkeit eines eventuell konfigurierten Hotkeys oder ein Benutzen des Commodities Exchange Programms. `Start Iconified' schließlich bestimmt, ob eine Applikation sofort beim Starten ikonifiziert werden soll. Sinnvoll ist das zum Beispiel für Tools die in der `WBStartup/' Schublade plaziert werden und sofort auf Knopfdruck zur Verfügung stehen sollen. Allgemeines =========== Dieses Fenster fällt aus der sonstigen Hierarchie etwas heraus. Hier werden lediglich Einstellungen vorgenommen die das Preferences Programm ganz privat betreffen, sozusagen die Preferences der Preferences. Die drei String Gadgets bestimmen jeweils die Pfade, die benutzt werden wenn im *Note Image-Konfiguration: PRF_IMAGES_EDIT der entsprechende Knopf gedrückt wird. CLI-Interface ============= Das Prefs-Programm bietet auch ein kleines CLI-Interface, das eigentlich nur dazu dient, den eingebauten Screen-Manager auch anderen Programmen zur Verfügung zu stellen. Die Syntax für den Aufruf mit Parametern lautet: NAME,OPEN/S,CLOSE/S NAME: Name eines (konfigurierten) Public Screens OPEN: Screen öffnen CLOSE: Screen schließen ARexx Port ========== Das Preferences Programm enthält einen einfachen ARexx-Port mit den folgenden vier Befehlen: * `SAVE' Entspricht der Funktion des `Save'-Knopfs. * `USE' Entspricht der Funktion des `Use'-Knopfs. * `TEST' Entspricht der Funktion des `Test'-Knopfs. * `CANCEL' Entspricht der Funktion des `Cancel'-Knopfs. Natürlich können daneben auch die *Note Standard-ARexx-Befehle: USE_AREXX verwendet werden. Wichtige Prinzipien der MUI-Programmierung ****************************************** Diese Kapitel enthält eine kurze Einführung in wichtige Prinzipien beim Erstellen von MUI Applikationen. Für tiefergehende Informationen sei auf die beiliegenden Autodocs und die dokumentierten Beispielprogramme verwiesen. Objektorientiertheit ==================== MUI basiert auf BOOPSI, dem `Basic Object Oriented Programming System for Intuition'. Um MUI zu verstehen ist es sicher nicht schlecht, einen kleinen Einblick in die Konzepte von objektorientierter Programmierung genossen zu haben. Eine gelungene und absolut ausreichende Einführung zu diesem Thema findet sich im ersten Abschnitt des BOOPSI Kapitels im `Libraries Rom Kernel Reference Manual'. Die folgende Dokumentation über die Programmierung von MUI setzt Begriffe wie `Objekte', `Klassen', `Methoden' und `Attribute' als bekannt voraus. MUIs Klassenbaum ================ Wie bei BOOPSI üblich, sind auch alle Klassen des MUI-Systems in einem festen Baum angeordnet. MUI setzt dabei direkt unter der `rootclass' an, es werden keine anderen Klassen des BOOPSI-Systems verwendet. Trotzdem ist es möglich, bereits vorhandene BOOPSI Gadgets in MUI Applikationen zu verwenden, dazu finden sich weitergehende Informationen in den `Autodocs'. Hier nun der komplette Klassenbaum: +-----------+ ! rootclass ! +-----------+ ! +--------+ ! Notify ! +--------+ ! +----------------------+-----------------------------+ ! ! ! +------+ +--------+ +-------------+ ! Area ! ! Window ! ! Application ! +------+ +--------+ +-------------+ ! ! +-----+-------+-------+-------+-------+-------+-------+-------+ ! ! ! ! ! ! ! ! ! ! +-----+ +----+ +------+ +----+ +------+ +-----+ +-----+ +------+ ! !Image! !Text! !String! !Prop! !Slider! !Gauge! !Scale! !Boopsi! ! +-----+ +----+ +------+ +----+ +------+ +-----+ +-----+ +------+ ! +---------------+-----------------------------+ ! ! +------+ ! ! List ! ! +------+ ! ! ! +-------------+-----------+ ! ! ! ! ! +---------+ +----------+ +-------+ +-------+ !Floattext! !Volumelist! !Dirlist! ! Group ! +---------+ +----------+ +-------+ +-------+ ! +------------+---------+--------+ ! ! ! ! +---------+ +--------+ +-----+ +-----+ !Scrollbar! !Listview! !Radio! !Cycle! +---------+ +--------+ +-----+ +-----+ Für jede Klasse existiert eine eigene Dokumentation im `Autodocs'-Format (siehe `Developers/Autodocs/' Directory), dort findet sich eine exakte Beschreibung aller unterstützten Attribute und Methoden. Familienverhältnisse ==================== Jede MUI Applikation besteht aus einer Ansammlung von vielen Objekten, die alle in gewisser Weise miteinander verbunden sind. Diese Verkettung ist dabei immer als Eltern-Kind-Beziehung organisiert, manche Objekte können entweder ein einzelnes oder auch mehrere Kinder verwalten. Das oberste Objekt in einem MUI Programm, also quasi der Vater aller andern Objekte ist das Application-Objekt. Es übernimmt die Kommunikation des Programms mit allen möglichen Arten von Eingaben, seien es nun Benutzer-Aktionen oder ARexx- und Commodities-Messages. Das Application-Objekt kann ein unbegrenzte Anzahl von Kindern verwalten, diese Kinder sind dabei immer Window-Objekte und stellen die verschiedenen Fenster einer Applikation dar. Einfache Programme kommen mit einem Kind, d.h. einem Fenster aus. Bei komplizierteren Applikationen, etwa dem Preferences-Programm, ist das Application-Objekt Vater einer ganzen Familie von Unterfenstern. Jedes Fenster (Window-Objekt) hat selbst ebenfalls wieder ein Kind, allerdings diesmal genau eines. Dieses Kind ist normalerweise ein Objekt der Group-Klasse und stellt die Gesamtheit aller Elemente im Fenster dar. Wie erwartet haben natürlich auch Group-Objekte Kinder, die entweder direkt irgendwelche Elemente darstellen (z.B. einen Text oder ein String-Gadget) oder ihrerseits auch wieder Gruppen mit eigenen Kindern sind. Um die Familienverhältnisse nochmal klar zu machen, hier ein kleines Beispiel wie eine MUI Applikation aufgebaut sein könnte: +-------------+ ! Application ! +-------------+ ! ... ------+---------------+-----------------+------ ... ! ! +--------+ +--------+ ! Window ! ! Window ! +--------+ +--------+ ! ! +-------+ ! Group ! ... +-------+ ! +------------+-+--------+-----------------+ ! ! ! ! +--------+ +-------+ +------+ +-------+ ! String ! ! Group ! ! Text ! ! Group ! +--------+ +-------+ +------+ +-------+ ! ! +-----+-----+ +-----------+-----------+ ! ! ! ! ! +------+ +-------+ +------+ +-------+ +--------+ ! List ! ! Cycle ! ! List ! ! Group ! ! String ! +------+ +-------+ +------+ +-------+ +--------+ ! +-----+-----+ ! ! +-------+ +-------+ ! Radio ! ! Radio ! +-------+ +-------+ Diese hierarchische Gliederung spiegelt sich auch im Source-Code von MUI Applikationen wieder. Die Spezifikation einer kompletten Applikation geschieht dabei prinzipiell in einem einzigen großen Befehl, der als Ergebnis das Application-Object zurückliefert. Innerhalb dieses Befehls werden, quasi als Parameter des jeweils übergeordneten Objekts, die Kinder und Kindeskinder mitgeneriert. Objekt-Handling =============== Ein MUI-Objekt wird mit dem Befehl Object * MUI_NewObject(STRPTR class, Tag tag1, ..., TAG_DONE); aus der `muimaster.library' generiert. Der Parameter `class' gibt dabei den Namen der Klasse des Objekts an (z.B. `MUIC_Window', `MUIC_Slider',...). Sollte sich die gewünschte Klasse noch nicht im Speicher befinden, so wird sie (und die eventuell benötigten Superklassen) automatisch nachgeladen. Mit den Werten der Tagliste können dem Objekt gleich zum Zeitpunkt des Erstellens bestimmte Attribute mitgegeben werden. Was das für Attribute sein können hängt natürlich von der Klasse des Objekts ab. Ein Aufruf um ein String-Objekt zu generieren könnte zum Beispiel so aussehen: MyString = MUI_NewObject(MUIC_String, MUIA_Frame , MUIV_Frame_String, MUIA_String_Contents, "foobar", MUIA_String_MaxLen , 80, TAG_DONE); Wie bereits vorher erwähnt, versteht ein Objekt natürlich neben den Attributen und Methoden seiner eigenen Klasse auch alle diejenigen, die von den übergeordneten Klassen angeboten werden. Nachdem zum Beispiel die String-Klasse Unterklasse der Area-Klasse ist, kann in obigem Beispiel beim Generieren des String-Objekts auch das `MUIA_Frame' Attribut angegeben werden, obwohl die String-Klasse selber damit nichts anzufangen weiß. Ein fertiges Objekt kann mit den normalen BOOPSI Funktionen des Betriebssystems gesteuert werden. Attribute werden mit `SetAttrs() gesetzt' und mit `GetAttr()' abgefragt: char *contents; SetAttrs(MyString,MUIA_String_Contents,"look",TAG_DONE); GetAttr(MUIA_String_Contents,MyString,&contents); printf("Always %s on the bright side of life.",contents); Viele MUI-Klassen bieten außerdem spezielle Funktionen an, die dann mit der `DoMethod()' Routine aufgerufen werden können: DoMethod(mylist,MUIM_List_Remove,42); /* und weg ist der 42. Eintrag... */ Alle Klassen mit ihren Methoden und Attributen werden ausführlich in den beiliegenden Autodocs beschrieben. Ein nicht mehr benötigtes MUI-Objekt kann mit VOID MUI_DisposeObject(Object *obj); gelöscht werden. Natürlich sind danach keine Zugriffe auf Methoden und Attribute dieses Objekts mehr möglich. Beim Löschen von Objekten spielen die Eltern-Kind-Beziehungen eine wichtige Rolle. Wenn ein Objekt, das Kinder verwaltet, gelöscht wird, dann werden automatisch auch alle seine Kinder (und deren Kinder, u.s.w.) mit gelöscht. Normalerweise ist eine Applikation so hierarchisch aufgebaut, daß ein einziger `MUI_DisposeObject()' des Applikations-Objekts genügt um alle dazugehörigen Fenster und Gadgets auf einen Schlag freizugeben. Makros ====== Das Erstellen einer MUI Benutzeroberfläche geschieht prinzipiell durch einen einzigen (großen) `MUI_NewObject()' Befehl, dem als Parameter viele Tags übergeben werden, deren Werte oft selbst wieder geschachtelte Aufrufe von `MUI_NewObject()' enthalten. Durch die große Menge an Funktionsaufrufen würde diese Spezifikation sehr schnell sehr unübersichtlich werden. Um dem vorzubeugen, sind im Include-File für C-Programmierer einige Makros definiert, mit denen viele Befehle abgekürzt werden können. So kann zum Beispiel statt MUI_NewObject(MUIC_Window einfach WindowObject geschrieben werden. Beachtenswert hierbei ist, daß das WindowObject Makro eine öffnende Klammer enthält, also in gewisser Weise einen Funktionsaufruf darstellt. Solche Makros müssen irgendwann mit einem TAG_DONE) bzw. dem dafür vorgesehenen End Makro beendet werden. Neben diesen Halb-Makros sind in `mui.h' auch noch vollständige Objekte definiert, so erzeugt zum Beispiel SimpleButton("Cancel") ein komplettes Button-Objekt. Diese Makros können natürlich direkt in eigenen Applikationen verwendet werden, sind aber andererseits vor allem als Anschauungsmaterial gedacht, denn meistens wird man noch zusätzliche Parameter einfügen wollen. Auch Nicht-C-Programmierer sollten sich `mui.h' einmal näher betrachten, die Datei ist ausführlich dokumentiert und enthält viele interessante Hinweise, wie bestimmte Probleme zu lösen sind. Layout ====== Das Layout eines Fensters, also die Positionen aller darin enthaltenen Elemente, ist bei MUI nicht statisch festgelegt sondern wird dynamisch an die vorhandene Umgebung adaptiert. Dieses Konzept macht es möglich, daß sich Applikationen automatisch an alle Zeichensätze und Fenstergrößen anpassen, ohne daß der Programmierer dadurch belastet wird. Um nun festzulegen, wie ein Fenster aufgebaut ist, bedient man sich bei MUI der bereits erwähnten Gruppenobjekte. Ein Gruppenobjekt hat über bestimmte Parameter die Möglichkeit, Positionen und Größen seiner Kinder zu beeinflussen. So gibt es etwa horizontale oder vertikale Gruppen, oder sogar Gruppen die ihre Kinder in ein zweidimensionales Raster zwingen. Dazu ein kleines Beispiel. Es soll das Layout für einen File-Requester erstellt werden. Dieser Requester sieht grob gegliedert folgendermaßen aus: +---------------------------------------+ ! ! ! +------------------------+ +------+ ! ! ! ! ! ! ! ! ! C (dir) ! ! dh0: ! ! ! ! Classes (dir) ! ! dh1: ! ! ! ! Devs (dir) ! ! dh2: ! ! ! ! Expansion (dir) ! ! df0: ! ! ! ! ... ! ! df1: ! ! ! ! Trashcan.info 1.172 ! ! df2: ! ! ! ! Utilities.info 632 ! ! ram: ! ! ! ! WBStartup.info 632 ! ! rad: ! ! ! ! ! ! ! ! ! +------------------------+ +------+ ! ! ! ! Path: _____________________________ ! ! ! ! File: _____________________________ ! ! ! ! +------+ +--------+ ! ! ! Okay ! ! Cancel ! ! ! +------+ +--------+ ! ! ! +---------------------------------------+ Dieses Layout muß nun in horizontale und vertikale Gruppen untergliedert werden. In diesem Fall würde das Fenster aus einer vertikalen Gruppe mit vier Kindern bestehen, wobei das erste und das vierte Kind ihrerseits wieder Gruppen sind, die diesmal horizontale Kinder beinhalten. In MUI würde eine derartige Spezifikation (vereinfacht) so aussehen: VGroup, Child, HGroup, Child, FileListview, Child, DeviceListview, End, Child, PathGadget, Child, FileGadget, Child, HGroup, Child, OkayButton, Child, CancelButton, End, End; Mehr muß der Programmierer bezüglich des Layouts nicht festlegen. Alle Objekte kennen ihre Minimal- und Maximalgrößen und werden vom MUI System je nach Größe des zu Grunde liegenden Fensters automatisch angeordnet. Natürlich kann man den Layout-Prozeß auf vielfältige Weise beeinflussen, etwa durch das Einfügen von Space-Objekten oder durch unterschiedliche Gewichtung einzelner Elemente. Genauere Informationen dazu finden sich in den Autodocs. Objekt-Kommunikation ==================== Das zentrales Element bei der Steuerung einer MUI Applikation ist der Notification-Mechanismus. Damit können beliebige Objekte miteinander verbunden werden. Gut geeignet um diese Fähigkeiten zu demonstrieren ist ein Listview. Dieser besteht normalerweise aus einer Liste mit einigen Einträgen und einem Scrollbalken um sich in dieser Liste zu bewegen. Die Position an der sich die oberste Zeile einer Liste gerade befindet, kann mit dem Attribut `List_TopPixel' bestimmt werden. Nun soll diese spezielle Liste ja von einem Scrollbalken gesteuert werden. Auch ein Scrollbalken besitzt ein Attribut (`Prop_First'), das dessen Position angibt. Dieses Attribut ändert sich natürlich selbstständig, wenn ein Benutzer den Balken verschiebt. Um nun beide Elemente, die Liste und den Scrollbalken miteinander zu verbinden, bedient man sich der Notify-Methode: DoMethod(ScrollbarObject,Notify,Prop_First,EveryTime, ListObject,3,Set,List_TopPixel,TriggerValue); Im Klartext: Immer dann, wenn sich beim Scrollbar-Objekt das Attribut `Prop_First' ändert, dann soll beim List-Objekt das Attribut `List_TopPixel' auf den entsprechenden Wert gesetzt werden. Fortan sind Liste und Scrollbalken miteinander verbunden. Sobald das Proportional-Gadget bewegt wird, ändert sich die Position der Liste entsprechend, ohne daß der Programmierer hier noch irgendwie eingreifen muß. Es gibt in MUI bereits ein fertiges Listview-Objekt, das die gerade erwähnte (und noch einige andere) Verbindungen selbständig vornimmt, aber der Notify-Mechanismus läßt sich noch für viele andere Aufgaben hervorragend gebrauchen. Im `MUI-Demo' Programm werden damit zum Beispiel die einzelnen Button-Gadgets mit den dazugehörigen Fenstern verbunden, so daß ein Anklicken eines Knopfes automatisch das jeweilige Fenster öffnet. Weitergehende Informationen finden sich auch hier in den Autodocs zur Notify-Klasse. Dynamische Objekt-Verwaltung ============================ Dieser Abschnitt behandelt die dynamische Verwaltung von MUI-Objekten. Dabei werden während der Laufzeit eines Programms Eltern-Kind-Beziehungen aufgebrochen und neu erstellt. Normalerweise wird die komplette Benutzeroberfläche einer Applikation komplett mit einem einzigen Befehl generiert. Das hat zum einen den Vorteil, daß alle Objekte jederzeit existieren und man ständig auf sie zugreifen kann, zum anderen wird die Fehlerbehandlung extrem einfach. Es kann aber durchaus Fälle geben, in denen es sinnvoll ist, bestimmte Fenster erst zu generieren, wenn sie wirklich benötigt werden: etwa wenn eine Applikation sehr viele Unter-Fenster bietet und diese zusammen zu viel Speicher verbrauchen würden, oder wenn Anzahl und Inhalt der benötigten Fenster beim Starten der Applikation noch gar nicht bekannt ist. Für solche Fälle bietet MUI die Möglichkeit des Late-Bindings. Damit können Kinder auch noch nachträglich an Objekte gehängt bzw. von ihnen entfernt werden. MUI benutzt dazu die beiden Methoden OM_ADDMEMBER und OM_REMMEMBER: DoMethod(parent,OM_ADDMEMBER,child); /* Kind anfügen */ DoMethod(parent,OM_REMMEMBER,child); /* Kind wegnehmen */ Diese beiden Methoden werden in MUI nur von der Application- und der Group-Klasse unterstützt, das sind auch die beiden einzigen Klassen, die mehrere Kinder verwalten können. Einer Sache ist besondere Aufmerksamkeit zu schenken: bei Objekten die keine Eltern mehr haben, sei es weil sie noch nicht mittels `OM_ADDMEMBER' irgendwo angehängt wurden oder weil sie mittels `OM_REMMEMBER' entfernt wurden, ist der Programmierer für das Löschen mittels `MUI_DisposeObject()' verantwortlich. Andererseits dürfen Objekte die noch Kind eines anderen Objekts sind unter keinen Umständen gelöscht werden! Dynamische Fenster ------------------ Angenommen, eine Applikation ist bereits fertig erstellt und es soll ein neues, d.h. noch nicht vorhandenes Fenster geöffnet werden. Dazu muß das Fenster-Objekt zunächst einmal generiert werden: win = WindowObject, MUIA_Window_Title, "New Window", WindowContents, VGroup, Child, ..., Child, ..., Child, ..., End, End, End; if (!win) fail(); /* Hier muß eine Sicherheitsabfrage erfolgen! */ Nachdem das Fenster-Objekt fertig generiert wurde, kann es als Kind an die Applikation angefügt werden: DoMethod(app,OM_ADDMEMBER,win); Das Fenster ist jetzt ganz normal Teil der Applikation, genauso als wenn es direkt als SubWindow gleich mit dem Applikations-Objekt generiert worden wäre. Es kann jederzeit durch Setzen der entsprechenden Attribute geöffnet oder geschlossen werden und wird durch ein Löschen der Applikation automatisch mit gelöscht. Normalerweise wird man das Fenster jedoch gleich nach Benutzung wieder komplett löschen wollen, sonst würde sich der ganze Aufwand des Late-Bindings nicht unbedingt lohnen. Nach einem set(win,MUIA_Window_Open,FALSE); kann man mittels DoMethod(app,OM_REMMEMBER,win); das Fenster aus der Applikation entfernen. Danach muß das Fenster-Objekt von Hand gelöscht werden, die Applikation kann diese Aufgabe jetzt nicht mehr übernehmen: MUI_DisposeObject(win); Mit dieser Methode können leicht Unterprogramme erzeugt werden, die ein Fenster generieren, dort irgendwelche Eingaben erwarten und dann ein bestimmtes Ergebnis zurückliefern. Hier nochmal in kurz der Ablauf eines solchen Unterprogramms: set(app,MUIA_Application_Sleep,TRUE); // andere Fenster disablen win = WindowObject, ...., End; // neues Fenster generieren if (win) // Sicherheitsabfrage { DoMethod(app,OM_ADDMEMBER,win); // Fenster hinzufügen... set(win,MUIA_Window_Open,TRUE); // und öffnen while (running) { switch (DoMethod(app,MUIM_Application_Input,&sigs)) { ... // Eigener Input-Loop, nur für dieses Fenster. ... // Achtung: Auch hier sollte der Spezial-Wert ... // MUIV_Application_ReturnID_Quit beachtet werden! } } set(win,MUIA_Window_Open,FALSE); // Fenster schließen, DoMethod(app,OM_REMMEMBER,win); // removen MUI_DisposeObject(win); // und vernichten. } set(app,MUIA_Application_Sleep,FALSE); // restliche app aufwecken Dynamische Gruppen ------------------ Ebenso wie Fenster nachträglich in eine Applikation eingefügt werden, können auch Elemente an bereits bestehende Gruppen-Objekte angehängt werden. Nützlich ist das zum Beispiel, wenn eine Gruppe viele gleichartige Kinder beinhaltet oder wenn die Anzahl der Kinder einer Gruppe nicht im vorhinein bekannt ist. Man kann jederzeit neue Elemente an Gruppen anhängen bzw. Elemente aus Gruppen aushängen, allerdings darf das Fenster in dem sich diese Gruppen befinden dabei nicht geöffnet sein! Ein kleines Beispiel für diese Technik: app = ApplicationObject, ..., SubWindow, win = WindowObject, WindowContents, VGroup, ..., grp = VGroup, End, End, End, End; /* Hier wurde die Gruppe grp zunächst ohne Kinder erzeugt, */ /* so dürfte das Fenster nicht geöffnet werden. */ for (i=0; i