[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Application Framework
- To: scosysv!keunen@nrb.be
- Subject: Re: Application Framework
- From: bill@cambridge.apple.com (Bill St. Clair)
- Date: Wed, 17 Jun 1992 11:14:25 -0500
- Cc: info-mcl
>Date: Wed, 17 Jun 1992 10:24+0200
>From: Vincent Keunen <scosysv!keunen@nrbmi2.ia.nrb.be>
>Reply-To: scosysv!keunen@nrb.be
>Subject: Re: Application Framework
>To: Bill St. Clair <bill@cambridge.apple.com>
>
> Date: Tue, 16 Jun 1992 01:16+0200
> From: bill@cambridge.apple.com (Bill St. Clair)
>
> I have packaged both the MORE & TEXT versions of Howard's upload in
> a binhexed Compact Pro archive and uploaded it to the anonymous
> FTP server at cambridge.apple.com in the file:
>
> /pub/application-framework/AppFrame.cpt.hqx
>
>Is the TEXT version too long to post to the mcl list?
>
>Vincent
No. Here 'tis.
-----------------------------------------------------------------------
MCL Application Framework
1. Philosophy
1.1. MCL already has a considerable amount of built-in class
functionality. Whilst we all recognise that this is not as good as we
would like (or need), it is something upon which we should build wisely
rather than ignore.
1.2. MCL and MacApp (and TCL) are different beasts. Whilst it is
superficially very tempting to just try and 'port MacApp' into MCL, in
practice what is needed is functional equivalence within the existing MCL
environment, not a straight translation into Common Lisp.
1.3. The logical approach to constructing this application framework is
to study the features of the MacApp and other class libraries, and to
identify areas in which MCL can be enhanced and enriched to the benefit of
those using it. To these should be added other areas which are either of
particular importance to the MCL environment, or which are useful features
which are also absent from these other class libraries.
1.4. Where MCL already has facilities and/or classes, then great care
should be taken to integrate these new features into the existing ones,
rather than just grafting the additional classes on willy-nilly. The
structure of the whole framework should present a coherent and structured
extension of the built-in classes.
1.5. Provided that implementations of Dylan offer similar
machine-specific features, wherever possible this work should proceed in
parallel in Dylan as well (provided that Apple Computer, Inc., agree to
this). This may require parallel development of different classes (e.g.
failure handlers).
1.6. The completed class library and application skeleton, together with
all ancillaries and documentation, shall be made available at low cost
through the OODL SIG, for incorporation into third party projects and
applications at no further cost (i.e. there shall be no runtime licensing).
2. Aims
2.1. To extend the built-in classes in Macintosh Common Lisp 2.0 so as
to make applications development quicker and easier.
2.2. To encourage further extensibility and customisation with the
addition of minimal new code.
2.3. To encourage good programming techniques and a consistent Macintosh
human interface.
2.4. To do these things with the aid of customisable interface design
tools.
2.5. To encourage consistency in CLOS naming conventions.
3. Naming Conventions
3.1. Globals, bracketed by *, e.g. *my-global*
3.1.1. This matches the Dylan definition of "module variables that are
designed to have their values change in the course of a program (i.e.
variables that are not read-only)" (Dylan, p 25).
3.1.2. Examples are:
3.1.2.1. *font-list*
3.1.2.2. *window-count*
3.2. Constants, prefixed by $
3.2.1. This matches the Dylan convention for "program constants
(read-only module variables)" (Dylan, p 25).
3.2.2. Examples are:
3.2.2.1. $max-dimension
3.2.2.2. $pi
3.3. Classes, no general requirements
3.3.1. Superclasses intended to be subclassed only, suffixed -abs
3.3.1.1. These correspond to Dylan's abstract classes
3.3.1.2. Examples are:
3.3.1.2.1. control-abs
3.3.1.2.2. primitive-rect-abs
3.3.2. Classes intended not to be modified, suffixed -sl
3.3.2.1. These correspond to Dylan's sealed classes
3.3.2.2. Examples are:
3.3.2.2.1. chain-code-vector-sl
3.3.2.2.2. prime-integer-sl
3.3.3. Mixin classes, to contain appropriate elements of their
superclasses so as to convey their nature
3.3.3.1. Examples are:
3.3.3.1.1. icon-control
3.3.3.1.2. colour-icon-control
3.4. Slots, no requirements
3.5. Readers, writers and accessors, default to the same name as their
slot
3.5.1. These correspond to Dylan setters and getters, and match Dylan's
convention (Dylan, p 26)
3.6. Predicate functions, suffixed by p or -p
3.6.1. This follows Common Lisp practice, although Dylan standardizes
on the suffix of ? (Dylan, p 25)
3.6.1.1. Question: can we or should we follow Dylan?
3.6.2. Examples are:
3.6.2.1. square-p
3.6.2.2. can-be-saved-p
3.7. Operations which modify destructively, prefixed by n
3.7.1. The corresponding convention in Dylan is a suffix of !
3.7.1.1. Question: can we or should we follow Dylan?
3.7.2. Examples are:
3.7.2.1. nchaos-sort
3.7.2.2. nmandelize-image
4. Class Structure
4.1. Note that these are initial rough guesses for further elaboration
and discussion - please feel free to expand on and add to these.
4.2. Application level features
4.2.1. All application-level features should be placed as globals, to
ensure that they remain accessible at all times. Besides, there is no
'application' class in MCL, nor should we attempt to define one.
4.2.2. Global lists should include:
4.2.2.1. windows
4.2.2.2. documents
4.2.2.3. commands (historic) (to allow multiple levels of undo and
redo)
4.3. Documents
4.3.1. Not necessarily file/stream based, although there should be
subclasses supporting file/stream documents.
4.4. Additional support for printing of views/windows
4.4.1. to extend the current hardcopy facility using PrintHandler
classes
4.5. PrintHandler and Printing classes
4.6. Additional control classes, although the intention is not to
provide every possible specialised control, rather to provide a broad range
for further sub-classing.
4.6.1. including:
4.6.1.1. Icon
4.6.1.2. Pattern
4.6.1.3. Picture
4.6.1.4. Popup
4.6.1.5. NumberText (and other specialised text classes)
4.7. Coordinate mapping to permit view coordinates which are LONG
integers
4.8. Improved error reporting
5. Interface Design
5.1. There are two tools which will be adapted for the design of MCL
application interfaces: AppMaker (by Bowers Development), and the MCL
Interface Editor (supplied with MCL).
5.1.1. AppMaker is a professional and polished tool used by developers
for a wide range of other environments, including the THINK Class Library
(TCL) and MacApp. Its current version (1.5.1) does not easiy support the
addition of novel control types, but this is apparently intended for future
versions. It is being modified to generate a mixture of MCL code and
resources.
5.1.1.1. There is considerable dispute as to whether MCL should
support dialog views accessed from resources (as TCL and MacApp do) or from
MCL code (as produced by the MCL Interface Editor). It is clear that there
are good reasons to do both, and accordingly AppMaker will be supported
both from two-stage generation of all-procedural controls (the first stage
will be direct code generation from AppMaker via templates, the second will
be decompilation of resources into MCL code) and from code to allow the use
of resource-based controls and views. Although in time it may be possible
to support both MacApp and TCL view resource types, in the first instance
only MacApp types will be supported (unless there is strong representation
for TCL views!).
5.1.2. The MCL Interface Editor only generates MCL code, and no
resource-based views or controls. However, it has the great advantage of
being written in MCL and completely customizable and extensible, and can
thus accommodate entirely novel types.
6. Presentation and Documentation
6.1. The completed application skeleton will be supplied as a skeleton
and a library of packages to implement the agreed classes.
6.2. AppMaker templates, a resource decompiler, and a new MCL Interface
Editor will also be supplied.
6.3. Documentation will consist of a hierarchical description of the
class library, a cookbook, and a ready reference, together with the
instructions for installation and use of the interface tools. These will
be provided in electronic format only (and not as Word documents?).
6.4. The documentation will not attempt to be exhaustive, as the class
library will be supplied as source.
7. Plan
7.1. Agree the project proposal based in this document
7.2. Establish areas of responsibility within the group undertaking the
work
7.3. Agree timetable; current intended completion date is end 1992.
7.4. Agree interim test release target dates
7.5. Go to it!
7.6. Dylan version to be run in parallel when Dylan implementation(s)
available, and with agreement of Apple Computer, Inc.
8. Comments and offers of help
8.1. All comments and offers to become involved in this project should
be addressed (by mail) to Howard Oakley at:
8.1.1. AppleLink UK0392
8.1.2. Internet UK0392@applelink.apple.com
8.1.3. CompuServe 70734,120
8.1.4. CIX hoakley
8.1.5. Fax UK (+44) 983 853253
8.2. It is intended to produce a revised version of this document by
early July.
8.3. This document (and subsequent versions) will be posted as follows:
8.3.1. On AppleLink, in the MCL Discussion folder (somewhere in the
depths of the DSBB)
8.3.2. On CIX, in the mcl topic in the macdev conference
8.4. Please post other unaltered versions freely. I hope that they will
be posted on accessible Internet locations, such as the Cambridge archive,
please.
8.5. This document is Copyright 1992 OODL SIG and EHN & DIJ Oakley,
all rights reserved, but permission to distribute as specified above is
given.
8.6. This is version 1, revision 1, dated 14 June 1992.