MUI - MagicUserInterface

Ein System zum Erstellen und Verwalten von grafischen Benutzeroberfächen

- Benutzerhandbuch -

Version 1.4 19. Oktober 1993

Stefan Stuntz

Copyright \begin{matrix}c \\ ◯ \end{matrix} 1993 Stefan Stuntz

1 Einführung

1.1 Das Konzept von MUI

MagicUserInterface, abgekürzt MUI, ist ein komplettes System zum Erstellen und Verwalten von grafischen Benutzeroberflächen. Das Generieren 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 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 besteht dabei darin, daß nur der Benutzer (und nicht der Programmierer) einer Applikation weiß, wie diese auf seinem persönlichen Gerät am Besten aussieht. Deswegen enthalten MUI Programme auch so gut wie keine absoluten Größenund 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.

1.2 Systemanforderungen

MUI läuft mit allen Betriebssystemversionen ab Kickstart 2.0 und ist so programmiert daß es auch unter allen folgenden Versionen arbeitet. Einige besondere Features bleiben jedoch den Besitzern von aktuellen Betriebssystemversionen (Kickstart 3.0 oder aufwärts) vorbehalten. 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.

1.3 Installation

MUI wird mit dem Abschnitt 4.8 [POL İNSTALLER], Seite 30 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.

Eine funktionsfähige MUI Installation besteht aus der ‘muimaster.library’ im ‘libs:’ Verzeichnis sowie den Unterlibraries für die einzelnen Bedienungselemente im Verzeichnis ‘libs:mui/’. Außerdem sollte sich das Preferences Programm zusammen mit den Voreinstellern der Workbench im ‘libs:Prefs’ Ordner befinden. Bei Verwendung des Installers braucht man sich über die Anordnung jedoch keine Gedanken zu machen, die Dateien werden automatisch an die richtigen Positionen kopiert.

2 Bedienen von MUI-Applikationen

2.1 Fenster

MUI Applikationen verhalten sich zunächst wie ganz normale Amiga-Programme und können auch so bedient werden. Allerdings bieten sie zusätzlich noch einige Features, die im folgenden etwas näher erläutert werden sollen.

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 nachträglich im Abschnitt 3.1 [PRF İNTRO], Seite 8 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.

2.2 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 Abschnitt 2.3 [USE ĊYCLE], Seite 6 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 Listview 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 Abschnitt 3.10 [PRF K̇EYBOARD], Seite 19).

2.3 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 Abschnitt 3.4 [PRF L̇ISTVIEWS], Seite 10).

2.4 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.

2.5 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.

3 Preferences-Programm

3.1 Allgemeines

Bei herkömmlichen Applikationen hat man als Benutzer normalerweise keine, oder nur sehr eingeschränkte Möglichkeiten, das Aussehen und die Funktionalität der Benutzeroberfläche zu beeinflussen. Man ist dem Programmierer gewissermaßen hilflos ausgeliefert und muß sich seinem Geschmack unterordnen bzw. anpassen.

Im Gegensatz dazu ist die Oberflächengestaltung bei MUI Applikationen wesentlich flexibler. Der Programmierer macht hier so gut wie gar keine Angaben über das eigentliche Aussehen von Bedienelementen, er legt lediglich deren Typ und gewisse Parameter fest. Wie diese Elemente dann letztendlich auf dem Bildschirm erscheinen, liegt fast ausschließlich in den Händen des Benutzers.

So würde zum Beispiel ein Programmierer im Falle eines File-Requesters lediglich spezifizieren, daß sein Fenster oben eine Dateiliste, darunter ein Pfad- und ein Datei-Eingabefeld und darunter wiederum einen OK- und einen Abbruch-Knopf besitzen soll. Er macht jedoch keinerlei Vorgaben bezüglich Größen, Farben oder Zeichensätzen. Alle diese, und noch viele andere Gesichtspunkte der Bedienoberfläche können vom Benutzer einer Applikation jederzeit nachträglich verändert und an den persönlichen Geschmack angepaßt werden.

Zum Vornehmen aller dieser Einstellungen dient nun das MUI Preferences Programm. Es befindet sich nach erfolgter Installation mit dem Installer im Prefs Ordner auf der System-Partition und wird einfach durch Doppelklick gestartet.

3.2 Hauptfenster

Das Hauptfenster des Preferences-Programms läßt sich in drei Bereiche untergliedern. Am linken Rand befindet sich eine Applikations-Liste, rechts daneben die Einstell-Seiten und am unteren Fensterrand eine Leiste mir vier Knöpfen.

Die Applikationsliste ermöglicht es, sämtliche Einstellungen nach Applikationen getrennt vorzunehmen. Sie zeigt dazu automatisch die Namen der bereits einmal gestarteten Programme an. Alle Voreinstellungen beziehen sich immer auf das Programm, dessen Name gerade aktiv ist. Es ist also ohne weiteres möglich, verschiedenen Applikationen völlig verschiedene Oberflächen-Outfits zu verpassen, in wie weit das auch sinnvoll ist, sei dahingestellt.

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.

Die eigentlichen Einstellungen werden dann auf der rechten Seite des Fensters getroffen. Hier befindet sich der - in Seiten aufgeteilte - Konfigurationsbereich. Die Seiten können mit dem Cycle-Gadget am obereren Rand, oder auch mit den Einträgen im Page-Menü, durchgeschaltet werden. Die einzelnen Elemente der verschiedenen Seiten werden in den folgenden Kapiteln ausführlich beschrieben.

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.

3.3 Spacing-Seite

Auf dieser Seite können einige Werte eingestellt werden, die ganz allgemein den Freiraum zwischen bestimmten Bedienungselementen festlegen. Weitergehende Einstellungen zum Thema Abstand finden sich auch noch auf der Abschnitt 3.5 [PRF ḞRAMES], Seite 12.

Die ersten vier Schieberegler bestimmen dabei pixelgenau den Abstand, der zwischen dem Rahmen des Fensters und dessen Inhalt eingefügt wird. 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.

Die beiden ‘Group’-Werte beeinflussen den Abstand der zwischen horizontalen bzw. vertikalen Gruppen eingefügt wird. Die ‘Radio’ Schieberegler sind für das Aussehen der (selten benutzten) Radio-Button Gadgets verantwortlich.

3.4 Listviews-Seite

Hier finden sich gesammelt einige Konfigurationsmöglichkeiten für Listen und Popup-Menüs.

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.

Das Smoothing ist nur dann aktiv wenn die Listviews auch wirklich pixelorientiert arbeiten. Normalerweise wird immer nur um ganze Zeilen gescrolled, die Pixel-Orientierung muß erst mit dem ‘Pixel’-Gadget eingeschaltet werden.

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.

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.

3.5 Frames-Seite

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, bei denen 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.

− Popup-Frame

für die Rahmen der Cycle-Gadget Popup-Menüs. − Virtual-Frame

für die Einrahmung der (bisher selten benutzten) virtuellen Gruppen.

Durch einen Doppelklick auf einen Eintrag in der Liste oder mit dem ‘Edit’-Gadget wird ein Rahmen-Konfigurations-Fenster aufgerufen. Wie die meisten anderen Unter-Fenster im Preferences-Programm, arbeitet auch das Rahmen-Konfigurations-Fenster parallel. Es ist sogar möglich, mehrere dieser Fenster auf einmal zu öffnen. Die darin getroffenen Einstellungen werden jedoch erst wirksam, wenn sie explizit mit dem ‘OK’-Knopf bestätigt werden.

3.5.1 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.

3.6 Images-Seite

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’, ‘Network’, ‘Assign’

Images für Einträge in einem File-Requester.

 − ‘TapePlay’, ‘TapePlayback’, ‘TapePause’, ‘TapeStop’, ‘TapeRecord’

Images für Tapedeck-Anwendungen.

 − ‘Prop-Gadget Knob’

Schieberegler im Proportionalgadget.

Ein Doppelklick oder der jeweilige ‘Edit’-Button am Ende der Liste öffnen für den gerade aktiven Eintrag das Image-Konfigurations-Fenster.

3.7 Backgrounds-Seite

Bei MUI kann man für viele Objekte verschiedene Hintergrund-Farben/Pattern einstellen. Wenn man das Glück hat, mit einer leistungsfähigen Grafikkarte arbeiten zu können, sollte man hier undedingt ein wenig experimentieren. Leicht unterschiedliche Grautöne für Fenster-, Buttonund Listview-Hintergründe geben einer Oberfläche ein wesentlich professionelleres und vor allem übersichtlicheres Aussehen als man es von normalen Programmem gewohnt ist.

− ‘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.

− ‘Virtual Groups’

findet sich als Hintergrund von virtuellen Gruppen.

Auch hier öffnet ein Doppelklick oder der jeweilige ‘Edit’-Button am Ende der Liste für den gerade aktiven Eintrag das Image-Konfigurations-Fenster.

3.7.1 Image-Einstellungen

In diesem Fenster kann jeweils für ein Standard-Image oder für einen der vorher aufgeführten Hintergründe ein bestimmtes Aussehen konfiguriert werden. MUI bietet dabei einige verschiedene Möglichkeiten an, die mit dem Cycle-Gadget am oberen Fensterrand angewählt werden können.

− Builtin 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-Image

Für (fast) alle Standard-Images ist in MUI jeweils ein Typ fest eingebaut. Diese eingebauten Images sind aus Vektoren zusammengesetzt und können sich daher in ihrer Größe jeweils an den verwendeten Zeichensatz anpassen.

− RGB-Color-Specification (nur Kickstart 3.0 oder höher)

Hier kann mit den bekannten RGB-Schiebereglern und falls vorhanden mit einem Farbrad einfach eine beliebige Farbe definiert werden, die dann für den entsprechenden Hintergrund verwendet werden soll.

− Extern Boopsi Image

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.

− Special MUI Brush

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.

− Alien-Images (nur Kickstart 3.0 oder höher)

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.

3.8 Fonts-Seite

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.

3.9 Screens-Seite

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 dreier Elemente die dem Default Public Screen, dem Workbench Screen oder dem gerade vordersten Public 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.

3.9.1 Screen Einstellungen

In diesem Fenster können Auflösung, Farbpalette sowie einige weitere Daten eines neuen Public-Screens eingestellt werden. Das Fenster ist deswegen auch in drei Seiten unterteilt, die mit dem Cycle-Gadget am oberen Rand umgeschaltet werden können.

Auf der ‘Attributes’-Seite finden sich im einzelnen folgende Einstellmöglichkeiten:

Im ‘Public Name’ String Gadget kann man einen Namen festlegen, unter dem der Bildschirm später referenziert wird. Um Verwechslungen zu vermeiden, sollten alle im System verwendeten Public Screens 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. Das ‘Background’- Gadget ist nur unter Kickstart 3.0 oder höher verfügbar und erlaubt die Konfiguration eines Hintergrundbildes. Hier werden wieder die ‘Datatypes’ verwendet, man kann dadurch die verschiedensten Bildformate verwenden.

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 Kickstart 3.0).

 − ‘Interleaved’

Dieses Attribut vermindert falls gesetzt das Flimmern das besonders beim Scrollen von Listen auf vielfarbigen Screens auftritt (erst ab Kickstart 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.

Die Auflösung und Größe eines Bildschirms läßt sich auf der ‘Display Mode’ Seite einstellen. In einer Liste werden dazu alle verfügbaren Modi angezeigt. Außerdem finden sich am unteren Fensterrand Gadgets für Breite, Höhe und Tiefe sowie eine Einstellung für den zu verwendenden Overscan-Typ.

Die Farbpalette eines Bildschirms kann man schließlich mit Hilfe der ‘Palette’-Seite bestimmen. Am linken Rand befindet sich zu diesem Zweck eine Liste, in der alle auf dem neuen Bildschirm verwendeten Farbstifte aufgeführt sind. Für jeden dieser Stifte kann mit Hilfe der Schieberegler rechts eine beliebige Farbe gewählt werden.

Meistens wird man nicht allen Stiften eine eigene Farbe zuweisen wollen, schon gar nicht wenn durch die gewählte Farbtiefe nicht genug Farben zur Verfügung stehen. Um diesem Umstand Rechnung zu tragen, kann man in der Farb-Liste beliebige Elemente zu Gruppen zusammenfassen und deren Farbe gesammelt bestimmen. Wenn ein Element einer Gruppe angewählt wird, werden alle anderen Mitglieder dieser Gruppe ebenfalls selektiert. Um einer Gruppe ein neues Element hinzuzufügen, muß dieses bei gedrückter Shift-Taste angeklickt werden. Zum entfernen eines Elements aus einer Gruppe genügt ein Doppelklick.

3.10 Keyboard-Seite

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’.

Änderungen werden nur nach Bestätigung durch die Return-Taste im String-Gadget akzeptiert. Vorher wird der eingegebene String allerdings noch auf Korrektheit überprüft und gegebenenfalls zurückgewiesen.

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.

3.11 System-Seite

Auf der System-Seite 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.

Beim Neuzeichnen eines Fensters bietet MUI ebenfalls zwei verschiedene Möglichkeiten an, die mit dem ‘Window Redraw’ Gadget eingestellt werden können. In der Einstellung ‘fast/ugly’ wird vor einem Neuzeichnen (nach einer Resize-Operation) zunächst der komplette Fensterinhalt gelöscht, das nachfolgende Zeichnen geht dann etwas schneller als im ‘slow/nice’ Modus wo das Löschen unterbleibt.

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.

3.12 General-Seite

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 Abschnitt 3.7.1 [PRF İMAGES ĖDIT], Seite 16 der entsprechende Knopf gedrückt wird.

3.13 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 (vorher konfigurierten) Public Screens

OPEN: Screen öffnen

CLOSE: Screen schließen

3.14 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 Abschnitt 2.5 [USE ȦREXX], Seite 6 verwendet werden.

4 Sonstiges

4.1 Registration

“MagicUserInterface” ist ein umfangreiches Produkt, in das ich viel Arbeit und Zeit (und wahrscheinlich ein Semester meines Studiums) investiert habe. Ich hoffe allerdings, daß sich diese Arbeit gelohnt hat und daß schon bald viele - auf MUI basierende - Applikationen mit schönen und flexiblen Benutzeroberflächen verfügbar sind.

Damit auch der finanzielle Aspekt nicht ganz unberücksichtigt bleibt, habe ich mich entschlossen, MUI als Shareware zu vertreiben. Mit der unregistrierten Version ist das Speichern einiger Einstellungen im Preferences-Programm nicht möglich. Diese Einschränkungen beeinflussen allerdings in keinster Weise die Funktionalität von Applikationen, alle wichtigen Parameter (etwa Fenster-Positionen, Public-Screens und System-Einstellungen) sind auch ohne Registrierung möglich. Für die übrigen Werte werden dann die integrierten Standard-Einstellungen verwendet, auch damit sind MUI Applikationen immer noch funktioneller und attraktiver als die meisten anderen Programme.

Wer allerdings die weitergehenden Möglichkeiten von MUI (verschiedene Zeichensätze, Rahmen, Images, Hintergrund-Pattern) nutzen möchte, der sollte sich registrieren lassen. Registrierte Benutzer erhalten eine Diskette mit der jeweils aktuellsten Version, zusammen mit einem Keyfile. Mit diesem Keyfile können dann sämtliche Einstellungen im Preferences-Programm abgespeichert werden und stehen dauerhaft zur Verfügung. Natürlich bleibt das Keyfile für alle zukünftigen Versionen von MUI gültig, spätere Updates können also einfach von Mailboxen oder PD-Disketten bezogen werden.

Der Preis für eine Registrierung beträgt

     20.- DM  (D-Mark),
     20.- SFr (Schweizer Franken),
     90.- FF  (French Francs),
     15.- US$ (US-Dollar)

oder einen Betrag in irgendeiner anderen Währung der 20.- US$ (zwanzig!) entspricht. Zwanzig deswegen weil ich das Geld dann bei meiner Bank umtauschen und dafür Gebühren bezahlen muß.

Als schnellster und einfachster Weg sich registrieren zu lassen bietet sich an, das beiliegende Bestellformular auszufüllen und es in einem Brief zusammen mit dem Geld an die folgenden Adresse zu schicken:

Stefan Stuntz
Eduard-Spranger-Straße 7
80935 München
DEUTSCHLAND

Statt Bargeld können natürlich auch Euro-Cheques verwendet werden, allerdings bitte ich von Auslands-Cheques abzusehen, diese einzulösen kostet teilweise unverschämt hohe Gebühren.

Innerhalb Deutschlands kann man die Registration auch einfach per Banküberweisung an die

Stadtsparkasse München, BLZ 701 500 00, Konto 35-169929

durchführen. Dabei ist unbedingt darauf zu achten, daß auf dem Überweisungsformular unter ‘Verwendungszweck’ die komplette Anschrift angegeben wird.

Alle Registrierungen werden schnellstmöglich bearbeitet und sollten im Inland innerhalb von ein bis zwei Wochen ausgeliefert werden. Bedingt durch die Postlaufzeiten kann eine Auslandsregistrierung etwas länger dauern. Deswegen gibt es für MUI in einigen Ländern Registration Sites:

− U.S.A. und Kanada

Robert Blayzor
P.O. Box 807
Johnstown, NY 12095-0807
Phone: (518) 883-5326 (data/fax/bbs)
electronic mail:
InterNet/UUCP: robertb@liquid.albany.ny.us
      FidoNet: 1:267/131.0
     AmigaNet: 40:714/1.0
       C-Link: 911:6150/1.0
Make all payments payable to: Robert Blayzor
Acceptable payment methods: US Money Orders & Bank/Personal Checks
Personal checks must wait 10-15 days to clear unless certified!
(All payments in US dollars ONLY!)

4.2 Updates

Wann immer eine neue Version von MUI erscheint, wird das in den entsprechenden Brettern einiger Datennetze angekündigt werden. Das neue Archiv findet sich dann sicher bald in vielen Mailboxen und ist außerdem auf allen ‘aminet’ ftp-servern zu bekommen. Größere Updates werden auch auf PD-Disks erhältlich sein.

In der MUI Support Mailbox ‘Amiga Unlimited’ (Node 1: +49-8151-78880 [HST/V32bis], Node 2: +49-8151-290282 [ISDN X.75/V110], Sysop Andreas Schildbach) kann man die jeweils aktuelle Version entweder per Fido Request an 2:246/46 unter dem Namen ‘MUI’ oder durch einloggen mit dem Usernamen ‘Download MUI’ und dem Passwort ‘MUI’ erhalten. In Amerika ist der Fido File Request bei 1:267/131 (HST/V32bis) möglich.

Wie bereits erwähnt, brauchen registrierte Benutzer weder ein neues Keyfile noch irgendwelche speziellen Programmversionen, Updates können sofort mit allen ihren Möglichkeiten genutzt werden.

Natürlich werden alle zukünftigen MUI Versionen zu den vorher erschienenen vollständig kompatibel sein. Applikationen die mit MUI 1.0 entwickelt worden sind, werden auch noch nach geraumer Zeit unter MUI 7.0 ihren Dienst versehen. Sie werden dabei automatisch von eventuellen Verbesserungen im Design oder in der Funktionalität der Oberfläche profitieren.

4.3 Support

Ich werde mich bemühen, alle Anfragen bezüglich MUI schnellstmöglich zu beantworten. Dabei werden die Probleme von registrierten Benutzern bevorzugt behandelt. Bitte wann immer möglich electronic mail als Kommunikationsmedium verwenden, das ist sowohl billiger als auch schneller, schont die Umwelt und erleichtert die Arbeit.

     Sackpost: Stefan Stuntz
     ~         Eduard-Spranger-Straße 7
     ~         80935 München
     ~         DEUTSCHLAND
      Telefon: +49-89-313-1248
       e-mail: stuntz@informatik.tu-muenchen.de

4.4 Danksagungen

MUI entstand aus der Enttäuschung darüber, wie wenig Unterstützung einem Programmierer beim Erstellen von Benutzeroberflächen seitens des Betriebssystems gewährt wird. Meine ersten Denkanstöße in Richtung objektorientierter Oberflächengestaltung erhielt ich von Armin Sander, bei dem ich mich an dieser Stelle für die vielen Tips herzlich bedanken möchte. Er hat damit den Grundstein für MUI gelegt.

Ohne die tatkräftige Mithilfe meiner Betatester wäre MUI sicher niemals fertiggestellt worden. Dabei beschränkten sich ihre Aufgaben nicht nur auf bloßes Ausprobieren sondern vor allem auch auf das Erstellen der mitgelieferten Beispielprogramme. Daß aus einigen dieser Beispielprogramme richtige Applikationen geworden sind, macht das große Engagement und die Begeisterung mit der sie alle bei der Sache waren um so mehr deutlich.

Im einzelnen haben mitgeholfen:

− Stefan Becker … hat trotz chronischen Zeitmangels einige wertvolle Tips und Hinweise gegeben. Außerdem waren mir Teile seines ToolManager Sourcecodes bei der Entwicklung von MUI eine große Hilfe.

− Martin Berndt … hat mich beim Lösen einiger kniffliger Probleme unterstützt. − Robert Blayzor … hat die englische Anleitung überarbeitet. − Dirk Federlein … erstellte die MUI-Applikation ‘DFView’. Bei über 100 kByte Sourcecode

inclusive Sprachen-Anpassung und Anleitung in drei verschiedenen Formaten wage ich es nicht mehr, nur von einem Beispielprogramm zu sprechen. Außerdem hat Dirk zu meiner großen Freude einige Teile dieser Dokumentation ins Englische übersetzt.

− Georg “gucky” Heßmann … hat in der Endphase noch einige Bugs aufgedeckt und das Demo-Programm ‘DVIprint’ beigesteuert.

− Martin Horneffer und Albert Weinert

… von ihnen stammt das Oberon-Interface. − Martin “XEN” Huttenloher

… hat viele der mitgelieferten Images gezeichnet und auch beim sonstigen MUI-Design entscheidend mitgewirkt. Außerdem stammen von ihm die wunderschönen Hintergrund-Patterns, die ein kleiner Auszug seines ‘MagicWB’-Pakets sind. Freunde einer ansprechenden, plastischen Workbench sollten sich sein Paket ‘MagicWB’ unbedingt einmal näher betrachten!

− Oliver “Mr.Coffee” Kilian … hat MUI auf dem guten alten (und langsamen) 68000er getestet.

− Klaus “kmel” Melchior … schrieb die beiden Beispiel-Programme ‘WbMan’ und ‘MUI-Exchange’ und endlose Listen von Bug-Reports. Außerdem war er beim Korrektur-Lesen der Autodocs mit Abstand am fleißigsten, malte die Icons der Demo-Programme und schrieb ein paar boopsi Images.

− Wouter van Oortmerssen

… für das Amige-E Interface. − Matthias “tron” Scheler und Markus “corwin” Stipp

… haben die erste richtige MUI Applikation geschrieben, einen Message-Editor für das Universal Mail System (UMS). Look out for ‘IntuiNews’! Außerdem stammt von Matthias das Beispiel-Programm ‘Font’.

− Andreas “goonie” Schildbach … hat MUI-Design und -Funktionsumfang entscheidend beeinflußt, von ihm stammt unter anderem ein kompletter Satz MUI-Images. Außerdem schreibt er ebenfalls mehrere Applikationen, eine davon ist eine Telefon- und Anrufbeantworter-Software für isdn. Andreas hat mich durch die wie immer endlosen Telefongespräche auch mal auf andere Gedanken gebracht.

− Wolfgang Schildbach

… für seinen Text-Formatierungs-Code. − Christian “Kochtopf” Scholz

… für das Modula-Interface. − Ibrahim “radi” Solmaz

… der mich ebenfalls durch viele Telefonate von der Arbeit abhielt, mir aber trotzdem manchmal eine wertvolle Hilfe war.

− Henri Veistera … für das Assembler-Interface. Ich hätte nie gedacht, daß man MUI in Assembler programmieren kann.

Das letzte Wort gilt jedoch allen registrierten Benutzern meines File-Requesters MFR. Der Erfolg, den ich mit diesem Programm hatte, bestärkte mich darin, es auch bei MUI auf Shareware-Basis zu versuchen. Deswegen tut es mir besonders leid, daß von MFR so lange kein Update mehr erschienen ist. Die Arbeit an MUI hatte für mich aber zunächst Priorität, insbesondere weil eine nächste Version von MFR vermutlich auf MUI aufbauen wird.

4.5 Diskussion

− "Was bringt MUI überhaupt für Nicht-Programmierer?" In Zukunft werden (hoffentlich) viele Applikationen MUI zum Erstellen ihrer Benutzeroberflächen verwenden. Als Benutzer solcher Applikationen hat man dann vielerlei Möglichkeiten auf deren Aussehen einzuwirken und kann alle nur erdenklichen Dinge an seinen persönlichen Geschmack anpassen. Um alle Features in vollem Umfang nutzen zu können, muß man sich für MUI registrieren lassen.

− "Warum ist MUI so langsam?" MUI ist nicht langsam. Die große Vielfalt und Flexibiltät erfordert jedoch einen deutlich höheren Rechenaufwand als bei den bisher bekannten Benutzeroberflächen. Insbesondere auf langsamen Rechnern kann sich dieser Aufwand unangenehm bemerkbar machen. Beim Starten der ersten MUI Applikation nach einem Reset müssen zudem noch einige Dateien nachgeladen werden, was ebenfalls einige Zeit in Anspruch nehmen kann. Diese Dateien bleiben dann allerdings im Speicher, so daß weitere Programme relativ schnell gestartet werden können. Natürlich könnte man bei MUI einige Dinge beschleunigen und ich versuche auch, jede neue Version etwas schneller als die vorherigen zu machen. Allerdings bin ich nicht bereit, zu Gunsten von ein wenig Geschwindigkeitssteigerung auf Features wie etwa das hohe Maß an Konfigurierbarkeit zu verzichten. Wer heute noch einen 10 Jahre alten 68000er Prozessor mit 7 Megahertz Taktfrequenz verwendet, der muß damit rechnen, daß nicht alle Programme in Hochgeschwindigkeit ablaufen. Die Software entwickelt sich hin zu immer komplexeren Produkten, deren Anforderungen einfach nicht mehr durch veraltete Hardware erfüllt werden können.

− "Warum werden meine Fensterpositionen nicht gespeichert?" Fensterpositionen werden normalerweise nur temporär, d.h. im ram gespeichert und sind nach einem Neustart verloren. Eine dauerhafte Speicherung kann man erreichen, indem man nach Benutzen einer Applikation das MUI Preferences Programm startet und hier das ‘Save’-Gadget angewählt.

− "Wozu dient das schräg schraffierte Feld beim Einstellen der Farb-Palette?" Hier wird normalerweise die gerade eingestellte Farbe angezeigt, allerdings funktioniert dieses Feature erst ab Kickstart 3.0 und außerdem nur dann, wenn auf dem Bildschirm noch freie Farben zur Verfügung stehen.

− "Wie kann man eigene Images malen?" Dazu kann jedes beliebige Malprogramm verwendet werden. Als Ausgangspunkt sollte man am besten das Bild ‘MBrKit.ilbm’ aus dem ‘Images’-Verzeichnis dieser Distribution verwenden.

− "Warum unterstützen die String-Gadgtes kein Clipboard?" Es gibt ein Utility namens ‘NewEdit’, daß allen String Gadgets im System Clipboard-Fähigkeiten verleiht. Auch MUI’s Gadgets arbeiten mit diesem Utility zusammen.

− "Wie bekommt man einen gutaussehenden 3D-Slider im typischen xen-Look?" Dafür müssen einige Optionen folgendermaßen einstellt werden:

− frames: Thickness=thin

− frames: Edit Prop-Frame: Type=Double, Look=Raised und alle Abstände (spacings) auf Null!

− images: Edit Prop-Gadget Knob: Select boopsi-Image ‘mui-xenknob’

− images: Backgrounds: Edit Prop-Gadget Container: Das Pattern ‘Fillback’ wählen (viertes von rechts)

− Schließlich können noch die entsprechenden xen-Arrows (Pfeile) im images-Fenster eingestellt werden. Diese Pfeile sind MUI Brushes, die speziell für den xen-Slider entworfen wurden. Sie müssen mit der Funktion ‘Select: MUI Brush’ im Edit-Fenster geladen werden.

4.6 Disclaimer

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE CO-PYRIGHT HOLDER AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WI-THOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FIT-NESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRI-TING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY REDISTRI-BUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOS-SES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

4.7 License

Diese Lizenz betrifft die Weiterverbreitung des kompletten MUI-Systems. Sie hat mit dem Benutzen von MUI in eigenen Applikationen nichts zu tun, genaue Informationen darüber finden sich im Developer-Archiv.

− This license applies to the product called “MagicUserInterface” (short “MUI”), a collection of programs for the Amiga computer, published by Stefan Stuntz under the concepts of shareware, and the accompanying documentation. The terms “Program” and “MUI” below, refer to this product. The licensee is addressed as “you”.

− You may copy and distribute verbatim copies of the program’s executable code and documentation as you receive it, in any medium, provided that you conspicuously and appropriately publish only the original, unmodified program, with all copyright notices and disclaimers of warranty intact and including all the accompanying documentation, example files and anything else that came with the original.

− Except when otherwise stated in this documentation, you may not copy and/or distribute this program without the accompanying documentation and other additional files that came with the original. You may not copy and/or distribute modified versions of this program.

− You may not copy, modify, sublicense, distribute or transfer the program except as expressly provided under this license. Any attempt otherwise to copy, modify, sublicense, distribute or transfer the program is void, and will automatically terminate your rights to use the program under this license. However, parties who have received copies, or rights to use copies, from you under this license will not have their licenses terminated so long as such parties remain in full compliance.

− By copying, distributing and/or using the program you indicate your acceptance of this license

to do so, and all its terms and conditions. − Each time you redistribute the program, the recipient automatically receives a license from

the original licensor to copy, distribute and/or use the program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.

− You may not disassemble, decompile, re-source or otherwise reverse engineer the program. − You agree to cease distributing the program and data involved if requested to do so by the

author.

4.8 Installer

Mit MUI wird der Installer von Commodore ausgeliefert, der die Installation des Programmpakets auf Festplatte erheblich erleichtert. Für dieses Tool gelten die folgenden Bestimmungen:

Installer and Installer project icon
(c) Copyright 1991-93 Commodore-Amiga, Inc.  All Rights Reserved.
Reproduced and distributed under license from Commodore.
INSTALLER SOFTWARE IS PROVIDED "AS-IS" AND SUBJECT TO CHANGE;
NO WARRANTIES ARE MADE. ALL USE IS AT YOUR OWN RISK. NO LIABILITY
OR RESPONSIBILITY IS ASSUMED.