Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!newsfeed.rice.edu!bcm.tmc.edu!news.msfc.nasa.gov!elroy.jpl.nasa.gov!swrinde!gatech!news.mathworks.com!news.kei.com!nntp.coast.net!torn!nott!cunews!tina.mrco.carleton.ca!knight
From: knight@acm.org (Alan Knight)
Subject: Re: Why is VisualWorks SO complicated?
X-Nntp-Posting-Host: tina.mrco.carleton.ca
Message-ID: <knight.821159356@tina.mrco.carleton.ca>
Sender: news@cunews.carleton.ca (News Administrator)
Reply-To: knight@mrco.carleton.ca (Alan Knight)
Organization: The Object People
References: <DKM6EJ.L59@cunews.carleton.ca> <4cfl1p$d36@newsbf02.news.aol.com>
Date: Tue, 9 Jan 1996 03:49:16 GMT
Lines: 83

In <4cfl1p$d36@newsbf02.news.aol.com> bytesmiths@aol.com (Bytesmiths) writes:

You make some good points, and I certainly acknowledged in my original
post that there were advantages to doing everything yourself at the
Smalltalk level. On the other hand, I don't believe that those
advantages are worth the associated costs. VisualWorks applications
require more memory, are less faithful to the platform look and feel,
and run more slowly as a result of emulation. I also believe you
overstate some of the benefits, though it is certainly true that
others have overstated the benefits of native widgets.

>* I have integrated, incremental spelling correction that works anywhere
>there is a ParagraphEditor or subclass.
>* I've made "read only" modes for ParagraphEditors that allow incremental
>searching if they are typed at.
>* I have hypertext available in any ParagraphEditor, using Text
>attributes.
>* I have a family of common text editing menus, that support the matrix of
>read-only and read-write against development-only and deployed -- four
>menus keyed by two booleans.

>In particular, the VW Text model is really much nicer and more versatile
>than any platform text editing widget I've seen.

Really? There are significant aspects of it that I really don't like.
The most important of these is font support. You've just gotta love a
system that's supposed to be ideal for building GUI's and offers you a
choice of 4 fonts at the UI level. Of course, if you want more you
only have mess with 3 or 4 complicated classes. Some of the stuff
that's in the underlying font model is pretty horrific. I consider
fonts one of the worst things in VW (along with colors, and polling
controllers).

>Okay, consider a drawing surface. I implemented a line graphing framework
>in a weekend in VW. "No sweat, just map it through a bunch of layers (Cg,
>CW, et. al.) and it will use the platform drawing API!" Well, will it
>render into PostScript like all other VW graphics? Not bloody likely!
>You'll have to figure out someone's arcane and clumsy printer driver
>architecture!

I consider VW's printer architecture much worse than most. They don't
have one. On anything except UNIX, if I can draw something to the
screen, I can print it, I can store it in a bitmap, or I can create a
PICT/Metafile/whatever. What do I do on VisualWorks if I have a
LaserJet? IBM suffers from the same problem, having modeled their
graphics after Motif, but I believe they've fixed that omission now.

... <native file picker may>...
>be great, but what if you want to put a custom menu in it, or re-arrange
>the elements, possibly adding some new ones? Better get used to writing
>primitives...

If you really must mess with the file dialog, you can always build
your own out of native widgets. For most circumstances, using the
standard dialog is preferable.


In another message you also made some comments about stuff that the
van Gogh alpha did not support. Two comments to that

 - I believe the van Gogh alpha was distributed about the time of the
PPD users conference, i.e. before the merger was even finalized. As
such it represents the state of what ParcPlace had done before
incorporating any of Digitalk's work. Digitalk has much more
experience with native widgets, and I expect their influence to be
significant.

 - From what you described, I would simply characterize the van Gogh
alpha as a poor implementation of native widgets. Other people have
done native widgets that integrate quite nicely with Smalltalk, and
which I do not believe suffer from most of the limitations you
describe.

There are disadvantages to using native widgets, but under the current
circumstances I believe they are far outweighed by the advantages.


-- 
 Alan Knight                | The Object People
 knight@acm.org             | Smalltalk and OO Training and Consulting
 alan@objectpeople.on.ca    | 509-885 Meadowlands Dr.
 +1 613 225 8812            | Ottawa, Canada, K2C 3N2

