cca@pur-phy (Charles C. Allen) (04/30/89)
After seeing some favorable reviews of Smalltalk/V Mac on the net and in
several magazines, I think it's time someone play devil's advocate and
present a few criticisms.
The integration into the Mac environment is half-hearted. The parts of
the Toolbox that ST/V uses are there to use, but many other parts are
available only by directly calling traps. This means that things like
radio buttons, checkboxes, icons, polygons, the Sound Manager, and other
missing parts, must be integrated into the class hierarchy by the
programmer. Sigh. I want to write applications, not redo the Toolbox.
Along the same lines, Digitalk decided to make it possible to have ST/V
Mac applications be portable to their IBM implmentations. As a result,
there are two different interfaces squished together. There are MacFont
and Font classes. There are Popup and MacPopup menus. There are good
reasons for wanting either interface, but please, NOT both at the same
time. Personally, I want to write Mac applications, and I was hoping to
find ST/V Mac more tightly integrated to the Mac. I'd settle for
another user interface if it provided the richness the Mac interface
does.
The manual calmly states that "Text editing in Smalltalk/V conforms to
text editing conventions of the Macintosh." Don't believe it. The
insertion point does not blink. Clicking after the end of a line or
below all the current text sticks the insertion point right there rather
than "gluing" it to the end of line or text. The arrow keys scroll the
text pane rather than moving the insertion point. There is no option to
have text wrap. Although it is possible to change the text font in
windows, bugs in the classes dealing with text make it almost mandatory
to use a fixed width font.
The first thing I wanted to do involved some text manipulation. Wrong
choice. CharacterScanner and related classes are rather buggy. Among
the problems:
* Pen>>centerText:font: should use 'font stringWidth: string'
rather than 'string size * font width'. This misuse of 'font
width' is scattered throughout the source.
* Evaluating the following in a workspace produces some ugly (and
incorrect) results:
| aString |
aString := 'Testing CharacterScanner 1 2 3 ...'.
Display lightGray.
CharacterScanner new
initialize: Display boundingBox font: Font menuFont;
mask: Form gray;
combinationRule: Form over; display: aString at: 8 @ 20;
combinationRule: Form orRule; display: aString at: 8 @ 40;
combinationRule: Form andRule; display: aString at: 8 @ 60;
combinationRule: Form under; display: aString at: 8 @ 80;
combinationRule: Form erase; display: aString at: 8 @ 100;
combinationRule: Form reverse; display: aString at: 8 @ 120;
combinationRule: Form orThru; display: aString at: 8 @ 140;
I'm not sure who the ultimate culprit is (I haven't totally
fixed this yet), but the following methods all appear buggy:
* MacFont>>createFont:height: sets the fixedWidth flag if "...most
of the widths are the same." Why not use the Toolbox
proportional flag? Note that this algorithm does give correct
results for Chicago and Geneva, but see next paragraph.
* Font applicationFont fixedWidth and Font menuFont fixedWidth
both return true. Oops. Have to set the flags by hand.
* Font>>sourceXPositionOf: assumes a fixed width font. The xTable
is not used.
* CharacterScanner>>copyCharsNonPrim doesn't work properly, fixed
width or not.
I think that's enough criticism for one posting :-). I do generally
like ST/V Mac, but the reviews I saw just seemed too gushing with
praise. Now if only either Apple or Digitalk would get the MacApp
model going in ST/V Mac, I might post a favorable review myself....
Charles Allen cca@newton.physics.purdue.edu
cca@fnal.bitnet