This is the README for MOKit.1.0.0.s.tar.gz [Download] [Browse] [Up]
To the Archive Administrator: This is the 1.0.0 release of the MOKit free object kit. It is a collection of free fully re-usable Objective-C classes, InterfaceBuilder Palettes, and example Applications. Full source code is provided for everything. The README.rtf file from the top-level Project directory is included (in ascii form) below... ----------------------------README starts here----------------------------- MOKit docs, Copyright ©1992, 1993, 1994 by Mike Ferris. All Rights Reserved. By Mike Ferris -- February 19th, 1994 MOKit Version 1.0 Welcome to the 1.0 release of MOKit! There have been a number of minor changes, some new objects, and a few bug fixes. See the file README_ChangeLog.rtf for details on the differences from the first release. The most exciting new stuff (the document architecture) is described more fully in the Documentation. What is MOKit? MOKit is a set of objects which I have written. I am making it available for use by whoever wants to use it. Full source is provided for all the classes, palettes, and examples. The following notice appears in each source file in the kit. // ABOUT MOKit // by Mike Ferris (mike@lorax.com) // // MOKit is a collection of useful and general objects. Permission is // granted by the author to use MOKit in your own programs in any way // you see fit. All other rights pertaining to the kit are reserved by the // author including the right to sell these objects as objects, as part // of a LIBRARY, or as SOURCE CODE. In plain English, I wish to retain // rights to these objects as objects, but allow the use of the objects // as pieces in a fully functional program. Permission is also granted to // redistribute the source code of MOKit for FREE as long as this copyright // notice is left intact and unchanged. NO WARRANTY is expressed or implied. // The author will under no circumstances be held responsible for ANY // consequences from the use of these objects. Since you don't have to pay // for them, and full source is provided, I think this is perfectly fair. As outlined above, anyone is free to use these objects in their own applications. There is NO WARRANTY of any kind. Now on to more interesting details. What classes are in MOKit? MOKit currently contains 10 classes, 2 palettes, and 2 example apps and other assorted goodies. There is full Next-style class documentation for each class. Most of MOKit should be ready for this to be version 1.0 (although, remember, no warranty is provided, see above). However, starting in this release, there will be two grades of classes in the kit: Release level objects and Pre-release level objects. Release level objects are those that have been in the kit for several versions and are considered stable (although remember there is no warranty :-). Pre-release level objects are new to the kit. Pre-release level objects have not had a lot of people besides myself using them, and thus are more likely to contain oversights in implementation or (heaven forbid) bugs. Below is a summary of the classes in this release. Release Level MOString MOSybaseString MOPathString MORegexFormCell MORegexTextCell MODateFormCell MODateTextCell MOMatrix MODocumentWell Pre-release level MOClassVariable MOController MODocController MODocManager MODocType Here's a brief description of each class included in this release: Release level MOString - yet another string class. This class basically provides a wrapper for a c-style null-terminated string. The class knows about Next-style unique strings as well. Many methods for accessing and modifying the string are provided including a fairly complete set of covers for the regular ANSI string library functions. MOSybaseString - a subclass of MOString which adds a few methods for dealing with string's that will be used to build qualifiers for Sybase. Primarily the class provides a way to make a given string case-insensitive SQL-style (eg. changing "a" to "[aA]"). It also provides a method for converting unix style wildcard characters into their SQL equivalents. MOPathString - a subclass of MOString which is good for treating strings as pathnames (especially file pathnames). It provides a lot of methods for accessing pieces of paths. MORegexFormCell - a subclass of FormCell which adds input validation via regular expression pattern matching. Each cell can have a list of regular expressions associated with it. When the user tabs out of the field, the entry is checked against the regular expressions. The entry must match at least one of the cell's expressions or it is not accepted and the field does not allow editing to end. It is possible to check a wide variety of input formats via regular expressions. MORegexTextCell - a subclass of TextFieldCell which is to TextFieldCell what MORegexFormCell is to FormCell. MODateFormCell - a subclass of MORegexFormCell specifically set up to check dates. Dates cannot be checked completely by regular expression matching, so this class lets regular expressions do what they can and then finishes validating the date. The class also allows customizable reformatting of entered dates via a printf style format string. MODateTextCell - a subclass of MORegexTextCell similar to MODateFormCell except that it is a TextFieldCell by ancestry. MOMatrix - a subclass of Matrix that allows variably sized rows and columns. MODocumentWell - a subclass of View that implements a document well that can be the destination and/or source of file drags. It can open its file by double-clicking too. Pre-release level MOClassVariable - this object can be used to implement class variables that have a separate value for each subclass. Internally this is done by having the class which is attempting to set or get a value, provide its class pointer. A hashtable is used to keep separate values for each different class that tries to use the variable. This object's use is demonstrated in MOController. Although this is the 1.0 release, this class should be treated as pre-release. MOController - this object manages a nib file with a window in it. It is meant to be used as the file's owner of a nib that contains basically a single window which an application only ever has one instance of. For document windows see below. This is an abstract superclass. Although this is the 1.0 release, this class should be treated as pre-release. MODocController - this object is a subclass of MOController which extends MOController for use with document windows. It supports all the standard document stuff. MODocControllers are generally managed by a MODocManager. This is an abstract superclass. Although this is the 1.0 release, this class should be treated as pre-release. MODocManager - controls a set of MODocController subclass instances (potentially from different MODocController subclasses). Although this is the 1.0 release, this class should be treated as pre-release. MODocType - used internally by MODocController to keep track of save and open types that a particular MODocController subclass supports. Although this is the 1.0 release, this class should be treated as pre-release. What else is in MOKit? As well as the class sources, headers, and documentation, MOKit contains several other peices. Palettes MORegexPalette - a palette containing many MORegexFormCells, MORegexTextCells, MODateFormCells, and MODateTextCells within Forms or Matrices. A Form/FormCell and Matrix/TextCell combination are provided for each of the following data types: integer, float, time, date, and generic (no preset expressions). MODocWellPalette - a palette containing a MODocumentWell. Examples MOMatrixTest - an example of the use of MOMatrix. MOStringTest - an example and test harness for MOString and its subclasses. MODocArchitecture - an example of how to use the document architecture classes to build a document based app with multiple document types. Bundles A class-bundle for each individual class is included with MOKit. These bundles are primarily of use to palette designers. See the README in the Bundle directory for details. Also, a MOKitBundle is provided that contains all non-code resources used by classes in the library. Currently this is just two nib files used by the document architecture classes. If you use MOKit in a project you should copy the MOKitBundle.bundle to your project directory and add it to "Other Resources" in your project. DocTemplates A set of templates for producing documentation consistent with Next's developer docs. Makefiles There is a library makefile which extends the Project Builder Tool type project to support libraries. It depends on several of the makefiles in /NextDeveloper/Makefiles/app. There is also a makefile for dealing with some annoying Next/CVS issues. Thanks are due to Art Isbell for both these makefiles. These two files are in the Makefiles directory along with other minor stuff. There is also a top-level makefile for making and installing the whole project. How do I install it? There is a master Makefile in the top-level MOKit directory (the directory where this README file was). The default install location is various directories under /LocalDeveloper. If you want to change this, override INSTALLROOT on the command line to make or edit the first few lines of the master Makefile. When installed, MOKit will leave files in four places. All of them will be under INSTALLROOT. It installs the library (or libraries) in $(INSTALLROOT)/Libraries. The headers go in $(INSTALLROOT)/Headers/MOKit. The docs go in $(INSTALLROOT)/Documentation/MOKit. The palettes go in $(INSTALLROOT)/Palettes. Once the installation locations are set up like you want, cd into the MOKit directory and type make install. This will build all the necessary binaries and install everything you need (library, headers, documentation, and palettes). The normal install process builds binaries for the machine you compile it on only. Fat binaries can be made for all the different projects, but you'll have to do it individually. How do I uninstall it? To remove all traces of MOKit from the installation location, cd into the top-level MOKit directory and do a make uninstall. How do I clean out the object code and binaries and such? To remove all derived files from the MOKit project hierarchy, cd into the top-level MOKit directory and do a make distclean. What else can the top-level Makefile do? These are the supported targets... lib builds the optimized library debuglib builds the debugging library profilelib builds the profiling library bundles builds the individual class bundles examples builds the example apps (depends on lib) palettes builds the IB palettes (depends on bundles) all build the lib, bundles, examples, and palettes targets install installs the library, docs, headers, and palettes (depends on lib and palettes) uninstall removes all traces of MOKit from the installation area distclean removes all derived and backup files from the MOKit distribution directory cvspack finds and archives all CVS administrative directories within file-packages (ie nib files and rtfd files). This target is used in conjunction with maintaining MOKit with the CVS revision control system. cvsunpack restores the CVS administrative directories previously archived with the cvsco target. This target is used in conjunction with maintaining MOKit with the CVS revision control system. cvstrim finds and removes all CVS administrative directories from MOKit's compiled products. Maiking this target after bulding MOKit will strip the unneeded CVS directories from all the apps, palettes, bundles, etc... This target is used in conjunction with maintaining MOKit with the CVS revision control system. More specialized control over building can be accomplished by using the Makefiles in the individual directories. Future Directions This is the 1.0 release, and it will be the last release of MOKit. MOKit will be merged with MiscKit, a similarly free kit of objects with many contributors administered by Don Yacktman. I urge all MOKit users to migrate eventually to MiscKit. I am hoping the transition will be relatively painless. I especially urge you to go to MiscKit, once we've merged, if you want to use the new document architecture. This version of MOKit contains new classes to support a document based application architecture which does a lot of work for you. Currently it is the first release. There are bound to be problems. They will not be fixed in MOKit, but it is certain that active improvement of these classes will occur in MiscKit. Well, that's all for now. Please let me know if you use the kit. Bugs, comments, and suggestions can be sent to: Mike Ferris mike@lorax.com
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.