Xref: utzoo comp.lang.smalltalk:1034 comp.sys.mac.programmer:5929 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!pur-ee!pur-phy!cca From: cca@pur-phy (Charles C. Allen) Newsgroups: comp.lang.smalltalk,comp.sys.mac.programmer Subject: Smalltalk/V Mac critique Message-ID: <2220@pur-phy> Date: 30 Apr 89 15:23:46 GMT Organization: Purdue Univ. Phys Dept, W.Lafayette, IN Lines: 80 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