Supercard

[Richard Gaskin]

Jeff Graham wrote:

> I was hoping for a 90% automatic conversion, 10% hand-tweaking, that
> kind of thing.  When you say people do conversions, do you mean as a
> chargeable service?

[Note:  Apologies in advance for what turned out to be another long post,
but this is an important topic so I pulled some notes from an artice I'm
working on to include them here.]


Similarities and Differences Among xTalk Dialects
-------------------------------------------------
When porting between xTalk tools, the differences that make each tool
uniquely valuable in the market can also make interoperability challenging.
After all, if all xTalk products were exactly like HyperCard, why not just
use HyperCard?  

In addition to different features, differences between operating systems
introduce an even larger range of porting issues.

xTalks I've ported between include HyperCard, SuperCard, Oracle Media
Objects, ToolBook, Gain Momentum, MetaCard, and Revolution.  In each case
much of the syntax and most of the objects were directly portable with
little or no modification.  Some ports were simpler than others, but none
were completely simple. :)

If you've ported HC stacks to SuperCard you know what I mean.  Just when you
fall in love with vector graphics you realize you don't have a
report-printing engine. When moving from SC to Rev/MC the scope of issues is
similar.

In addition to differences between the respective xTalk dialects and the
object models they support is the issue of relying solely on automated
methods of porting.  When a porting tool encounters a set of objects not
supported in the new environment or supported differently, it has to make a
"best guess" about what the most appropriate solution should be.  Most of
the time the decisions encoded in a porting tool apply well; other times a
different approach would be better.


Example: Menus
--------------
HyperCard implements menus in scripts only, while in SuperCard menus and
menu items are each a discrete object.  Rev/MC sits somewhere in between:
menus are objects (buttons actually), with menu items as text within the
button.

The SC->Rev converter makes a safe choice with menus:  it puts all of the
itemselect handlers from each item in a menu into the script of the button
that is now the new menu, adding text to that button to display the menu
item names.  So far so good.  Now then, where to put those menu buttons...

As a Mac-only tool, SuperCard menus exist only in the menu bar.  But in
Windows and UNIX menus are attached to the top of a window.  Rev supports
the detached menu bar on Mac OS by shortening the stack by the height of the
group object containing your menu buttons, with the contents of those
buttons being displayed in the menu bar as you would expect (it actually
goes further to display the last item of your Help menu as the first item in
the Apple menu and other OS-specific niceties).  This approach lets you
build one set of menus that automatically take on the appropriate behavior
for each platform.

But the detached menubar of Mac OS raises a question:  now that we're
cross-platform, to which window do we attach the menus?

Here's where an automated tool can't help you:  some applications are best
served by attaching relevant menus to specific windows, others by mimicking
an MDI ("Multiple Document Interface", one of the four standard Windows
windowing models) by detaching the menu bar into a separate stack.

The SC->Rev converter does its best to rebuild the objects in a way that
makes sense in the new multi-platform environment: it puts them in a
separate stack and leaves it for you to determine which menus go where.  As
an automated tool that's pretty much as far as it can go on that one.


Other Differences
-----------------
Beyond menus, other differences between SC and Rev can affect conversion
productivity:

- SC supports QT through script functions while Rev has native QT player
objects.

- SC uses graphic objects for shared text while Rev uses fields with a
sharedText property (the implications there warrant a thread in itself).

- SC windows can have scrollbars while Rev uses scrolling groups (a slightly
shorter thread).

- SC always saves when you move card-to-card while Rev controls saving in
scripts.

- Mac-specific things like AppleScript, PICT-format images, creator and file
type associations, high-ASCII character codes, etc. must be revised for
cross-platform compatibility.


Why Contractors?
----------------
Given the scope of differences between tools and operating systems, for
complex applications a lot of business and universities find it
cost-effective to partner with an experienced developer.  Sometimes it's a
one-time conversion job, other times the client may be looking at OS X and
XP and want to expand the work to include an "interfacelift" to bring their
project up to date with current conventions.

For small businesses and individuals, sometimes having a contractor on tap
can provide as-needed training and lend a hand with parts of the project
from time to time.


For the Self-Starter
--------------------
For an experienced scripter willing to dive in, the water's fine once you
adjust to it. :)   You have this list, a large and growing number of example
files on the Web, docs by one of xTalk's most published authors (Jeanne
wrote "HyperTalk 2.2: The Book" and more), and a very responsive Rev team.

Having gone through this transition myself (I sold SuperCard components
exclusively for many years) and having watched others do it, I've found that
learning Rev as a second language tends to follow this pattern:

  Two days: "Omigawd, the potential is incredible!
  If only I knew how to use it all..."

  Two weeks: "After reading the language guide and trying
  some things out, I'm able to do truly productive work."

  One month: "Now I can do productive work efficiently."

  Three months: "With the flexibility of the language and the handy
  tools in Revolution, I'm seeing slightly greater productivity
  than in my formerly-favorite tool I'd used for years."

  Six months : "I love this thing."

  One year: "I love this thing like no other."


A Learning Caveat
-----------------
When moving from one tool to another there is a temptation to assume the
best way to learn is to start with something you know, to jump in with
porting an existing project from another tool.  While this approach has its
merits, it underestimates the role of "unlearning".

Unlearning is what happens when you encounter new ways of doing things in
systems that have apparent, but limited, similarity.  Without unlearning,
expectations of a greater level of similarity than may be present can cause
frustration.  I've seen this many times moving from tool to tool and OS to
OS.

At a minimum, doing the Rev tutorials will introduce you to the basics
unique to Rev, and help you anticipate potential challenges likely to be
encountered during conversion.

Taking a few hours to toy around in the Rev development environment before
doing a conversion can pay off handsomely.  You'll have the basics down and
can dive right into your conversion with confidence.


More Info
---------
Article: Revolution for SuperCard Developers
<http://www.RunRev.com/revolution/developers/articles/movingtools/supercard.
html>

There are links in the upper-right of this page to the Human Interface
Guidelines for most of Rev's supported platforms (and to other usability and
interface design resources):
<http://www.fourthworld.com/resources/index.html>

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Custom Software and Web Development for All Major Platforms
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc