This is ProgrammerDoc.rtf in view mode; [Download] [Up]
Informer programmer's documentation Version 1.1 November 1993 Max Tardiveau Introduction Informer started from a simple fact : there is a lot of information about my machine that I want to know, but I always forget how to get to it. Most of that information is readily available from numerous commands (vm_stat, hostinfo, netstat, etc...), but somehow, I never remember them. I guess I am more the kind of guy who prefers to pick from a menu rather than typing arcane commands. Anyway, Informer is my attempt at centralizing all the information possible into one program. That is possible only because Informer is highly modular. In fact, the program itself is just a shell. All the work is done by a number of modules, each of which is dynamically loaded as needed. Each module takes care of a certain class of information. For instance, there is a module for Mach tasks, and another one for virtual memory. This approach has many advantages : it simplifies the development of new modules, it makes reorganizing the information structure very easy, and it allows painless updates of the program. Organization of the Informer library Informer is a .app file package. It contains the application per se, called (surprise !) Informer, and a directory called Lib, which contains a hierarchy of directories containing the inspectors. The hierarchy of directories determines the presentation of the top browser in an Informer window. By looking at the organization of the directories, and comparing it with the organization of the browser, you can easily understand the relation. There are three types of directories : plain directories, item directories and list directories. · Plain directories simply add a level to the hierarchy. · Item directories (distinguished by a .item suffix) contain all the files necessary for a static item in the browser. For instance, a directory called Virtual memory.item would contain all the files necessary to display the virtual memory inspector. · List directories (distinguished by a .list suffix) contain all the files necessary for filling a column of the browser, and for inspecting each item of that column. For instance, a directory called Tasks.list would contain all the files necessary to list all the tasks, and to inspect each of them. All directories give their name to the corresponding item in the browser; item and list directories, of course, lose their suffix. It is perfectly acceptable to use spaces and other signs in these names. Directories whose name begins with a period do not appear in the hierarchy. This is convenient to temporarily disable a level, for instance. Item and list directories must contain at least one file : Main.o, which contains the main class. In addition, if the class is a subclass of the abstract class InformerInspector (which is normally the case), the directory must also contain the file (or directory for NextStep 3.0 and later) Main.nib, which contains the user interface. If the directory contains a file called HELP.rtf, the corresponding inspector will enable the Help button in the Informer window, and when that button is pressed, it will open a window containing that HELP.rtf file. If the directory contains a text file called Libs, Informer will load the files named in this file along with Main.o. If the file has a relative pathname, it is assumed to be in the current directory. This is useful for classes that require a special library, or for loading an additional class. Writing an Informer inspector Writing your own inspector to add it to Informer is very easy if you know how to access the information you want to display. It can be arbitrarily difficult if the information is hard to get. In any case, the Informer side of things is easy to master. An Informer inspector is normally a subclass of InformerInspector. Looking at the code of existing modules is the fastest and easiest way to learn how to write your own. System Info/Kernel Information is a good example of a very simple module. Kernel servers is a good example of a list module. See the documentation for the classes InformerCell, InformerInspector and InformerWindow. The real reason that made me write Informer is that deep-down desire to know what is really happening inside the machine, stemming from a shameful past as an assembly-language programmer...
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.