CD, CDDirectory, CDOrient, CDBasics, CDInstances

CDCells, CDRects, CDSymbolicObjects

CDExtras, CDMarks

CDImports, CDRepetitions, CDAtomicObjects, CDTexts, CDPolygons

CDGenerate, CDGenerateBackdoor

CDGenerateImports, CDRemote

CDUtil, CDCreateLabels, CDCleanUp

TerminalIO, CDIO

TokenIO, CDRopeViewer, CDMark

CDProperties, CDValue, CDEvents, CDCallSpecific

CDSequencer, CDMenus, (CDGenerate)

CDTipEtc, CDDefaults, CDLRUCache, CDPanel, CDColors, CDAtomicObjects, CDDefaultProcs, CDLayers

CDOps, CDCommands, CDCommandOps, CDViewer, CDDirectoryOps, CDSimpleOps, CDPropertyTools, CDCleanUp

CDSimpleRules, CDViewer

CDStretchyExtras, CDImportsExtras, CDPrivate, CDSimpleOps, CDMenuSpecials

CDViewHighlight, CDViewer, CDErrors

CDVScale, CDVFurtherPainters, CDVArrow, CDVTicks, CDVPrivate, CDViewerBase

CDDrawQueue, CDLayers

CMos stuff

NMos stuff

CStitching

The style rules make it possible for new people to maintain code, without learning for years about tioga formatting and such crap. (I personally refuse to maintain any program where editing shows to be too painful)

No formats except "code".

Only Cedar style.

No looks which do not appear with the <CTRL>-M command; optional exception: to make interim warnings. You may use XXX or ??? to mark warnings. I hate greek characters in program code and I never have the Idea that a variable "greek lambda" and a variale "l" is the same for the compiler...(nor do I know [or want to know] how to edit that) Greek characters in comments are ok, as long as the size of the font does not change.

Names of procedures are bold, independant if their type is an identifier or a PROC constructor. Names of procedures types are NOT bold.

Use Mesa convention for smaller-uppercase... (optional exception: multiword-constants may be made with lower case letters only, are also acceptable).

Use -- for comments in the middle of code, it's easier to read than looking at the font.

Don't use Cedar's object notation for your own types. Exception where usage of object notation is ok are Cedar types which are very well known, like IO.STREAM, Rope.ROPE and Imager.Context.

Avoid non-readonly public variables in public interfaces.

Is the interface complete?

Are the procedures commented?

There is always a client who wants to use it for something you hav'nt thought at.

Df files must be verifyed, with 0 errors and 0 warnings.

Do the release version number crap, it's necessary: if the amount of existing code increases we cannot do nice releases of everything at the same time; different releases must be able to coexist.

A Df file has an owner, do not change it nor its contents without notifying him.

Where ever properties are provided for clients, there MUST be comment whether clients have to follow the CDProperties registration rules or not (This 1 bit decision is mandatory, and there exists no maybe). If the CDProperties registration rules do not hold for some property lists, these lists MUST NOT be written out on ChipNDale files. (It would be really a show stopper, not just a style violation)

There is a file ChipNDale-Registrations.tioga which lists some registered features.

Do write new modules, change existing ChipNDale modules only later when the new stuff is tested and accepted. This rule has two exceptions: 1) small bug corrections [Feature adding is NOT bug correction, please]. 2) The owner or maintainer of a module owns it and may change it without following this rule.

Your free to write your own extensions, but your extension should not restrict other people to write other extensions; violaters will end up with their code not beeing used.

Please think at the maintenance problem. Even if your code is good and bug free, ChipNDale is still evolving, therfore your code has to be updated.

It's better to write a small peace of code which does a complete job, than to have a big module which needs some finish; remember whoever makes the finish will not know your style and intentions by hart.

When your job ends in changing an existing module, try not just to add the new feature. Try to add it such that improving the existing code is not more difficult than without extension. Some modules (of mine) are really not (yet) perfect, and improving the functionality must not prevent later improving the structure.

Use the ^-middle command; a popup menu allows you to make an event handler which has access to the design.

Register a command with CDSequencer; Your command procedure will be called and the design is given as a parameter to the command procedure. The command procedure is either called because of an tip-table entry; or, your module registers an entry in a popup menu using the module CDMenus.

If interactive access is important: use a CDSequencer command.

If it returns an object: use a CDGenerate.GeneratorProc.

If running from commandfile is important: use the Cedar commander.

Create the design; specially good for commandfile usage.

Modify an input design

The command should check for abort! well short commands which are immediately finished don't have to. There are several ways to check for abort.

Certain modules use global variables which must be protected; CDCommandOps.CallWithResource is the tool to manage such resources.

Example of ChipNDale usage

Copyright © 1985 by Xerox Corporation. All rights reserved.

by Christian Jacobi, June 5, 1985 8:02:35 pm PDT

Last Edited by Christian Jacobi, July 10, 1985 10:28:49 am PDT

CD,

CDGenerate, --0

CDDirectory,

CDUtil;

IMPORTS CDDirectory, CDGenerate, CDUtil =

--this generator fetches the objects "x", "y" and, "z" and creates a cell "test"-- --4

--which is an abut of "x", "y" and, "z" in x direction to the right.

BEGIN

ob1: CD.Object ← CDDirectory.Fetch[design, "x"].object; --5

ob2: CD.Object ← CDDirectory.Fetch[design, "y"].object;

ob3: CD.Object ← CDDirectory.Fetch[design, "z"].object;

ob ← CDUtil.CreateSimpleCell[design, LIST[[ob1], [ob2], [ob3]], "test", right]; --6

END;

-- cdCoords: chipndales internal and native coordinate system used in Instances

-- interrestCoords: base of interest-rects.

-- originCoords: invariant fake origin which for cells never changes, but might be far off...

If you want to do all the computations yourself.

ChipNDale internally uses ALLWAYS cdCoords. That where its name come from.

If you ask fans of abuts.

If you want a coordinate system where you have your own control and where the coordinates of object origins never change underneath you.

If you find numbers in data types of ChipNDale, like in Instances, these numbers are cdCoords.

cdCoords are actually the real truth, but they have some severe problems for certain applications. To gain (significantly!) speed in the process of displaying ChipNDale designs in viewers and other devices, cdCoords are defined such that the [0, 0] origin in cdCoords matches the lower left point of objects. Lower left point is defined as lower left point of the object which needs to be drawn. (There might be elecrical, magical or other influences more to the left or lower, but this lower left is used to determine the clipping boundary for displaying). Unhappily when cells are edited the position of the lower left point might change relative to some stable points in the cell. To maintain the lower-left-[0, 0] invariant ChipNDale (at some time) performs a coordinate system translation (called reposition); the position of all instances in the cell will change. If you maintain a copy of some coordinate in the cell, your copy probably will no more be correct.

When ChipNDale repositions a cell this is really made complete: the instances inside the cell get new coordinates. All instances of this cell in the whole design are then checked and translated, such that it exactly compensate for the coordinate system translation inside the cell: The design as a whole does not change. To get this process right it is necessary that the directory invariants are hold.

The complicate reposition process may be speed up if a cell is first created and repositioned and only thereafter included into a design. IncludeMode is a type which allows to postbone repositioning on IncludeOb, it can then be done using RepositionCell.

The position of an oriented object in cdCoords is the position of its lower left point after the orientation is applied.

The interest rect is an (artifical) rectangle denoting the users interest. It might therefore be conveniant to use it's lower left point as origin of some coordinate system. This is specially the case for abuts.

The coordinates returned by a procedure CD.InterestRect[mumble] are of course cdCoords.

The coordinates of the interest rect might change on any repositioning process, the coordinates of the interest rect might also change on user requests. Finally, when the interest rect is defaulted, its coordinates might even change by including or removing sub-objects into a cell.

The position of an oriented object in interrestCoords is the position of the lower left point of the already oriented interest rect.

This is the hassle free coordinate system for lazy applications. The position of the origin is returned by CD.ClientOrigin and is of course told in cdCoords. Whenever some repositioning happens the position of the origin is updated, such that relative positions of points relative to the origin will NOT change. There is no guarantee that with multiple edits the origin might not lie outside a cell...

The position of an oriented object in originCoords is the position of the objects origin.

The origin of rectangles is the lower left point of its interest rect before its orientation.

The wonderfull stableness of these originCoords is paid by needing more overhaed at run time.