Inhaltsverzeichnis

  Einleitung  4

1  Grundlegendes  5

1.1  Software und Analysetechnik  5

1.2  Problemstellung  5

2  Hardware  6

2.1  OFSP Open Frame Smart Panel  6

3  Betriebssoftware  7

3.1  Embedded-Systems  7

3.2  Windows CE TM  7

3.3  Ultratronik Linux Distribution  8

3.4  X-Window Systeme  8

3.5  Cross-Compiler  9

4  Nano-X Die schlanke X-Window Variante  11

4.1  Gesamtüberblick  11

4.2  Lizenz und Bedingungen  12

4.3  Einrichtung des Systems  12

4.4  Einführung in die Nano-X Programmierbibliothek  14

4.4.1  Fenster  16

4.4.2  Graphische Kontexte  17

4.4.3  Ereignisse  18

4.4.3.1  Ereignistypen  18

4.4.3.2  Ereignisverarbeitung  18

4.4.3.3  Ereignisorientierte Anwendungsprogrammierung  19

4.5  Der Nano-X Server  20

4.6  Nano-X API und Microwindows API  21

4.6.1  Kernkonzepte im Vergleich  21

4.6.2  Nano-X API oder Microwindows API Ein Fazit  21

4.7  State Saver Visueller Zustandsspeicher  22

4.7.1  Verwendung  23

4.7.2  Funktionsweise  23

4.7.3  Kompilierungshinweise  24

4.8  dkbd Eine virtuelle Tastatur für das OFSP  24

4.8.1  Anwendungskonzeption  24

4.8.2  Programmiertechnische Umsetzung  25

4.8.2.1  Abstrakt  25

4.8.2.2  Grundlegender Code  26

4.8.2.3  Ereignisverarbeitender Code  28

4.9  Die TinyWidgets Bibliothek  29

1

4.9.0.4  Grundlegendes  29

4.9.0.5  Grundlegende Verwendung  29

5  Zusammenfassung  32

6  Ausblick  33

  A Anhang I  i

  A 1 Linux Serialschnittstellenkommunikation  i

  A 1 1 Grundlegendes  i

  A 1 2 Überprüfung der Schnittstellenfunktionalität  ii

  A 1 3 Programmierung  iii

  B Anhang II  vi

  B 1 Nano-X Kurzreferenz  vi

  B 1 1 Fenstereigenschaften  vi

  B 1 2 Ereignisstrukturen und Ereignistypen  x

  B 1 3 Nano-X Zeichenroutinen  xii

  C Anhang III  xiv

  C 1 Quelltext der virtuellen Tastatur „dkbd“  xiv

  C 1 0 1 Quelltext-Datei dkbd h  xiv

  C 1 0 2 Quelltext-Datei dkbd c  xv

  C 1 0 3 Quelltext-Datei stuff c  xxxi

  C 2 Der Zustandsspeichers „state saver“  xxxix

  C 2 1 Hinweise zur Verwendung  xxxix

  C 2 1 1 Package description  xxxix

  C 2 1 2 Package use  xxxix

  C 2 2 Quelltext einer Beispielanwendung xl  

  C 2 3 Quelltext des Zustandsspeichers xliii  

  C 3 Quelltext eines einfachen Nano-X Ladebalkens lii  

  C 3 1 Header-Datei sbar h lii  

  C 3 2 Quelltext-Datei sbar c liii  

  C 4 Quelltext der Tiny-Widgets und Serialport-Testanwendung lvi  

  Glossar a  

  Literatur e  

  Quellen f  

  Abbildungsverzeichnis h  

Tabellenverzeichnis i   

  Rechtliche Hinweise j  

  Eidesstattliche Erklärung j  

  Danksagung j  

2

Vorwort

Aufgrund des Vorhabens, dem Leser einen möglichst leichten Textfluss zu ermöglichen, sind bestimmte verwendete Begriffe und spezielle Terminologien im Glossar am Ende dieser Arbeit verzeichnet und erläutert. Im Glossar aufzufindende Einträge sind bei ihrem ersten Auftreten im Text . . . . . . . . punktiert . . . . . . . . . . . . . unterstrichen.

Es sei weiterhin darauf hingewiesen, dass der Leser dieser Arbeit grundlegende Kenntnisse des GNU/Linux-Systems sowie der Bedienung der interaktiven Unix-Shell besitzen sollte, dennoch für alles Weitere kein spezielles Vorwissen notwendig ist. Wichtige weiterführende Unix-relevante Konzepte werden weitestgehend beschrieben undsoweit es der Rahmen dieser Arbeit zulässt - ausgeführt.

3

Einleitung

In der Softwareentwicklung stellt jeder Schritt einer Neu- bzw. Umorientierung auf alternative Entwicklungstechniken und -werkzeuge einen wohl überlegten Eingriff in die Produktivität eines Unternehmens dar.

Dabei besteht die Unsicherheit, die richtige Entscheidung getroffen zu haben. Zum einen ist ein erheblicher Arbeitszeitaufwand notwendig, die entsprechenden Fähig- und Fertigkeiten zu erwerben, die für professionelle Produktentwicklungen notwendig sind, zum anderen bleibt zunächst der Aufwand ungerechtfertigt, bis sich ein effektiver Nutzen nach einer längerfristigen Zeitperiode abzeichnen kann, dessen Eintreten nicht vorhersehbar ist.

Trotz eines in der letzten Zeit stark zugenommenen Herantastens vieler Unternehmen an OpenSource-Lösungen als Alternativen zu ihren bisherigen Herangehensweisen, ist hier die Vorsicht besonders groß und aus stereotypisierender Sicht auch gerechtfertigt. Wie oftmals missverstanden, ist die Verwendung oder gar Entwicklung von kommerzieller OpenSource-Software nicht gleichbedeutend mit der bedingungs- und willenlosen Übergabe von kostspieligen Neuentwicklungen an Konkurrenz oder böswillige Kräfte, sondern ein verständnisvolles Geben und Nehmen innerhalb der Gemeinschaft freier Softwareentwickler.

Durch diese Art von gemeinsamen Teilen wird nicht nur die Zeit der kompletten Neuentwicklung von Grundlagensoftware eingespart, sondern auch die Beständigkeit, Stabilität und Integrität von „Source code“ insgesamt verbessert, da der Anspruch der Perfektion nicht im Kleinen, aber in der großen nach Vollendung strebenden OpenSource Gemeinschaft von allen getragen wird.

Aus den Gründen eine grundlegend solide Wissensbasis sowie einen Ausgangspunkt für potenzielle Entwicklungen von Embedded Linux-Anwendungen für das Gerät OFSP (Open Frame Smart Panel) von der Firma Ultratronik aus Herrsching zu schaffen, wurde diese Arbeit mit dem Ziel initiiert, wertvolle Vorarbeiten zu leisten, indem Grundlagen zusammengefasst bzw. erweitert werden und gesammeltes Wissen lehrreich und strukturiert dargeboten wird.

Dabei wurden die Schwerpunkte so gewählt, dass sie den grundlegenden Fragestellungen in der Entwicklung von graphischen Anwendungen analytischer Software mithilfe der Nano-X Bibliothek möglichst gerecht werden können. Denn gerade für Nano-X existieren nur wenige und mindergute Anleitungen, die in ihrem Beispielreichtum und ihrer Vollständigkeit eher große Lücken aufzuweisen haben. Im Rahmen dieser Arbeit wurden zudem Beispielapplikationen zur Anwendung von Nano-X, zur Anwendung der Tiny-Widgets Bibliothek sowie zur Benutzung der Serialschnitte unter Linux erstellt. Weiterhin wurde eine kleine Erweiterung zur Nano-X Bibliothek vorgenommen (siehe Abschnitt 4.7).

Ferner wird am Ende diese Arbeit auf die für die Kommunikation mit externen Geräten sehr wichtige Ansteuerung und Programmierung der Seriellen Schnittstelle unter Linux genauer eingegangen (siehe Abschnitt A.1).

4

1 Grundlegendes

1.1 Software und Analysetechnik

Der Einsatz von Software zur Auswertung aufgenommener Messdaten bietet gegenüber manuellen Methoden zahlreiche Vorteile: Es können Aussagen in kürzerer Zeit und zuverlässiger getroffen sowie sehr einfach und anschaulich dargestellt werden. Zunehmend komplexere Problemstellungen erfordern zuverlässigere Methoden, die anfallenden Datenmengen untersuchen zu können. Durch den Einsatz von Software ist es möglich solche Probleme schnell und bequem zu lösen.

1.2 Problemstellung

In einem Unternehmen der Entwicklung und Produktion von Mess- und Analysegeräten besteht der ständige Anspruch der Verbesserung bestehender Produkte sowie deren Software und der effizienteren Gestaltung der Verfahren, die dazu notwendig sind. Gerade aber im Bereich der Software besteht sehr oft das Problem, dass stark lizenzpflichtige Programmpakete zuerst kostenintensiv zu erwerben und dann, wenn in Anwendung, kostenaufwendig zu warten sind. Dieses wirkt aus Sicht dieser Arbeit dem hohen Anspruch der Effizienz entgegen. Ob die Flexibilität analytischer Geräte durch ein hohes Maß an proprietärer Basis-Software eingeschränkt wird und ob die Entscheidung für OpenSource-Produkte deshalb als bessere Wahl gelten kann, ist je nach Situation abzuwägen:

Gründe, die gerade ein mittelständisches produktorientiertes Unternehmen mit weniger Entwicklungskapazitäten zur Abwägung bewegen sollten, sind der zusätzlich entstehende Mehraufwand der Einarbeitung in anwendungspraxis-fremde Programmierverfahren, die oftmals nicht oder noch nicht vorhandene Hardware- und Treiberunterstützung von vielen OpenSource-Bibliotheken, der fehlende (gute) Support eines Software-Anbieters sowie die Abklärung eventueller Verletzungen der Bedingungen unterschiedlicher freier-software Lizenzen .

Dennoch bietet es sich an, im weiten Feld der vorhandenen Software-Pakete nach Alternativen zu suchen, die auf den Grundideen, die durch . . . . freier . . . . . . . . . Software vertreten werden, fundiert sind.

Das Nano-X Projekt ist als eine OpenSource „Windowing environment“ ein sehr gutes Produkt, um durchdachte graphische Benutzerschnittstellen für verschiedenste Anwendungen zu erstellen und auf in komplexeren Messgeräten integrierten Computer-Geräten laufen zu lassen.

Die Hardware, d. h. das ebenfalls einleitend erwähnte OFSP (Open Frame Smart Panel) von Ultratronik, soll zunächst im folgenden Abschnitt als ein freie Software unterstützendes, universelles Gerät vorgestellt werden, welches sich als Steuereinheit in ein analytisches Gerät integrieren ließe.

5

2 Hardware

2.1 OFSP — Open Frame Smart Panel

Grundlegend kann das OFSP („Open Frame Smart Panel“) der Firma Ultratronik als ein vollwertiges Computersystem verstanden werden, dessen kleine Größe und hohe Leistung es besonders geeignet für die Integrierung als „Embedded device“ (siehe Abschnitt 3.1) in größere funktionale Geräte macht.

Der aufgesetzte Touchscreen hat eine Auflösung von 320x240 Pixel und stellt die gesamte Interaktionsschnittstelle zwischen Gerät und Anwender dar. Dadurch ist es möglich, relativ komplexe graphische Benutzeroberflächen darzustellen und bestimmte anwendungsrelevante Software direkt am Endgerät, an welches das OFSP angeschlossen ist, laufen zu lassen. Betrachtung und Auswertung von z. B. aufgenommenen Messdaten können dabei in einem bestimmten Maße unmittelbar durchgeführt werden. Zur Ausstattung des OFSP gehören wei-

terhin eine 10/100 MBit Ethernet-, eine USBsowie zwei RS232-Seriell-Schnittstellen. Dabei werden USB- und serielle Schnittstelle zur Interaktion mit dem zu steuernden Gerät verwendet, wogegen die Ethernet-Schnittstelle zur Kommunikation mit externen Systemen, oft auch für die anschließende Weiterverarbeitung aufgenommener Daten, verwendet wird. Das OFSP operiert vor allem bei sehr langen Betriebszeiten energiesparend. Ein wichtiger Punkt für die ökonomische

Abbildung 1: Die OFSP - Hardware ¹ Verwendung ist weiterhin, dass das OFSP durch seine auf das Notwendigste reduzierte

Hardware-Ausstattung sehr kostengünstig erwerbbar ist. Durch vielseitige Einsetzbarkeit an verschiedenste zu kontrollierende Geräte kann das OFSP ohnehin als ein sehr flexibles Produkt angesehen werden.

Die verwendete MIPS-Prozessor-Architektur wird herstellerseitig zum einen von dem Betriebssystem Windows CE ^TM unterstützt, zum anderen aber auch durch eine von Ultratronik modifizierte Debian-GNU/Linux ² Distribution. Ultratronik, in ihrer Beschreibung des Gerätes, bezeichnet den Einplattencomputer „OFSP5“ mit eigenständiger Betriebssoftware als MMI („Man-Machine-Interface“) und hebt vor allem die „Kostengünstigkeit, Modularität, Integrationsfähigkeit, Erweiterbarkeit sowie die Langfristigkeit“ [Q11] des Produktes hervor. In der Tat kann das OFSP als Universallösung vieler Problemstellungen der softwarebasierenden Benutzerinteraktion sowie der Steuerung eines Gerätes gelten.

¹ Diese Graphik wurde http://www.ultratronik.de, der Ultratronik Webseite, entnommen.

² „Debian is a free operating system (OS) for your computer. Debian uses the Linux kernel (the core of an operating system), but most of the basic OS tools come from the GNU project; hence the name GNU/Linux.“ [Q6]

6

3 Betriebssoftware

In diesem Abschnitt ist Grundlegendes zur Betriebssoftware von Computersystemen („Embedded devices“), die in größere Geräte als Einheit der Übernahme von Steuerfunktionen integriert sind, erläutert.

3.1 Embedded-Systems

Ist eine Computersoftware so konzipiert, dass sie in einer Steuereinheit eines bestimmten Gerätes ganz spezielle Aufgaben der Regelung und Überwachung wahrnimmt, so spricht man von einem Embedded-System („Eingebettetes System“). [Q8] Häufig sind solche Embedded-Systems sehr speziell und hardware-spezifisch, d. h. nur für die Verwendung in einem bestimmten Gerät entworfen und daher nur auf dieses beschränkt. Neue Geräte würden demnach den Aufwand der Entwickelung eines komplett neuen Betriebssystems nach sich ziehen.

Deshalb ist es sehr vorteilhaft, vollständige Betriebssysteme in der Steuereinheit eines Gerätes zu verwenden und lediglich gewissen Programmen, die auf diesem System als simple Anwendung ausgeführt werden, die eigentlichen Regelungs- und Steueraufgaben zukommen zu lassen.

Nach diesem Prinzip ist vorgesehen, das im Abschnitt zuvor beschriebene OFSP als integrierbare Steuereinheit für verschiedenste Arten an Mess- und Analysegeräten zu diskutieren. Im nächsten Abschnitt soll deshalb als Betriebssystem auf das stark proprietäre Windows CE ^TM kurz eingegangen werden, um danach die GNU/Linux-Alternative vorzustellen.

3.2 Windows CE TM

Windows CE ^TM , welches für ressourcenarme Geräte konzipiert wurde, d. h. für Geräte, die einen Arbeitsspeicher von wenigen Megabyte, eine geringe Prozessorleistung sowie wenig Festplattenspeicher besitzen, ist ein populäres, weit verbreitetes und nach abschätzbarer Einarbeitungszeit leicht programmierbares Produkt der Firma Microsoft. Dennoch sind diese scheinbaren Vorzüge kritisch zu betrachten: Es ist vor allem anzumerken, dass Microsoft Windows CE ^TM Versionen als OEM-Versionen („Original Equipment Manufacturer“ ³ ) so modifiziert sind, dass sie nach den Bedingungen eines stark monetär-belastenden Kontrakts mit einem Hardwarehersteller nur für spezielle Geräte angepasst und lauffähig sind. Außerdem sind fast alle weiteren Software-Produkte, die für Windows CE ^TM existieren, mit ähnlichem Hintergrund versehen. Die Entwicklung neuer Software geschieht hier nach dem sogenannten „Closed source“-Prinzip ⁴ .

Trotz alledem sind eine Vielzahl von komfortablen Entwicklungsumgebungen für Windows CE ^TM vorhanden, so z. B. Visual Studio für komplexe Entwicklungen, Platform

³ Originalausrüstungshersteller

⁴ Der eigentliche Quelltext eines Programmes ist nur einem kleinen Kreis von Entwicklern und Autorisierten bekannt ist.

7

Builder für Treiberentwicklungen und zudem das populäre Embedded Visual C++. Da das Verständnis der Linux-Alternative vorangetrieben werden soll, wird die Ultratronik Linux Distribution, welche speziell für die Verwendung mit dem OFSP entwickelt wurde, im folgenden Abschnitt genauer behandelt.

3.3 Ultratronik Linux Distribution

Aus dem Ultratronik Linux Handbuch heißt es:

„The Ultratronik Linux Distribution is a GPL licensed and royalty free set of Linux tools and projects to enable the development of applications and device drivers for HW based on Ultratronik MMI solutions.“ [Q7]

Bei Ultratronik Linux handelt es sich prinzipiell um ein speziell modifiziertes Debian Linux, für das ebenfalls von Ultratronik vertriebene OFSP. Deshalb ist eine Kompatibilität zum verwendeten Hardware-System des OFSP hundertprozentig gegeben. Die CD-ROM der Distribution beinhaltet vorerstellte Root-Verzeichnisse mit unterschiedlichen Konfigurationen, die für die verschiedenen MMI-Lösungen von Ulktratronik jeweils unterschiedlich aufgebaut sind. Beim OFSP5 ist das Root-Verzeichnis nach dem Mikrokontroller „VR4181A“, auf welchem das Hardware-System aufbaut, benannt und im Verzeichnis rootfs/rootfs_VR4181A zu finden. Auf einem ausgelieferten Gerät sollte allerdings das grundlegende Root-Dateisystem bereits vorhanden sein. Die Distribution beinhaltet des weiteren Nano-X sowie die TinyWidgets Erweiterung zum Nano-X System, welches die graphische Basissoftware als „Windowing system“darstellt.

Weiterhin ist eine Toolchain, welche CLIB (C Bibliothek), GCC (GNU C Compiler) und GDB (GNU Debugger) beinhaltet, vorhanden. Für die Installation der Toolchain auf dem Gerät ist es lediglich notwendig, sie in das Root-Verzeichnis mittels des tar Befehls zu extrahieren ⁵ :

tar xfjv /toolchain/ gcc-3.3.5-glibc-2.3.2.tar.bz2 -directory=/

Außerdem sind einige Beispielapplikationen, die neben einfachen „Hello world“-Programmen außerdem die Ansteuerung bestimmter Hardware demonstrieren, auf dem Datenträger enthalten.

Für genauere Information empfiehlt es sich, das auf der CD-ROM im Ordner doc/ zu findene „Ultratronik Linux User Distribution Users Manual“ zu konsultieren.

3.4 X-Window Systeme

Für die graphische Ausgabe ist es in einem System zum einen notwendig grundlegende Treiber (z. B. für die Graphikkarte), welche auf niedrigster Ebene („low-level“) operieren, vorzuimplementieren, zum anderen aber auch, darauf aufbauend, Programmierbibliotheken, die sogenannte . . . . API, als höhere Abstraktionsebene anzubieten, welche einem

Entwickler eine leicht bedienbare, geräteunabhängige (portable) und gut dokumentierte Schnittstelle bieten.

⁵ Kommando in dieser Form dem „Ultratonik Linux Distribution“-Handbuch entnommen [Q7].

8

Das auf GNU/Linux-Systemen heutzutage am meisten zur Realisierung dieses Konzepts verwendete Software-Paket ist das X-Window-System, welches auch unter dem Namen X11 bekannt ist.

Es wurde 1984 am MIT (Massachusetts Institute of Technology) als Projekt initialisiert, um ein graphisches System zu entwickeln, welches sowohl lokal als auch über eine Datenfernübertragungsleitung in der Lage sein sollte, graphische Routinen und Primitiven bereitzustellen. Um dies zu ermöglichen, wurde ein Client/Server Modell und ein spezielles Protokoll entwickelt. [Q20]

Die generelle hohe Rechengeschwindigkeit und Speicherkapazität moderner Computersysteme unterstützt den mittlerweile riesig gewordenen Funktionsumfang des X-Window-Systems relativ problemlos. X11 bleibt allerdings gerade deshalb für ressourcenarme Geräte sehr ungeeignet.

Aus diesem Grund wurde das Nano-X Projekt (Microwindows ⁶ ) mit dem Vorhaben ins Leben gerufen, für Embedded-Systems, d. h. Handhelds, Embedded-Steuereinheiten, etc. eine leicht programmierbare und problemlos lauffähige Alternative darzustellen, die niedrige Systemanforderungen voraussetzt. Innerhalb des Nano-X Projektes wird ebenfalls das oben erwähnte Client/Server-Modell mit einem eigenen Protokoll sehr ausschöpfend inkorporiert.

Vorteilhaft an Nano-X ist außerdem, dass sich mit der Programmierbibliothek des X-Window-Systems (Xlib) geschriebene Programme mit abschätzbar wenig Programmier-aufwand zu unter Nano-X lauffähigen Applikationen portieren lassen. Die Entwicklung von graphischen, leicht zu portierenden Linux-Anwendung kann vor diesem Hinter-grund guten Gewissens vollzogen werden.

Im nächsten Abschnitt wird hinführend zur Entwicklung von Nano-X Anwendungen erläutert, wie Programme generell für das OFSP kompiliert werden können.

3.5 Cross-Compiler

Cross-Compiler werden generell verwendet, um auf einem sogenannten Build-Host den generischen und portablen Quelltext eines Programmes in eine dem kompilierenden System „fremde“ Maschinensprache zu übersetzen. Das Kompilat ist dann auf einem sogenannten Target-Host, für welches die Applikation fremd-kompiliert wurde, lauffähig, da die ausführbare Datei mithilfe von Maschinensprachinstruktionen erstellt wurde, welche für den Build-Host unverständlichen, aber für den Target-Host verständlichen bzw. ausführbar sind.

Bei den meisten Computersystemen handelt es sich um solche, welche Intel-Assembler Maschinensprache verwenden und deren Instruktionen vom Prozessor bearbeitet werden können. Da es sich aber beim Prozessor des OFSP um eine MIPS-Prozessorarchitektur handelt, muss auf einem Build-Host ein Cross-Kompilat erstellt werden.

Gewöhnlicherweise steht dazu auf dem Build-Host ein spezieller Compiler zur Ver- ⁶ DasNano-X Projekt trug einmal den Namen Microwindows. Es musste allerdings auf Verlangen eines größeren U.S.-Amerikanischen Softwarekonzerns umbenannt werden, da dieser äußerte, dass ihr Betriebsystem mit ähnlichem Namen mit dem ursprünglichen Namen des Projekts hätte verwechselt werden können.

9

fügung, welcher in der Lage ist, systemfremden Assembler-Code zu produzieren, d. h. ein lauffähiges Programm für den Target-Host zu erstellen. Die von Ultratronik herausgegebene CD-ROM der Ultratronik Linux Distribution beinhaltet einen bereits voreingerichteten und für Intel-Prozessoren vorkompilierten GNU-Compiler, um C-Programme für die MIPS-Prozessorarchitektur zu erzeugen (Cross-Compiler).

Für die Installation dieses Cross-Compilers muss das sich im Verzeichnis Toolchain auf der CD-ROM befindliche Archiv gcc-3.3.5-glibc-2.3.2 mittels des tar-Tools lediglich extrahiert und das anschließend erhaltene Verzeichnis usr/mipsel-linux einschließlich Ordnerstruktur und Inhalt in das Root-Verzeichnis des Host-Entwicklungsystems kopiert werden. Die Binary /usr/mipsel-linux/bin/mipsel-linux-gcc stellt dann den eigentlichen auf dem Host-System lauffähigen Compiler dar, welcher für die Kompilierung für Anwendungen für das Target-Sytem nun zur Verwendung bereit steht.

10

4 Nano-X — Die schlanke X-Window Variante

Ziel in diesem Teil ist es, das Konzept und die grundlegende Funktionalität der Nano-X API weitestgehend zu ergründen und einen tieferen Einblick in die Benutzung der Programmierbibliothek zu geben.

4.1 Gesamtüberblick

„The Nano-X Window System is an Open Source project aimed at bringing the features of modern graphical windowing environments to smaller devices and platforms.“ [Q13]

Bei Nano-X handelt es sich um ein freies Software-Produkt für Linux, welches grundlegende Graphik- und Management-Routinen moderner fensterbasierter Benutzeroberflächen für ressourcenarme Geräte zur Verfügung stellt.

Gegenüber anderen X-Window Systemen ist Nano-X selbst mit einfachster Hardware zuverlässig und stabil lauffähig, bietet aber daher auch nur einen begrenzteren Funktionsumfang. Dieser ist allerdings für kleinere Geräte und deren Anwendungsbereich oftmals vollkommen ausreichend.

Nano-X ist ohne Probleme auf einer Vielzahl von Architekturen lauffähig, wie z. B. Intel 16/32 Bit, MIPS oder PowerPC. Beim OFSP handelt es sich um ein auf der MIPS R4000 - Prozessorarchitektur basierendes System. Ein Linux-System, dessen Kernel Framebuffer unterstützt, d. h. Kernel ab Version 2.2.x, sollte vorhanden sein. Das Nano-X System wurde in drei separaten Ebenen nach dem sogenannten „ . . . . Glue

layer-Prinzip“ konzipiert. In der ersten untersten Ebene, der Treiberebene („Driver le-. . . . . . . . . . . .

vel“), werden Hardware-Routinen für Maus, Bildschirm, u. ä. implementiert, um sie dann für die zweite, die Betriebsebene („Engine level“), der sogenannten MicroGUI, bereitzustellen. Dabei werden in der ersten Ebene sehr viele verschiedene Treiber für eine Vielzahl an Hardwareprodukten unterstützt. Die zweite Ebene kann als eine Art geräte-und plattformunabhängige Umsetzung der graphischen Zeichenroutinen und der dazu notwendigen Algorithmen verstanden werden. [Q10, 1, 17]

Bei der dritten Abstraktionsebene, der eigentlichen Anwendungsebene, steht einem Programmierer der volle Funktionsumfang der Bibliothek als API zur Verfügung. Besonders interessant ist hierbei, dass Nano-X zwei verschiedene APIs zur Verwendung anbietet. Bei der ersten handelt es sich um die sogenannte Nano-X API, welche sehr an die des X-Window Systems angelehnt ist und bei der zweiten um die sogenannte Microwindows API, welche Anlehnung an die in der Windows-Programmierung verwen-

11

dete APIW (Win32 ^TM API) findet, allerdings nicht den vollen Funktionsumfang dieser unterstützt. [Q19]

Durch diese Anlehnung an zwei sehr populäre APIs können Anwendungen, die auf Xlib (X-Window) basieren, bzw. Anwendungen, welche die Windows API ^TM benutzen, zu unter Nano-X lauffähigen Programmen mit etwas Aufwand portiert werden. In dieser Arbeit soll die Nano-X API vorgestellt und verwendet werden, da sie die Möglichkeiten, welche die unter der Anwendungsebene liegenden Schichten, d. h. der Betriebs- und Treiberebene, implementierungstechnisch besser nutzen kann (siehe Abschnitt 4.6 „Nano-X API oder Microwindows API“).

4.2 Lizenz und Bedingungen

Bei der Entwicklung von proprietärer Software besteht oft das Problem, dass die Verwendung von unter der GPL („GNU General Public License“) lizenzierter Software zu Problemen führen kann, denn es gilt laut den Lizenzbedingungen der GPL, dass sie zu einer anschließenden Lizenzierung der neu entwickelten Software unter ihr verpflichtet. Da es allerdings nicht sinnvoll erscheint, den Quelltext eines letztendlichen Produktes freizugeben, kann dies sehr einschränken, gerade wo doch eine Vielzahl an nützlicher GNU-Software bei der Entwicklung als Werkzeug oder auch als Programmierbibliothek

. . . . . vorhanden ist.

Eine Alternative dazu bietet die MPL („Mozilla Public License“), unter welcher Nano-X ebenfalls lizenziert ist: Anders als die GPL verpflichtet die MPL zwar auch dazu, dass alle Software-Derivate unter ihr lizenziert werden, hat aber dennoch einige Lockerungen zur strengeren GPL. So wird z. B. die Einteilung zwischen den Rechten des Originalau-tors einer Software und den Rechten derer, die Software-Derivate erzeugen, getroffen. Die Nano-X Bibliothek ist sowohl unter der GPL als auch unter der MPL zweifachlizenziert.

Bei letzterer ist es genauso möglich, auf dem Original-Quelltext einer Software aufzubauen oder eine Programmierbibliothek zu verwenden, wobei allerdings nur der ursprünglich übernommene Kernteil auch unter der MPL lizenziert bleiben muss und der andere, letztendlich hinzugefügte Anteil, beliebig unter jeglicher anderer Software-Lizenz lizenziert werden darf. [Q12]

Demnach sind bei der Verwendung der Nano-X Bibliothek auch im kommerziellen Verwendungsbereich keinerlei Einschränkungen erkennbar. Der Quelltextanteil einer proprietären Neuentwicklung muss bei der Verwendung der MPL also nicht veröffentlicht werden.

4.3 Einrichtung des Systems

Die Entwicklung von Nano-X wurde leider im Jahre 2005 eingestellt, weswegen es sich bei der neusten Version um Microwindows 0.90 handelt, dessen Quelltext unter http://www.microwindows.org heruntergeladen werden kann. Nach dem Dekomprimieren des Archivs mittels des Konsolenkommandos tar xvf microwindows-0.90.tar.gz sollte der „ . . . . . Build . . . . tree“ im Paketverzeichnis vorhanden sein.

12

Nicht wie bei Installationen unter vielen Linux-Systemen üblich, muss hier vor dem Kompilieren das configure-Skript ausgeführt werden, sondern lediglich die Datei config im src/-Quelltextverzeichnis editiert werden, um bestimmte Einstellungen, wie z. B. Mausunterstützung, Framebufferverwendung oder die zu benutzenden Systemfonts (Schriftarten), zu tätigen ⁷ .

Wichtig ist, dass in der config-Datei die Prozessorarchitektur des späteren Nano-X ausführenden Systems durch die Zeile ARCH= korrekt angegeben wird, d. h. für die MIPS-Architektur würde sie ARCH = LINUX-MIPS lauten.

Es soll also cross-kompiliert werden, d. h. in diesem Falle, dass das Nano-X System für eine andere Architektur als die des kompilierenden Systems übersetzt wird, muss beim Ausführen des make-Skripts der in Abschnitt 3.5 eingerichtete Crosscompiler dem Programm . . . . . GNU . . . . . Make zur Verwendung angegeben werden:

./make install --prefix=/usr/mipsel-linux/

--with-build-gcc=/usr/bin/mipsel-linux-gcc

Nach dem Kompilieren sollten nun alle nötigen ausführbaren Dateien („Binaries“) im Ordner src/bin des Microwindows-Verzeichnisses vorhanden sein ⁸ . Bei der ausführbaren Datei nano-X handelt es sich um den eigentlichen „X-Server“ , d. h. um das Programm, welches grundlegende low-level Routinen und Hardware-Primitiven implementiert.

Die weiterhin wichtige Binary-Datei nanowm ist der Nano-X „Window manager“, welcher dafür zuständig ist Nano-X Applikationen in einer fensterbasierten Umgebung („Windowin environment“) anzuordnen und zu verwalten.

Wird Nano-X auf einem System betrieben, so sollte zunächst das Nano-X Basissystem ( nano-X) und anschließend der Fenstermanager ( nanowm) gestartet werden ⁹ . Während der Entwicklung von Software für das Endgerät (in diesem Fall das OFSP) kann die Möglichkeit verwendet werden, Nano-X auf einem X-Window System, d. h. auf einem Host, welcher X11 als graphisches System verwendet, zu emulieren, sodass Anwendungen schon beim Entwickeln getestet werden können. Dazu ist es lediglich notwendig vor dem Kompilieren die Zeile X11 = Y und die Zeile FRAMEBUFFER = N in der Konfigurationsdatei INSTALL zu setzen.

Es ist weiterhin wichtig, dass die statischen Nano-X Bibliotheken, welche nach dem Kompilieren im Verzeichnis src/lib mit der Endung * .a vorhanden sind, auf dem Host-Entwicklungssystem in das Verzeichnis usr/lib kopiert werden müssen. Ebenso müssen die Microwindows Header-Dateien in das Verzeichnis /usr/include auf dem Host-System von dem Verzeichnis src/include kopiert werden. Damit ist sichergestellt, dass der C-Compiler die Include-Dateien bzw. Bibliotheken vorfindet. Beim Kompilieren muss nun lediglich der Parameter -lnano-X , welcher für die Nano-X Bibliothek steht, in der Kommandozeile beim gcc Aufruf übergeben werden.

⁷ Einstellungen dieser Art können in der Konfigurationsdatei config im src/-Ordner des Nano-X Quelltextes entnommen werden.

⁸ Die beiden ausführbaren Dateien nano-X und nanowm sollten anschließend z. B. in das Verzeichnis /usr/bin kopiert werden, sodass diese global verfügbar sind.

⁹ Soll dieser Prozess bei jedem Systemstart automatisch durchgeführt werden, so kann dies durch einen Eintrag in die Systeminitialisierungsdatei /etc/initab geschehen.

13

4.4 Einführung in die Nano-X Programmierbibliothek

Da die Nano-X API in der Programmiersprache C implementiert wurde, handelt es sich bei dieser auch um die Sprache, in welcher Nano-X Anwendungen generell geschrieben werden, so auch in dieser Arbeit.

Mit dem Ziel, einen ersten Überblick über das Arbeiten mit der Nano-X API zu bekommen, wird hier der Quelltext einer einfachen Nano-X Anwendung angebracht, welcher allerdings bereits viele wichtige Kernpunkte der Programmierung beinhaltet.

1 #include

2 / * Nano-X Farben sollen verwendet werden * /

3 #define MWINCLUDECOLORS

4 / * Inkludiere Nano-X Header-Dateien * /

5 #include

6 #include

7

8 int main(int arc, char ** argv)

9 {

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

14

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70 }

Betrachten wir die im Quelltext auftretenden Einzelheiten vorerst einmal nicht, so ist die Grundidee eines Nano-X Programmes sehr schnell verständlich. Ein Fenster wird erzeugt, auf welches mithilfe eines so genannten Graphischen Kontexts Ausgaben erfolgen können.

Weiterhin wird deutlich, dass verschiedene Ereignisse existieren, die auftreten können, und im unteren Teil des Programms in eine Endlosschleife, der sogenannten Ereignisschleife, abgefragt werden.

Ersichtlich ist in der Beispielanwendung auch, dass beim Auftreten des Ereignisses GR_EVENT_TYPE_EXPOSURE, des sogenannten „Sichtbarkeitsereignisses“ ¹⁰ , der Text „Hello World“ auf dem Fenster ausgegeben wird.

In den folgenden Abschnitten wird auf die im Beispiel bereits verwendeten Kernkonzepte der Nano-X API näher eingegangen werden ¹¹ .

¹⁰ expose = anzeigen, aussetzen

¹¹ Verschiedenste Publikationen wurden zur Erstellung und Ausarbeitung dieses Teils herangezogen. Siehe dazu folgende Quellen im Quellenverzeichnis: [Q4, 3, 15, 18, 2].

15

4.4.1 Fenster

Fenster sind ein rechteckiger Pixelraum mit einer Höhe und einer Breite sowie X- und Y-Koordinaten des linken oberen Eckpunktes. Sie sind in einer Baumstruktur registriert, d. h. ein Fenster kann als Elter („Parent“) beliebig viele Kinderfenster („Children“) besitzen. Das sogenannte Hauptfenster („Rootwindow“) stellt dabei den gesamten Bildschirm als „Fenster“ dar und ist das Haupt-Elter aller anderen Fenster. Es ist als Fenster nicht entfernbar, verhält sich aber ansonsten wie ein reguläres Fenster, auf dem Ereignisse wahrgenommen werden sowie Ausgaben getätigt werden können. Die Positionsangaben eines Fensters sind außerdem immer eine Angabe relativ zum Elter-Fenster, dessen oberster linker Eckpunkt die Koordinaten X=0 und Y=0 besitzt. Kommt es zur Überlappung von Geschwisterfenstern (Fenster mit dem gleichen Elter), so legt ein veränderbarer Präzedenzwert fest, welches Fenster vollständig sichtbar ist und welches durch seine Geschwister verdeckt werden kann. Außerdem besitzen alle Fenster eine Hintergrundfarbe, wobei ein neu erstelltes oder ein geleertes Fenster immer mit dieser vollständig gefüllt ist. Für ein Fenster existiert weiterhin ein optionaler Rahmen, der mit einer variablen Breite und Farbe definiert ist. Besitzt ein Fenster einen Rahmen (Rahmenbreite > 0), so ist dieser um das Fenster gezeichnet, d. h. er beeinflusst die Ausmaße des durch das Fenster aufgespannten relativen Koordinatensystems nicht. Um ein Fenster zu erstellen, geht man wie folgt vor:

Zunächst deklariert man eine Variable mit dem von der Nano-X API definiertem Typen GR_WINDOW_ID, welcher die Identifikationsnummer des Fensters darstellt:

GR_WINDOW_ID fenster;

Als nächstes erzeugt man mithilfe der Funktion GrNewWindow (...) ein neues Fenster und weist den Rückgabewert dieser der eben deklarierten Variable zu, womit die ID des Fensters gespeichert ist.

fenster = \

GrNewWindow(GR_ROOT_WINDOW_ID, 10, 10, 20, 20, 4, WHITE, BLUE);

Die Parameter der Funktion GrNewWindow (...) sind in dieser Reihenfolge das Elter-Fenster, welches hier im konkreten Fall das Hauptfenster durch die Konstante GR_ROOT_WINDOW_ID, die X-Koordinate des Fensters, die Y-Koordinate des Fensters, die Fensterbreite, die Fensterhöhe, die Rahmenbreite, die Fensterhintergrundfarbe sowie die Rahmenfarbe repräsentiert.

Im Beispiel ist also ein Fenster an der Position (10, 10) mit den Ausmaßen 10x10, der Hintergrundfarbe weiß und der Rahmenfarbe blau erzeugt worden. Dabei ist das Hauptfenster vom Typ GR_WINDOW_ID, X- und Y-Koordinate vom Typ GR_COORD, Fensterbreite und -höhe sowie Rahmenbreite vom Typ GR_SIZE. Positions-und Größenangaben verhalten sich wie Integervariablen.

Ein Fenster kann sichtbar oder unsichtbar sein („mapped“ oder „unmapped“), wobei auf ihm, wenn unsichtbar, keine Ereignisse auftreten können. Ansonsten verhält es sich genauso wie ein sichtbares Fenster. Ein neu erstelltes Fenster ist immer unsichtbar und muss deshalb erst sichtbar gemacht werden:

16

GrMapWindow(fenster);

Es ist möglich, einem Fenster einen speziellen Mauszeiger zuzuordnen. Kinder eines Fenster haben, wenn erstellt, den gleichen Mauszeiger wie das Elter-Fenster. Für ein Fenster kann solch eine Zuordnung durch die Funktion GrSetWindowCursor (...) geschehen.

Wissenswert ist auch, dass zwei Fensterarten existieren. Das sind zum einen Ein/Ausgabe-Fenster, welche normal sichtbar sind und in welche ausgegeben werden kann, zum anderen unsichtbare rahmenlose „Nur-Eingabe“ -Fenster, in welche nicht ausgeben werden kann. Sie fangen Ereignisse ab bzw. ändern den Mauszeiger an bestimmten Bildschirmregionen. „Nur-Eingabe“ -Fenster können auch nur solche als Kinderfenster besitzen.

4.4.2 Graphische Kontexte

Ein Graphischer Kontext („Graphics Contexts“) ¹² bezeichnet eine Menge von Eigenschaften (wie Farbe, Dicke, Art), die beim Zeichnen graphischer Objekte eine Rolle spielen. D. h. anstatt diese Eigenschaften bei jeder Zeichenoperation einzeln als Parameter des entsprechenden Funktionsaufrufs anzugeben, wird ein eigenschaftsspeichernder GK verwendet. Die einzige Eigenschaft, die ein graphischer Kontext nicht vereinen kann, sind die für jedes graphische Objekt individuellen Positionskoordinaten. Für einen neuen GK muss Speicher allokiert werden, womit dieser eine einzigartige Identifikationsnummer erhält:

GR_GC_ID graphischer_kontext = GrNewGC();

Ein neuer GK ist mit Standardeigenschaften ausgestattet, d. h. zum Beispiel der Vorder- und Hintergrundfarbe weiß und der Dicke 0.

Gewöhnlicherweise wird für jede Gruppe ähnlicher graphischer Elemente ein GK angelegt, der dann im Programm mehrfach für eben diese Gruppe verwendet werden kann.

Eine typische Eigenschaft eines GK ist z. B. der Zeichenmodus, welcher das Vorgehen beim Zeichnen eines jeden Pixels beschreibt. Für einen bestimmten GK kann er mit der Funktion GrSetGCMode (GR_GC_ID gk, int mode) gesetzt werden. Die modusbeschreibende Integervariable der Parameterliste kann die konstanten Werte GR_MODE_SET (Standardmodus), welcher Pixel unverändert zeichnet, sowie GR_MODE_XOR, GR_MODE_OR oder GR_MODE_AND besitzen, welche die Farbaddition nach der jeweils im Konstantennamen erkennbaren Methode durchführen. Eine weitere Eigenschaft eines GK ist die Schriftart, welche als Standardschriftart durch die Integervariable 0 angegeben wird. Die in fortlaufender Nummerierung folgenden Schriftarten sind Systemschriftarten. Wie viele dieser genau existieren, ist unterschiedlich und vom System abhängig. Weitere Schriftarten müssten erst beim graphischen Server des Nano-X Systems registriert werden. Die Schriftart eines GK wird mit der Funktion GrSetGCFont (GR_GC_ID gk, GR_FONT_ID font) festgelegt.

¹² Im Folgenden soll die Abkürzung GK für graphischer Kontext verwendet werden.

17

Weiterhin existierende Eigenschaften sind Vordergrund- bzw. Hintergrundfarbe, die mit GrSetGCForeground (...) bzw. GrSetGCBackground (...) gesetzt werden können, wobei die Standardhintergrundfarbe schwarz ist. Hierbei gibt eine bool’sche Variable als weitere GK-Eigenschaft an, ob der Hintergrund beim Zeichnen überhaupt verwendet werden soll. Diese kann mittels GrSetGCUseBackground (GR_GC_ID gk, GR_BOOL bool) gesetzt werden.

Neben diesen Grundeigenschaften existieren einige weitere, die im Nano-X Handbuch kurz beschrieben werden.

4.4.3 Ereignisse

4.4.3.1 Ereignistypen

Ein Ereignis beschreibt eine Statusänderung von Tastatur, Maus oder Bildschirm, die vom Benutzer hervorgerufen wurde. Dabei werden durch Hardware hervorgerufene Ereignisse als physische bezeichnet.

Tritt ein Ereignis auf, so kann ein Nano-X Programm darauf reagieren, indem es Ereignisse von der Ereignisschlange („Event queue“) des Nano-X Servers abruft, welche dort für eine Anwendung angestellt werden.

Weiterhin wird die Art eines Ereignisses durch dessen Ereignistyp bestimmt. Da eine Vielzahl von Ereignissen auftreten können, assoziiert Nano-X mit jedem Ereignis eine sogenannte Ereignisstruktur, welche Informationen über das Ereignis enthält (z. B. bei Mausereignissen die Koordinaten des Mauszeigers, oder bei Tastaturereignissen die gedrückte Taste).

Bei einer Ereignisstruktur handelt es sich also um eine C-Kollektion ( struct) mehrerer Objekte, welche in ihrer Gesamtheit spezifische Informationen über ein Ereignis mit einem bestimmten Ereignistyp liefert.

Das typendefinierte ¹³ GR_EVENT stellt ein polymorphes Konstrukt dar und ist in Wahrheit lediglich eine C-Variante („Union“), welche als Elemente seiner Ausprägung alle in Nano-X vorhandenen Ereignisstrukturen enthält. Somit kann ein jedes Ereignis den Typ GR_EVENT besitzen. Dieses Ereignis kann nun aber auch nach einer Fallunterscheidung mittels des type-Feldes, welches, da es in jeder Ereignisstruktur existiert, auch als Element der Variante abgefragt werden kann, in den richtigen Typen umgewandelt werden (cast), um Zugriff auf die ereignisstrukturspezifischen Informationen eines bestimmten Ereignisses zu bekommen.

Somit korrespondiert eine ereignistypbeschreibende Integerkonstante (Ereignistyp) mit einer oder mehreren typendefinierten Ereignisstrukturen. Mehrere deshalb, da einige unterschiedliche Ereignisse gleiche Informationen liefern, d. h. gleiche Strukturfelder besitzen, wie z. B. Ereignisstrukturen vom Typ GR_EVENT_TYPE_BUTTON_DOWN und GR_EVENT_TYPE_BUTTON_UP (Taste gedrückt und Taste losgelassen). Eine auflistende Beschreibung aller Ereignisstrukturen und der mit ihnen korrespondierenden Ereignistypen kann dem Anhang B.1.2 entnommen werden.

4.4.3.2 Ereignisverarbeitung

¹³ Einer Struktur ( struct) wurde mittels der typedef-Anweisung ein Typenname zugeordnet.

18

Ereignisse sind an ein Fenster gebunden, d. h. sie können auf dem Bereich, der durch die Ausmaße des Fensters definiert ist, auftreten.

Hierzu müssen sie allerdings beim Fenster dafür registriert sein, was durch die Funktion GrSelectEvents( GR_WINDOW_ID fenster, GR_EVENT_MASK

ereignis_maske) ¹⁴ realisiert wird. Dabei stellt die Variable ereignis_maske vom Typ GR_EVENT_MASK eine logische ODER Verknüpfung einzelner Bit-Werte bestimmter Ereignismasken mittels des „ |“-Symbols dar und repräsentiert dadurch einen speziellen Ereignistyp. 15

Die Typnamen aller Ereignismasken sind denen des Ereignistyps sehr ähnlich. Ist der Ereignistyp z. B. durch die Integerkonstante GR_EVENT_TYPE_BUTTON_DOWN beschrieben, so wäre der dazugehörige Maskenname nichts weiter als GR_EVENT_MASK_BUTTON_DOWN.

Ist ein Fenster Kind eines anderen und tritt auf ihm ein Ereignis auf, welches nicht von ihm, aber bei seinem Elter registriert ist, so bemerkt das Elter das Ereignis des Kindfensters. Es kann dann mittels des Feldes wid einer Ereignisstruktur die Fensteridentifikation des Fensters ermitteln, auf welchem das Ereignis auftrat. Erwähnenswert ist zudem, dass ein sogenannter Eingabefokus („Input focus“) existiert. D. h. wenn ein Tastaturereignis eintritt, wird es von dem Fenster registriert, über welchem sich der Mauszeiger momentan befindet. Mit der Funktion GR_WINDOW_ID GrGetFocus (void) kann das Fenster ermittelt werden, welches im Moment den Eingabefokus besitzt. Mit der Funktion GrSetFocus (GR_WINDOW_ID fenster) kann dieser auf ein beliebiges Fenster verlegt werden.

4.4.3.3 Ereignisorientierte Anwendungsprogrammierung

Die für eine gesamte Anwendung (egal welches Fenster) auftretenden Ereignisse werden von Nano-X in einer Ereignisschlange („Event queue“) organisiert. Möchte man überprüfen, ob ein neues Ereignis für die Anwendung aufgetreten ist, so verwendet man die Funktion int GrPeekEvent (GR_EVENT * ereignis_zeiger), welche als Parameter einen Ereignisstruktur-Zeiger erhält, der auf die Ereignisstruktur des nächsten anstehenden Ereignisses zeigen wird, ohne das dieses von der Schlange entfernt wurde. Die Funktion gibt 1 zurück, wenn ein Ereignis vorhanden ist, 0 wenn nicht.

Erst mit der Funktion GrGetNextEvent (GR_EVENT * ereignis_zeiger) entfernt man das nächst anstehende Ereignis von der Schlange und erhält einen Zeiger vom Typ GR_EVENT * auf eine Ereignisstruktur.

In einer Anwendung kann man nun mithilfe einer endlos laufenden Ereignisschleife jeweils das nächste Ereignis abfragen und je nach Ereignistyp der erhaltenen Ereignisstruktur entscheiden, welches Ereignis auftrat und wie mit den erhaltenen Informationen verfahren werden soll (siehe Anfangsbeispiel in Abschnitt 4.4). Ein spezielles Ereignis namens GR_EVENT_EXPOSURE, das sogenannte „Sichtbar- ¹⁴ Zuvermerken ist, dass die Funktion GrSelectEvents(...) alle ausgewählten Ereignismasken des Fensters überschreibt, d. h. um Ereignisse hinzuzufügen, muss anders verfahren werden (siehe 4.7).

¹⁵ Für eine genauere Erläuterung und eine Auflistung aller Ereignisstrukturen und deren Ereignistypen siehe Anhang B.1.2.

19

keitsereignis“, tritt dann einmalig auf, wenn ein Fenster vollständig sichtbar wird. Schreibt man Nano-X Anwendungen, so ist es wichtig zu wissen, dass Fensterinhalte nicht gespeichert werden, d. h. sie gehen bei Überlappungen verloren und müssen somit neu gezeichnet werden.

Das kann geschehen, indem der Teilbereich (oder der gesamte Fensterbereich) genau dann neu gezeichnet wird, wenn er sichtbar geworden ist. Hierzu ist das Sichtbarkeitsereignis sehr dienlich, denn tritt es in der Ereignisschleife der Anwendung auf, d. h. wird das Fenster oder ein Teil dessen angezeigt, kann die Anweisung zum Neuzeichnen ausgeführt werden.

Daraus folgt außerdem, dass permanente graphische Fensterinhalte im Quelltext nicht gleich nach dem Erstellen des Fensters gezeichnet werden sollten, sondern erst dann, wenn das Sichtbarkeitsereignis des entsprechenden Fensters in der Ereignisschleife der Anwendung auftritt. Möchte man dennoch permanent Inhalte realisieren, so kann man auf die im Rahmen dieser Arbeit entwickelte State - Saver Erweiterung zurückgreifen (siehe Abschnitt 4.7).

Zuletzt existiert als ein besonderes Ereignis das sogenannte „Fensterschließereignis“. Um zu ermöglichen, dass ein Fenster beim Betätigen des Fensterschließbuttons, welcher sich in der rechten oberen Fensterecke befindet, geschlossen wird, muss in der Ereignisschleife der Anwendung auf das Eintreten eben dieses Ereignisses mit dem Typen GR_EVENT_CLOSE_REQ geprüft werden. Hiernach kann dann das Fenster rekursiv mithilfe der Funktion GrDestroyWindow (GR_WINDOW_ID) entfernt werden, d. h. es werden auch alle Kinder dieses Fensters aus dem Speicher entfernt. Soll eine Nano-X Anwendung vollends beendet werden, so empfiehlt sich, die Verbindung mit dem Nano-X Server mittels GrClose(void) zu beenden.

Für eine Auflistung aller Nano-X Funktionen empfiehlt es sich, das englischsprachige „Microwindows Nano-X API Reference Manual“ zu konsultieren.

4.5 Der Nano-X Server

Hier noch einige Worte zum schon mehrfach erwähnten Nano-X Server. Dahinter nämlich verbirgt sich ein Kernkonzept der Nano-X API, bei welchem es sich um das sogenannte Client/Server-Modell handelt.

Der Server stellt einen seperaten Prozess, d. h. ein eigenständiges Programm dar, welcher mit dem Ausführen der Nano-X Binary ( nano-X) gestartet wird. Dieser stellt dann einen . . . . . Unix . . . . . . . domain . . . . . . socket . . . . . . (UDS) bereit, zu welchem sich ein oder mehrere Clients verbinden können und über welchen sie kommunizieren.

Der Client stellt dabei die eigentliche vom Programmierer entwickelte Anwendung dar. Wie oben schon verwendet, muss in einer Applikation die Funktion GrOpen() zu Beginn aufgerufen werden, um eine Verbindung zum Nano-X herzustellen sowie die Funktion GrClose() am Ende, um die Verbindung wieder zu trennen. Client-Funktionen, d. h. alle Funktionen der Nano-X API, welche in einer Anwendung verwendet werden, sind dadurch gekennzeichnet, dass sie das Präfix Gr mit im Funktionsnamen tragen. Ein bekanntes Beispiel dessen ist die Funktion GrGetNextEvent(...), welche anstehende Ereignisse vom Nano-X Server über die

20