Hypercard and Gorm ?

Hypercard ? Never used it, but always heard good things about it.. (starting from Dave Small's articles ;-)
So in another round of web procrastination, I tried to find more infos about it. Turns out it was quite interesting, and modern incarnations such as Revolution are quite cool too.

So what's cool with Hypercard ?

• You could say that it was one of the first easy to use "gui builder" -- you just drag'n drop elements on your screen, click on them to open a script function that will be triggered (for example when the user click on the element), etc. And it's not limited to widgets, you can draw, add images, sound... More than a gui builder, Hypercard was the first multimedia authoring system..


• You program it using Hypertalk, a "natural" programming language (ie, close to english, rather lax). Interesting.


• The real interesting bit: everything revolves around the concept of Stacks of Cards. Basically, you start with a stack containing one card. You can have more than one card in a stack (duh), and only one card is displayed at a time. So, a card is a "screen" if you want. And then you have the possibility to navigate through the cards, going from one card to another, to add cards, etc. Which is basically a hypertext (or hypermedia in that case) system. Now, the other great thing is that cards are persistants : if you add something to a card, it will stay. If you quit hypercard, restart it, reload your stack, what you added on the card is still there. Combine that with the ability to specify some of the elements on a card as "background elements" (meaning they'll be there on any cards of the stack) and you have a really simple method to define databases. Which is why Hypercard was also considered as a database. Pfew, quite a lot of possibilites, no wonder Apple's management had a hard time figuring it out ;-)
  

An example of creating a database: Just create a new card, add some textfields... add buttons to navigate (prev card, next card) and a button to add / remove a card. Set the textfields as background elements. And voila ! you're done ! Now you can run your stack, fill in the card, and when you need to add a new card, just click on the button. Great no ? In addition Hypercard could easily search through a stack, so it wasn't difficult to add search possibilities too.. And if you need to add a new information ? just add a new textfield :-)

So to sum up, quite a neat system. As I never used it, I perhaps misunderstood some of the possibilites, but playing a bit with Revolution, I'm not too far from what I describe..

I now understand more why lots of people liked it -- it was really a great system for "non programmers" to actually do great things with their computer. It's a shame Apple didn't push it more...

Anyway... I needed to explain all that to introduce my idea : Gorm is the InterfaceBuilder-like program for the GNUstep framework. You could say it's just another "gui builder" ... and you would be rather wrong ! Because instead of limiting itself to describe UI elements layout.. it really only deals with objects. Live objects. Which means you can even try your user interface, link buttons to actions, etc., all without compiling. And it's any objects -- not just graphical objects.

When you set options of the elements on your UI, you really work on the objects themselves. Then the UI is saved -- in fact, the objects graph is simply serialized in a file. When your GNUstep (or Cocoa) program starts, it just load this serialized graph of objects back in memory. That's the great thing with InterfaceBuilder and Gorm : you can set up a lot of things directly, without writing a line of code. The other good thing is you can define your own palettes of objects :-) so at the end, you can build complex program simply by drag'n drop... well, that's the idea anyway. Recent Apple's additions to the Cocoa API goes toward that (NSController, CoreData...).

So what's my idea then ? Well, it occured to me that you could simply have two objects -- a "Card" object and a "Stack" object, and put them on a Gorm (or IB) palette. The "Card" object will accept other objects (textfields, images...) and will also be in charge of saving their state. So there you'd have a persistant Card. The "Stack" object will maintain a collection of Cards, and will answer to messages like "go to card #2", "go to next card", or "create a new card".

Thoses two objects will provide you with Hypercard-like functionalities -- just start Gorm, select the "hypercard" palette, drag'n drop a Stack view on your window, and then add what you want on it. Want another card, open the Stack inspector and add one. Add new objects on it. Add some buttons on your window, and link the buttons' actions to some methods of the Stack or of the current card. And of course, instead of widgets, you could drop images or sound ... why not ?

Now, imagine we'd have a Steptalk palette to create scripts objects... and voila, you have an hypertalk-like system :-) -- all that inside Gorm (or InterfaceBuilder), leveraging the Gorm's UI builder possibilities. Imagine now we add a few nice graphical transitions or other niceties... and you end up with a rather good multimedia authoring system that generates binaries :-)
-- and if you want to add your own objects to it, to extend it.. well, it's still Gorm and GNUstep, so you can easily do that, obviously :-)

Ok, that was a long post... :-)

So in short, the idea sounds quite cool to me, and I actually started to implement a palette with thoses two objects on InterfaceBuilder (MacOSX). Sadly, palette creation isn't that well documented and I ran into a couple of strange problems .. so ... I'll do that with Gorm first, it'll be easier. Didn't start with Gorm for a very simple reason -- since Tiger, my GNUstep/OSX installation is b0rked. In the end, I'm installing a linux distrib (ubuntu PPC) ... Should be easier to have a working GNUstep environment ! :D