CsLib

• Introduction
• Overview
• Background
• Goals
• Acknowledgements

Introduction

CsLib is a cross platform foundation class and programming method designed for the scientist/programmer. The scientist/programmer may not have taken a course in C++, and may have learned programming on their own, and would like to spend their mental energies on developing algorithms and answering scientific questions. They would like to keep programming simple and yet they may want others to eventually use their algorithms in commercial programs. CsLib provides a simple environment by defining default behaviors such as opening a window, if they are not explicitly programmed, and defining default locations of objects in a window, and responding to mouse and other events. CsLib removes from the programmer programming steps that are common to all data objects, such as display management, event handling, and opening of files.

Cslib runs on Mac OS X with the Carbon and Mach-O GUI, Microsoft Windows XP with the Win32 GUI, and is roughly sketched out in X Window / Motif (Linux). It contains a minimum number of calls to the operating systems and these calls are isolated to about 10 source files (plus their respective header files). The majority of source files (currently 20 plus their respective header files) are operating system independent. The core of the library is the CsData class defined in files CsData.cc and CsData.h. All services common to the notion of "displayable data", is contained within CsData. By use of CsData as a base class, a derived class object may open its own files, display, accept events and save itself in a minimal 5 line program. This provides the possibility of building prototype software within a day that can be eventually expanded to a full graphical application or a device driver using C++ in a homogenous environment. This is in stark contrast to the current state of the art, an in-homogenous compiled/interpreted environment such as Java/C++, IGOR/C, xxxx/C++, where "xxxx" is your favorite analysis program.

We plan to use CsLib for future projects we do. As such we will be developing 3D imaging, movies, oscillographics, and spectral displays. These applications will eventually be available to C++ scientific users in much the same terms as Image/J is available to the Java imaging community.

We invite collaborators from scientific C++ programming circles.

Overview of CsLib

< eventual reference to programmer's manual >

Background

The idea behind Cslib came from our internal need for a cross platform foundation for future code development in C++. The structure of CsLib was inspired by Image/J, written by Wayne Rasband at NIH. In Image/J, you may edit and execute Java code from within the Java application Image/J. In our case, CsLib lives within the CodeWarrior development environment which provides powerful editing capabilities. The programmer then runs the program with a graphic debugger. When satisfied, the debugged program may be run on any similar machine without further compilation.

We had developed a common code base written in Pascal that was reused many times. Pascal is considered obsolete and we are forced to retool in C++. Dawn Gregory wrote our first C++ application, Score. The program had two design goals: fast delivery and clean organization. While it met these goals, the classes were OS dependent and too specialized to be used in new applications. Also, the code was written before Constructors and Destructors. This code has become a source of ideas for CsLib. Dr. Kyle Hedges wrote our second C++ application, SRView, a medical image viewer. The goals were to: write an extremely fast image class (SRImage) and to develop a medical image viewer with the possibility of adding analysis extensions. While it met these goals, the program is a hybrid of Tcl/Tk and C++. SRImage, SRDataBuf, and other mathematical classes were renamed to Cs__, modified to be a derived class of CsData, and added to CsLib.

Goals

The goals of CsLib are:

• Permit writing extremely simple, "macro-like", programs, although these programs are compiled and possibly run in an integrated development environment. The simplest program is a five line program that instantiates a class variable, opens a file, displays, and services events.
• Initialization is automatic.
• All objects that are derived from base class CsData and implement certain virtual methods can receive CsLib services that include opening windows, drawing support, window refresh, support for handling events, opening and saving files, changing the mouse cursor appearance, and other common services.
• Use of external resource files is minimized.
• Support for global localization is supported by word and phrase translators for roman scripts. Other scripts (outside of those that can be represented by ASCII) are not supported.
• GUI elements such as windows, window behavior, and location of objects are automatically created if not explicitly defined. For example, calling an object's doDisplay() method opens a window and places the object in it.
• Design does not preclude the addition of an eventual GUI editor which runs while the program is running and permits resizing and placement of objects.
• Display may be customized later by deriving a new class or by installing a display callback routine.
• Events are handled automatically and directed to the affected window object, or menu.
• Displayed objects may receive events through their doEvent() method. Event processing may be customized by a call back routine.
• Opening and saving of files, including open/save dialog windows, is handled as much as possible by CsLib. The actual reading and writing is done by the derived class.
• A flattened object file format is defined as the default format. This flattened object format supports remote access to objects, is forward and backward compatible with respect to program and file versions, supports high speed data acquisition (minimal disk seek), and is resilient to computer crashes (flags in the file header and searchable bit patterns in file nodes maintain file integrity).
• High level programming is, and most CsLib classes are, OS independent. A side effect of this is that User Interface standards defined by the OS manufacturer is not always followed. However, the program is still of good quality. For example, basic GUI controls are provided by CsLib and may not call the OS-native control methods. CsLib permits a tighter OS binding in it's OS dependent files. The trade-off is increased long term code maintenance costs.
• OS dependence in low level code is minimized. For example, GUI elements require the reading of OS events and the drawing of lines and pixels. It does not require the use of OS dependent controls Where possible, an OS functionality is called only once..

Acknowledgements

Acknowlegements for the CsLib foundation class project.

Internal project.
Designed and written in C++ by Jim Nash including MacOSX binding.
CsImage and other math classes based on SRView by Dr. Kyle Hedges.
Various C++ ideas from Score, by Dawn Gregory.
Various structural ideas from Image/J, by Wayne Rasband.
Timing and Serial I/O from Feeder, by Dr. Lawrence A. Woltz