MOKit

An Open Source Framework to extend Cocoa

MOKit Home Page

• Basic Info
• Detailed Info
• Release Notes
• Developer Info
• License

SourceForge Services

• Project Summary
• News
• Files
• Forums
• Mailing Lists
• Tracker
• CVS Info

Developer Info

This page has information that will be of interest to folks who want to get involved with the MOKit project. If you simply want to use MOKit, you should download a released version and just use it. But if you want to become more involved with the development of MOKit itself, read this information.

Getting Releases

The latest release, 2.8 is available from SourceForge. See the project's File Download section. Releases prior to 2.7 are available only at http://www.lorax.com/FreeStuff/MOKit.html.

Using CVS

To get started with MOKit's CVS repository, you can use the following two commands:

• cvs -d:pserver:anonymous@cvs.mokit.sourceforge.net:/cvsroot/mokit login
• cvs -d:pserver:anonymous@cvs.mokit.sourceforge.net:/cvsroot/mokit co -P MOKit

Just hit return when it asks for a password.

I recommend using the -P option with "cvs checkout" commands and the -P and -d options with "cvs update" commands. In fact, I recommend simply putting those options into your ~/.cvsrc so they will always be used. Also, I personally like the -u and -w options for the "cvs diff" command.

For more information about using SourceForge's CVS server, please see the SourceForge Site Documentation.

Getting Involved

If you want to get involved with the MOKit project by suggesting features, reporting bugs, contributing code, or whatever, post to the discussion forums or just mail me.

I am still becoming familiar with how SourceForge works, so bear with me.

Submitting Bugs

Bugs will be tracked through the SourceForge bug tracker. It might be a good idea to bring up your bug on the forums or mailing lists prior to submitting it just to get confirmation that it sounds like a real bug and that it is not a duplicate of a known issue.

Submitting Patches or New Features

If you have code you would like to contribute to MOKit, start a discussion about it on the Developers forum or post to the mokit-develop mailing list. In your post give the general details of what you're proposing fixing/changing/adding. Do not include code unless it is very small (eg a small bug fix may be best described by the actual code).

Here are some guidelines (I am not going to be real strict about any of this, at least at first, but the less work I have to do to the code, the quicker it might be checked in):

• Consider the general utility of what you have done. MOKit tries to include stuff that is potentially useful to a wide audience. If your change or addition is too obscure or too vertically oriented, it may not make an appropriate addition to the kit.
• Public API is forever. Make sure you've thought about what added API should be public and what should not. This is especially important for folks adding new classes.
• Make sure the code works and has been tested. Especially for new features, including a test program along the lines of the test programs that are there already would be much appreciated.
• Public API should have HeaderDoc documentation in the header where it is declared.
• Try to conform to the indentation and other formatting conventions of the rest of the code. Please use spaces only to indent and use a four-space indent width. Use the top-of-file comment structure that the rest of the code uses. Make sure to include the license/disclaimer text at the bottom of files.
• All new text files MUST be UTF-8 encoding (unless there is an overriding reason for them to be in another encoding.) Strings files should be straight two-byte Unicode (not UTF-8).
• "Convenience" methods that serve to replace only a couple lines of equivalent code are usually not worth the additional API exposure. For example adding a -scrollToEndOfText method to NSTextView would really only replace the code [textView scrollRangeToVisible:NSMakeRange([[textView string] length], 0)] and is really not worth the additional API.
• Do NOT bother updating the README or ReleaseNotes rtf files.

The general process for getting stuff included, at least for now, will be to discuss it on the forums/mailing lists, refine API and so on through the discussion, get some agreement on the change, and then get it checked in. For now, the last step will be done through sending the diffs or modified project to me so I can commit it. Over time, active developers may get CVS commit access of their own.