GNUstep

Einführung

Mit GNUstep haben wir eine großartige Software: die GNU-Implementierung des OpenStep Standards, der einst von NeXT Computer Inc. und Sun Microsystems Inc. veröffentlicht wurde. Uns wird hiermit eine vollständig objektorientierte Entwicklungsumgebung zur Verfügung gestellt, um portable Anwendungen zu erstellen.

Dieses Dokument zielt auf Benutzer des GNUstep-Systems. Zwar hauptsächlich für Softwareentwickler bestimmt, kann es auch eine wertvolle Quelle für die sein, die einfach nur mehr über die Software wissen möchten, die sie verwenden.

Erklärt wird das GNUstep System von zwei Perspektiven, die zum einen die Funktionen und zum anderen die Architektur, den Aufbau des Systems betrachten. Diese Schrift beschreibt zudem Begriffe und Konventionen, wie z.B. Bundles, Frameworks und die Dienste (Services), welche auf einem GNUstep System in der Regel vorhanden sind.

Die GNUstep Systemübersicht ist als eine Einführung gemeint; wo möglich wird auf detailliertere Dokumentationen verwiesen. In keinster Weise ist diese Schrift ein GNU/Linux Dokument. Dokumentation zu GNU/Linux kann unter www.linuxdoc.org abgerufen werden.

Geschichte

GNUstep ist die von der Free Software Foundation veröffentlichte Implementierung des OpenStep API, das einstmals Teil der NeXT Entwicklungsumgebung OPENSTEP war. Es ist gedacht als eine einfach zu benutzende Entwicklungsumgebung, die auf objektorientierten Programmiertechniken beruht.

Um die gemachten Entscheidungen besser zu verstehen, ist ein Tauchgang in die Vergangenheit der beste Start.

Als Steve Jobs Apple Computers, Inc verließ, startete er eine neue Firma mit Namen NeXT Computers, Inc. Im Jahr 1988 brachte die Firma einen Computer auf den Markt, genannt NeXT Cube mit einem neuen Betriebssystem genannt NeXTSTEP. 1989 erblickte NeXTSTEP 1.0 das Licht der Welt.

Zusammen mit Sun Microsystems schloss sich NeXT Computer zusammen, um einen Standard für grafische Entwicklungsumgebungen zu definieren, genannt OpenStep. Kurz danach veröffentlichte NeXT sein OPENSTEP System. Hoffentlich bemerkt der Leser hier die Differenz zwischen OpenStep (dem Standard) und OPENSTEP (der NeXT Implementierung des Standards). Dieser Unterschied ist essentiell und führt oft zu Missverständnissen.

Aufgrund von finanziellen Sorgen sah sich NeXT Computer gezwungen, die Hardwareentwicklung zu stoppen und sich in NeXT Software umzubenennen. Von da an konzentrierten sie ihre Ressourcen darauf, ein Entwicklungssystem herauszubringen, das es erlaubt, den Programmcode einmal zu schreiben und überall zu kompilieren.

Gegen Ende des Jahres 1996 wurde NeXT von Apple Computer aufgekauft. Steve Jobs wurde kurze Zeit später CEO von Apple, wobei er Gil Amelio ersetzte. Die neue Version des Betriebssystems, Mac OS X (10), ist eine aktualisierte Version des OpenStep Frameworks (nun Cocoa genannt) kombiniert mit dem Macintosh 'look and feel', basierend auf der neuesten Version des Mach Kernels.

Das GNU Projekt hatte in der Zwischenzeit die Spezifikation aufgegriffen und die Entwicklung einer eigenen Implementierung 1995 gestartet, mit der Intention es zur standardmäßigen Umgebung für das GNU Betriebssystem zu machen.

Das ist zwar alles sehr schön, aber was bedeutet das für den Benutzer oder Entwickler? Nun, GNUstep wird das Wirklichkeit werden lassen, zu was NeXT OpenStep machen wollte: eine Multiplattform-Entwicklungsumgebung. GNUstep kann auf verschiedenen Plattformen eingesetzt werden: Linux, Windows, Solaris, BSD und weiteren. Dies erzeugt Plattformunabhängigkeit. Wir brauchen uns nicht um das zu Grunde liegende Betriebssystem kümmern, wir brauchen nur die schöne grafische Schnittstelle benutzen - und müssen nie mehr eine weitere erlernen.

Eine weitere schöne Seite der Plattformunabhängigkeit ist, dass wir unsere Lieblingsanwendungen sozusagen mitnehmen können, wenn wir ein neues, anderes Betriebssystem oder einen anderen Computer benutzen. Es besteht kein Grund, einen weiteren Texteditor zu beherrschen lernen, wir können einfach den weiter benutzen, den wir mögen - und das überall.

Und der letzte große Grund, um GNUstep zu benutzen, sind die Vorteile des NeXT Interfaces. Dieses Interface ist mit dem Benutzer im Hinterkopf entworfen worden, nicht mit den Gedanken an den Computer. Das bedeutet, dass es einfach ist, und konsistent. Jede Arbeit kann mit möglichst wenig Aufwand erledigt werden.

Das Benutzerinterface

Jedes System hat ein Interface, eine Schnittstelle, um mit dem Benutzer zu kommunizieren. Dies ist das sogenannte UI oder GUI für 'Graphical User Interface'. Die Hauptsache des GUI ist es, dem Benutzer einen Weg zur Verfügung zu stellen, mit dem er Zugriff auf das System bekommt. Man soll in der Lage sein, auf Dateien zuzugreifen, durch Verzeichnisse zu spazieren usw. GNUstep reicht dem Benutzer dazu ein Werkzeug an die Hand, Workspace genannt, das diese Funktionalitäten implementiert. Da GNUstep keine Firma ist, sind wir in der Lage einen Workspace Manager unserer Wahl zu benutzen. Wir haben einen ausgewählt, um zu zeigen, was man von einem Workspace Manager zu erwarten hat.

Der Workspace

GNUstep führt erneut die NeXT-Variante der Benutzerschnittstelle ein. Das bedeutet, dass das Menü und die Anwendung zwei verschiedene Gegenstände auf dem Desktop sind. Falls man vorher mit Microsoft-Produkten gearbeitet hat, ist dies möglicherweise ein neuartiges Konzept, falls man mit dem Macintosh vertraut ist, kennt man dieses Prinzip vielleicht schon, nur dass es etwas anders aussieht.

Ein Fenster beinhaltet das Programm, in diesem Fall ist es der File Viewer, während ein anderes das Menü beinhaltet, welches mit der Anwendung verknüpft ist. Dahinter steckt die Idee, ein möglichst konsistentes Interface zu erstellen und so viel Flexibilität wie möglich zu bieten. Der Leser wird viele Beispiele innerhalb dieses Dokumentes finden, die dies beweisen.

Viele Leser werden wissen, was es für ein Durcheinander geben kann, wenn mehrere Anwendungen offene Fenster auf dem Desktop haben. GNUstep behebt einen Teil dieses Problem mit mehreren Lösungen.

Erstens sollte das Menü genannt werden. Denn nur das Menü des aktiven Fensters wird angezeigt. Sobald der Benutzer das Fenster eines anderen Programmes anklickt, erscheint das Menü dieses Programmes während alle anderen verschwinden. Das sorgt für freien Raum.

Da das Menü eine eigene Sache ist und durch alle GNUstep-Anwendungen hindurch in konstanter Weise auftritt, ist es wohl Zeit, einen genaueren Blick darauf zu werfen. Als oberstes sehen wir den Punkt 'Info'. Das Öffnen dieses Punktes versorgt uns mit weiteren Informationen über die Anwendung, darüber, wer sie geschrieben hat, das Copyright, das Einstellungsmenü und Zugriff auf das Hilfesystem.

Der Dateieintrag ('File') gibt uns Zugriff auf alle Dinge die die Handhabung von Dateien betreffen: Öffnen ('open'), Speichern ('save'), Schließen ('close'), Neuerstellen ('new') usw.

Ebenfalls in allen Menüs vorhanden ist die Bearbeitenfunktion ('Edit'). Sie wird benutzt, um Dinge zu auszuwählen, sie zu kopieren ('copy') und einzufügen ('paste').

Die Sektionen 'Disk', 'View' (Ansicht) und 'Tools' (Werkzeuge) Sektion überspringen wir, da sie spezifisch für GWorkspace sind. 'Services' (Dienste), 'Hide' (Verstecken) und 'Quit' (Beenden) sind wiederum generelle Bestandteile eines jeden Menüs. Dem Leser wird auffallen, dass die ersten und letzten drei immer gegenwärtig sind.

Der 'Services'-Menüeintrag gibt Zugriff auf Programm, welche Helfer für diese Anwendung sind. Wir stellen uns einmal vor, wir hätten eine E-Mail-Anwendung und empfangen ein tar.gz-Archiv, welches ein Unix-Archiv von Daten ist, das gezippt ist. Ein Mailprogramm weiß nicht, wie es damit umgehen soll, aber ein Entpacker weiß es; also könnte der Entpacker eine Hilfsanwendungen für Mail sein und über den 'Services'-Menüeintrag erreichbar sein.

Verstecken ('Hide') sagt es bereits. Das Menü und alle assoziierten Programmfenster sind hinter dem Programmsymbol am unteren Rand des Desktops verborgen. Ein Doppelklick auf das Symbol bringt alles wieder dahin, wo es vorher war.

Und 'Quit'..., ja das hat die Anwendungen geschlossen.

Das Menü kann platziert werden, wo es am angenehmsten und bequemsten erreibar ist. Kein Menübalken am oberen Bildschirmrand (wie im Mac OS) oder ein Menü im Anwendungsfenster (wie in Windows), der Benutzer kann das Menü einfach dahinschieben, wo er es mag. Es ist sogar möglich Untermenüs abzutrennen, wie z. B. das 'Tools'-Menü von seinem Hauptmenü, und es irgendwo anders hin bewegen.

Ein abgetrenntes Menü

Aber nun sollten wir mit der Workspace fortfahren; denn dort gibt es mehr Dinge, die einem das Leben erleichtern. Der File Viewer besteht aus drei Teilen: Eines ist das Shelf, welches dazu benutzt wird häufig benutzte Anwendungen, Dokumente, Links etc abzulegen. Man zieht einfach etwas vom Ansichtsbereich ('Viewing Area') auf das Shelf, sobal man es loslässt haftet es dort fest.

Darunter befindet sich der Symbolpfad ('Icon path'), der dem Benutzer schnell ein Bild davon vermittelt, wo er sich innerhalb des Verzeichnisbaumes gerade befindet und ihm gleichzeitig ein schnelle Möglichkeit zum Zurückgehen bietet: man benutzt einfach den Scrollbalken, um schnell dorthin zu gelangen, wo man vorher war.

Und als letztes gibt es den eigentlichen Ansichtsbereich ('Viewing Area'). Hier sind alle Dateien und Verzeichnisse im Pfad angezeigt. In unserem Beispiel sehen wir eine Auflistung mit drei Spalten, aber natürlich kann das reduziert oder erweitert werden mit weniger oder mehr Spalten. Ebenfalls hat man die Möglichkeit eine Symbolansicht ('Icon view') oder eine Auflistung ('Listing') wie auf Unix Systemen zu haben. Das alles bleibt der persönlichen Wahl überlassen.

Das Dock, App Icons und mini-Windows

Der Desktop

Man kann Anwendungen zwar auf dem Shelf ablegen, aber es gibt einen richtigen Ort, an den man oft benutzte Programme ablegen sollte: das Dock. Der logischste Gebrauch des Shelf ist das Speichern von oft benutzten Verzeichnissen und Dateien, so dass das Dock für oft benutzte Anwendungen verwendet werden kann.

Gedockte Anwendungen sind über Workspaces hinweg verfügbar. Falls man bestimmte Anwendungen nur auf einem bestimmten Workspace benutzen möchte (z.B. den Internet Browser auf einem Workspace und die Grafikanwendungen auf einem anderen), kann der Fiend benutzt werden, um Workspace-spezifische Apps zu halten. Dementsprechend ist der Fiend ein Dock per Workspace. Noch einfacher gehts wirklich nicht.

In der Terminologie von GNUstep ist ein Workspace der betrachtete Bildschirm mit allem darauf. Das beinhaltet die Fenster, das Dock und die Icons. Dabei ist es möglich mehrere Workspaces zum arbeiten zu haben, vergleichbar zu mehreren virtuellen Schreibtischen. Wenn einer voll ist, aber weitere Arbeit ansteht, ohne alles stapeln zu müssen, was da ist, kann man einfach zu einem anderen wechseln, der noch leer ist. Fakt ist jedoch, dass man auch diesen ganzen Mist einmal aufräumen muss, virtuelle Desktops ändern daran auch nichts - leider.

Mit dem Fiend kann man diese Workspaces verwalten. Man kann von einem zum anderen wechseln, sie benennen und Programme verschiedenen Workspaces zuweisen, auf denen sie verfügbar sein sollen.

Einfacher? Okay. Am unteren Rand des Bildschirms sehen wir zwei Arten von etwas das wie Icons aussieht, aber nur eine Art ist ein Icon, das andere ist ein Fenster. Das ganz linken, App Icon genannt, sind die Icons von laufenden Programmen auf dem ganzen System (auf allen Workspaces), die Mini-windows jedoch sind die Programme, die auf dem aktuellen aktiven Workspace laufen. Falls man immer noch das Gefühl hat, dass der Desktop mit Fenster überfüllt wird während man arbeitet (oder man einen sauberen Screenshot für eine Anleitung will... ohne alle Arten von offenen Fenstern), kann man ein Fenster minimieren, so dass es sich zum unteren Rand des Bildschirms verkriecht.

Das zeigt, wie einfach es sein kann.

[ preferences setting time etc. TO BE WRITTEN ]

Anwendungen

Project Center

Im Apps Verzeichnis sind die Anwendungen des Systems installiert. Das Symbol der Anwendungen sehen wir im Icon-Pfad, während im Betrachtungsbereich sichtbar wird, dass eine Anwendung mehrere andere Objekte beinhaltet. Normalerweise ist eine Anwendung im Apps Ordner selbst ein Verzeichnis. In diesem Verzeichnis befinden sich alle Resourcen, die zu der Anwendung gehören. Daraus resultiert eine Erleichterung der Systemverwaltung: eine Anwendung wird einfach durch Löschen der zugehörigen .app-'Datei' aus dem System entfernt.

Die Sektion über Project Center und GORM, die beiden GNUstep Entwicklungsanwendungen, beschreibt die meisten Details dieser .app-'Datei'; doch um die Neugierde etwas zu lindern, ein kleinwenig Aufklärung:

Innerhalb des Ordners befindet sich die eigentliche Anwendungen, gebaut für das jeweilige Betriebssystem. Dies ist die eigentliche ausführbare Datei ('executable'). Daneben findet man den systemabhängigen Pfad zu der ausführbaren Datei. Im Beispiel wurde Project Center auf einem ix86-Rechner gebaut. Auf diesem Weg kann man Apps für verschieden Systemarchitekturen bauen, damit ein Paket erstellen und in die Welt schicken.

Darüber hinaus kann man hier verschiedene Verzeichnisse finden, die verschiedene Resourcen beinhalten, wie weitere Programmbibliotheken (libraries), Bilder, Sounddateien etc.

Bundles und Frameworks

Im vorigen Kapitel haben wir gesehen, dass eine Anwendungen eigentlich ein Verzeichnis ist mit einer 'executable' und all ihren Resourcen. Solch ein Verzeichnis bezeichnet man als ein 'bundle' (dt. Bündel).

Für die meisten Entwickler werden die Begriffe Bundle und Framework (dt. Gerüst) neu sein. Für ein gutes Verständnis von GNUstep sind sie jedoch essentiell, also werden wir sie nun etwas detailierter beschreiben.

Ein Bundle ist, wie bereits gesagt, eine Sammlung von Resourcen die zusammen ein eigenständiges Paket zur Nutzung ergeben. Derzeit gibt es drei Typen von Bundles: Anwendungen, Frameworks und ladbare bundles ('loadable bundles'). Der erste Typ, die Anwendung, sollte bereits geklärt sein, also fahren wir mit den Frameworks fort.

Ein Framework ist eine dynamisch geteilte Programmbibliothek ('dynamic shared library') mit allen ihren Resourcen: einschließlich Header-Dateien und Dokumentation. Es könnte sogar verschiedene Versionen einer Library enthalten, z.B. für Abwärtskompatiblität.

Ein ladbares Bundle ist etwas wie ein Plug-in, außer dass es zwei Arten von ladbaren Bundles gibt, namentlich Plug-ins und Paletten. Ein Plug-in ist ein Bundle, das von einer Anwendung geladen werden kann, um zusätzliche Funktionalität anzubieten, während eine Palette ein Plug-in für GORM ist. Benutzt wird eine Palette, um GORM mit eigenen Benutzerinterface-Objekten zu erweitern. Paletten haben die Dateierweiterung '.palette'.

Alles unabhängig von allem anderen zu erstellen, ist der grundlegende Ansatz von GNUstep. Je weniger Abhängigkeiten, umso weniger läuft falsch im Falle einer Änderung. Der gleiche Ansatz wurde in der gesamten Auslegung des Systems gewählt. Durch das aufstellen von sogenannten Abstraktionsschichten ('abstraction layers') innerhalb des Systems, sind Hardware, Betriebssystem und Benutzerinterface getrennt. Un das nicht nur für den Benutzer, sondern auch für den Entwickler. Dadurch wird das Leben ein Stückchen vereinfacht, mit weniger konfliktreichen Änderungen.

Ein System in Schichten

Die Idee, OpenStep für GNU zu implementieren, ist sehr NeXT-orientiert. Wie NeXT, so ist GNUstep am besten als ein System implementiert, das auf dem Betriebssystem aufsetzt, mit einer klaren Unterscheidung der beiden. Standardmäßig ist der GNUstep Verzeichnisbaum in einem separaten Ordner angelegt, in dem alles was zu GNUstep gehört untergebracht ist. Die Wahl dieser Struktur schafft nur sehr wenige, vereinzelte Abhängigkeiten zwischen dem zu Grunde liegenden Betriebssystem und GNUstep.

OpenStep besteht hauptsächlich aus zwei Libraries: dem Application Kit und dem Foundation Kit. Das Application Kit ist verantwortlich für alle Graphiken, während sich das Foundation Kit für alle niederen, d.h. nicht GUI-bezogenen Arbeiten verantwortlich zeichnet.

Hier ist eine graphische Übersicht des Systems, welche in den nächsten Kapiteln besprochen wird:

Application

Application Kit

gnustep-gui

gnustep-xgps gnustep-xdps Foundation Kit

gnustep-base

Geräteabhängige Erweiterungen des Window-Systems

X-Window-System

Betriebssystem

Tabelle 1: Die blauen und hellgrünen Teile sind eigentliche GNUstep-Bestandteile.

In den folgenden Abschnitten wird das oben präsentierte System von unten nach oben beschrieben, aber zuerst fangen wir mit der Objective-C Programmiersprache an, in der das gesamte GNUstep-System geschrieben wurde.

Die Objective-C Programmiersprache

Die Objective-C Runtime ist Bestandteil des GNU C Compilers (gcc), sowie Teil der NeXT- und Mac OS X-Compiler. Dieser Abschnitt beschäftigt sich jedoch nicht weiter mit der Runtime, sondern konzentriert sich auf die Objective-C Programmiersprache.

Eigentlich ist Objective-C gar kein Teil von GNUstep. Es ist nichtmal eine 'offizielle' Programmiersprache. Genauer gesagt, es gibt keinen offiziellen Standard, der Objective-C beschreibt. Brad J. Cox entwickelte die ursprüngliche Objective-C Sprache, indem er SmallTalk-80-Erweiterungen zu C hinzufügte. Dennis Gladding schrieb 1992 die erste GNU Version, auf die kurze Zeit später eine zweite Version von Richard Stallman folgte. 1993 erschien die nächste Version, geschrieben von Kersten Thorup, der diese Version auch für die eigentliche NeXT Implementierung benutze. Spätere Versionen wurden von Ovidiu Predescu verwaltet und derzeit (2001) ist Stan Shebs von Apple Computer Inc. die verantworliche Person.

Die GNUstep Bibliotheken sind in Objective-C geschrieben. Objective-C ist ANSI-Standard C mit einem kleinen Set von Smalltalk-ähnlichen objektorientierter Syntax und wird für die dynamischste der C basierten objektorientierten Sprachen gehalten.

Als komplette (englische) Objective-C-Anleitungen kannst du das online NeXT manual lesen oder Apples Cocoa Dokumentation benutzen. Aber du kannst auch mit einem einfachen (ebenfalls englischsprachigen) Änfängertutorial beginnen unter: http://www.tenon.com/products/codebuilder/Objective-C.shtml.

Hier ist ein Vergleich der Eigenschaften von C++, Java und Objective-C
	Binding Time	Operator Overloading	Garbage Collecting	Inheritance	Activation/ Passivation	Multiple Inheritance	Supports Protocols/ Interfaces	Supports Categories
C++	Either	Yes	No	Yes	No	Yes	No	No
Java	Either	No	Yes	Yes	Yes	No	Yes	No
Objective-C	Either	No	Possible	Yes	Yes	No	Yes	Yes

Special Features of Objective-C

Objective-C has some special features which make the language elegant and easy to use. These are protocols and categories.

Protocols in Objective-C are very much like interfaces in Java. A protocol declares the methods which should be implemented on a class which defines a given protocol. Since Objective-C lacks multiple inheritance, we can use Protocols to make up for this. I personally don't like the idea of multiple inheritance, but to each his own. Speaking of multiple interhitance, it is possible to make up for the absence of protocols/interfaces in C++ by using an abstract base class combined with multiple inheritence. Although this is somewhat kludgy it will work, but there is no denying that the Objective-C and Java way of doing this is much cleaner.

Categories allow you to add or repair functionality of a given class without having access to its source code. Whenever an object of the type you added the category to is instantiated within your program, it has the extra methods you added to it.

The Device Dependant Windowing System

Here starts the insight of the great benefits of a layered system. By abstracting GNUstep from the actual windowing system (On Unix X, Windows voor Microsoft products and DPS for e.g NeXT and Apple operating systems) life gets better.

A windowing system is a piece of software that talks to the hardware (graphics adapter) that displays letters and images on your screen. This is the first step in making sure, next to the OS ofcourse, that applications and thus developers do not need to worry about what kind of hardware is installed. This is not a GNUstep achievement, but just fact of life.

[ TO BE WRITTEN: DGS stuff ]

The Foundation Kit

As a developer you probably don't wanna know anything about every OS. You don't want to know the internals of Windows, Unix and Mac OS. You want a clean API for your programs to talk to. On the non-graphical side that will be the Foundation Kit for you. This Kit gives you all you need to write non-graphical applications.

The Foundation Kit or gnustep-base (as it is called in GNUstep) includes the root class, classes for basic data types, like strings and byte arrays, classes for storing objects and ofcourse classes representing system information, like date and time, communication ports, etc.

The Application Kit

This is probably what you all have been waiting for, a complete system independent API to write your applications against and what makes them portable. A true write once, compile everywhere system. The Application Kit (the entire blue part in table 1) makes it happen.

But as you can see the Application Kit consists of three different pieces of work: gnustep-gui, gnustep-xdps and gnustep-xgps. Let's discuss them one by one.

gnustep-xgps is a back-end system with which you as a developer need not be concerned. It is this piece of software that talks to the X-window system and does all the neat stuff to make your program look as you intended it to be.

The same goes for gnustep-xdps only this piece uses PostScript and talks to a PostScript server, like DPS from Adobe or DGS, the GNU implementation of DPS.

A more important piece for you is gnustep-gui. This is the API that your applications will talk to. gnustep-gui is what is described in the OpenStep standard as the Application Kit from a programmers point of view. The other two are just their to make it easy on the GNUstep developers part and to make portability as easy as possible. You see, just writing a new backend for a complete different windowing system is easier then writing a new Application Kit.

The filesystem

The GNUstep filesystem expects certain things to be in a certain place. Although applications can be placed everywhere on the system (they are self contained afterall), it might be that some things might not work directly if they are not placed in the Apps directory.

The workspace manager e.g. searches on startup for available resources on the system so the resources (services) can be offered to other applications. Now imagine that an tiff-image viewer is not placed in the Apps directory, so the workspace manager doesn't know there is a tiff-viewer around. When you want to open a tiff in an editor you'll have to point the editor to the place where the tiff-viewer is.

This is not convinient. So you are advised to place the software where it belongs, and to explain where things belong, we have a little chapter about that.

First of all a little bit about the conventions used. A directory seperator in this chapter will be the / on Windows systems this is actually the \, so people using GNUstep on Windows should remember to read \ when they see /.

Another thing is the place where GNUstep is installed. The entire GNUstep system lives in it's own tree, but that could be placed everywhere. The default on Unix systems is /usr/GNUstep, but it could also be /opt/GNUstep or every other place for that matter. To make it easy we will call /GNUstep the root.

Okay, that's a start we have the root of GNUstep. Directly under the root directory you will find three direcories:

System Network Local

System and Local have the same structure. The only difference is that System contains the default (pre-installed) stuff, while Local contains those software products you installed yourself e.g. from source. And another thing that is also different is the /GNUstep/Local/Users directory. Since GNUstep is created for use on a multi-user system this directory is meant for the users home-directories. Default one user is present in this directory and that is Administrator.

The Network directory is empty by default. The idea is that you could share your applications across networks. That way you could save on diskspace and maintenance. The default way to share your information is by using the system-name as the mount point (mapping) and use the tree as described in the '/GNUstep/System tree'-section underneath that.

The /GNUstep/System tree

The first directory we introduce is the Makefiles-directory. GNUstep has it's own makefile system. GNUstep Make is a system of scripts that allows you to create a simple Makefile which in turn allows you to compile, install and even distribute in RPM or deb format the package you're building. A more complete description can be found in the gnustep-make section.

This directory holds everything that is needed for the Make-system.

Ofcourse there is the Apps directory, but you already knew that. But one major point is still to be made. The Apps directory only contains graphical applications. The none graphical applications are in the Tools directory. All commandline tools can be found here.

The Documentation directory speaks for itself I guess. It contains the documentation.

Now to someting more exciting the Developer directory. This directory holds all the developer resources. Including the Palettes for GORM. What's however not contained in this directory are the header files. Those files are so important that they deserved a directory of their own called Headers.

Are we left we two more directories that create sometimes some confusion due to their naming. One is called Library and the other Libraries. The most simple way is to think about a Library where you can get books. That is a place that holds information, where Libraries on the otherhand is just plural for library which is a piece of software that is a shared object.

The Library directory contains resources like bundles, colors, services, etc which can be read by the system. Like in a real Library.

The Libraries directory on the contrary contains the libraries sorted on architecture and operating system. Meaning that Libraries/ix86/linux-gnu/gnu-gnu-gnu contains the Foundation and Application Kit libraries for your GNUstep system. Or is it our GNUstep system?

The path ix86/linux-gnu/gnu-gnu-gnu has a special meaning. GNUstep is capable of providing binaries for more then one architecture to live in one directory. This way you as a developer can create so called 'fat' bundles. That are packages containing the binaries for all architectures you want to support, so you only have to maintain one archive. This is easy for you, but the system needs to know which binary to start. Executing a PPC executable on an Intel processor, is mostly not a good idea.

To solve this there is a tree within every bundle that has a path to the system dependant program or library. The first part is the hardware indicator. For Intel that is ix86. The second part describes the operating system. In our case we are running GNU/Linux (meaning the Linux kernel and the GNU tools), and the last part describes how GNUstep was build. The gnu-gnu-gnu tells us that from left to right, the Objective C runtime used was the GNU one (which is correct since it was the one from the GNU C compiler gcc), the second part tells us that the Foundation library was the GNUstep one. It is possible to build GNUstep with a NeXT system then it would have shown nx. And the last part is the Application Kit part, which also happens to be the GNUstep version.

To give you a better understanding of this here is a little table to explain a couple of the possible combinations:

Objective-C runtime Foundation library GUI library Library combo

NeXT NeXT NeXT nx-nx-nx

NeXT PDO NeXT nx-pdo-nx

NeXT PDO gnustep-gui nx-pdo-gnu

NeXT libFoundation gnustep-gui nx-fd-gnu

GNU gnustep-base gnustep-gui gnu-gnu-gnu

GNU libFoundation gnustep-gui gnu-fd-gnu

Das gnustep-make Paket

Das gnustep-base Paket

Das gnustep-gui Paket

Das gnustep-xdps Paket

Das gnustep-xgps Paket

Entwicklungswerkzeuge

Die beiden Hauptanwendungen sind ProjectCenter und GORM, welche für schnelle Anwendungsentwicklung (kurz RAD, 'rapid application development') unter GNUstep benutzt werden. Die beiden Anwendungen sind noch im Beta Stadium, also ist dies Blick dessen, was die Zukunft bereit hält.

ProjectCenter

ProjectCenter ist das GNUstep-Equivalent zu Apples Project Builder.

Zukünftige Versionen von ProjectCenter.app werden einen vollständig integrierten Debugger und einen emacs-ähnlichen Editor enthalten. Derzeit kann PC.app zu einem gewissen Grad zum Editieren von Dateien und Kompilieren von Projekten verwendet werden, ist jedoch noch im Beta-Stadium.

Bitte besuche http://wiki.gnustep.org/index.php/ProjectCenter für weitere Informationen.

GORM

GORM steht für GNU Object Relationship Modeller. Hier ein Schnappschuss von GORM:

GORM erlaubt es Entwicklern in kurzer Zeit GUIs für Anwendungen zu kreieren. Ein Beispiel: um eine Aktion zuzuweisen, klicken wir mit gedrückter STRG-Taste auf ein Control, dem wir eine Methode zuweisen wollen und ziehen den beidseitigen Pfeil zu dem Objekt, mit dem wir die Methode aufrufen wollen. Ein Dialog erscheint mit den Namen aller auswählbaren Methoden. Wenn ich zum Beispiel möchte, dass die Methode foo von einer Instanz des Controller aufgerufen wird, wenn ich einen Button auf der GUI betätige, ist alles, was ich zu tun brauche:

STRG-Klick auf den Button, der daraufhin mit einem 'S' als Ursprung ('Source') markiert wird, dann ziehe ich den doppelseitigen Pfeil zum Controller Objekt, das daraufhin mit einem T als Ziel ('target') markiert wird. Wenn der Dialog erscheint, kann man die foo Methode aus der Liste aussuchen. Das Umgekehrte geschieht, wenn man den Wert einer Variablen auf der GUI anzeigen will. Zuerst STRG-klicken wir auf das Objekt, dessen Attribute wir anzeigen möchten, dann ziehen wir den Pfeil auf das Textfeld, auf dem es angezeigt werden soll.

Gehe zu ftp://ftp.gnustep.org/pub/daily-snapshots für den neuesten CVS snapshot von GORM (Paket dev-apps).