Supercard

[Ken Ray]

Well said, Richard!

Ken Ray
Sons of Thunder Software
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/

----- Original Message -----
From: "Richard Gaskin" <ambassador at fourthworld.com>
To: <use-revolution at lists.runrev.com>
Sent: Wednesday, October 02, 2002 4:59 PM
Subject: Re: Supercard


> 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
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>