Cincom VisualWorks Smalltalk: doing something useful part 2

The Omega Man

Straight up, I spent an embarrassing amount of time on this and I'm not going to go into all the details. Suffice to say, VisualWorks ancient UI painter has been a major problem for the last 30 years and it still sucks. It demos quite well and the instructional video is very informative, but like a lot of 1990s era GUI builder tools, the demos were always fantastic and the lived reality is a major pain. Here is the instructional video and I had to watch it to get anything done at all.

We were warned about The End. Well, here it is

The stock VisualWorks image doesn't have the good old UI painter in it, you have to add it via the Package manager. Once it's there, fire it up on a blank canvas and drop a couple of controls on there. I want a tree view and a space to dump some text (because I'm not going to fancy format anything just yet).

Once you've painted up your interface, you need to stop and create somewhere to put your classes (watch the video), I made a new "Package" called Smackeyacky, told the interface painter to save my class and it created a class method called "windowSpec" which contains a pile of very un-Smalltalk looking stuff. Basically it's a pile of arrays full of Symbols. Symbols are special strings that aren't and they are kind of like when you declare a literal String in Java, but not really. You're not meant to understand the pile of rubbish in windowSpec I don't think. Next step is to make sure all your "aspects" are filled out which are the methods on your interface object that the widgets on the screen will call to get values to populate themselves. There is an entire rabbit hole on Smalltalk ValueHolders, AspectAdaptors, SelectionInList etc. that would take too long to explain as well. Most of it is completely opaque, difficult to understand and navigate for a newbie and feels arcane and old fashioned compared to something like Razor pages.

Here is the instrument of cleansing, my brethren. And nothing quite cleanses like fire

Back to something resembling normal, I fill out some classes for navigating AWS. I create a superclass called "AWSCliInterface" that does all the command line stuff, then create a few children for specific purposes. In this case, I have one called "AWS" which should return the services available to browse, one called AWSDynamoDB and another AWSDynamoDBTable. The general idea is that asking AWS for it's children will hand back an AWSDynamoDB, asking that for it's children will hand back a set of AWSDynamoDBTables and asking those for their contents will scan the table.

So it works. The UI Painter created a couple of "aspects" for the two widgets on the screen. All you do is give it a name on the properties editor and hit the "Define" button and it makes aspects of the correct type for the widget. In this case, the tree view widget has an aspect of type "SelectionInList", and the document view widget creates a value holder on a Document. To populate the tree view, I intercept the "postOpenWith:" method by overriding it and do this:

In this case, the SelectionInList object "awsServices" gets pointed to my AWS object, that defines methods called "children" and tree view is magically populated. I used the UI painter to tell the tree view to send my object a message when the selection changes, which triggers some more stuff, which eventually populates the document view.

Is there anything you can do, DOCTOR, I mean, seeing as how you've lost over 200 million patients?

By far the major impediment to getting anything done in Smalltalk is it's lack of use. It's just about impossible to find any documentation on any of this stuff for a beginner. I wasted a pile of time reading through the class definitions, looking at the methods, trying fifty different things and when it did finally work acceptably, deciding it just wasn't worth pursuing. Pharo might be a lot easier since it still has an active community. It's incredibly difficult to be as productive in VisualWorks as in more common environments simply because of that. The other problem is that the product feels creaky and unloved. I hated that UI Painter back in 1995 and it is ostensibly identical now. Zero progress.

So my conclusion is: no, it's not possible to be as productive making your own tools in VisualWorks as it once was. We all moved on and rightly so. I can still see the logo of the bank I used to work for embedded in their marketing material although I'm 100% sure they no longer use VisualWorks. Next I will have a crack at Electron or Flutter.