Similarities Among xTalks
When porting between tools, the differences that make each tool uniquely valuable in the market also make interoperability difficult. If all xTalks were exactly like HyperCard, why not just use HyperCard?
Differences Between xTalks
xTalks I've ported between include HyperCard, SuperCard, Oracle Media Objects, ToolBook, Gain Momentum, MetaCard, and Revolution. Some were simpler than others, but none were truly 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 would be. Most of the time the decisions encoded in a porting tool apply well; other times not.
Menus are a good example. HyperCard implements them 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 conveter makes a safe choice with menus: it put all of of the itemselect handlers from each item in a manu 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, whewre 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 such niceties). This approach lets you build one set of menus that automatically take on the appropriate behavior on 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 approach by detaching the menu bar into a separate stack.
The SC->Rev converted does its best to rebuild the objects in a way that makes sense in the new multi-platform environment: it puts then 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.
And that's just menus. ;)
SC supports QT through script functions while MC has native QT player objects; SC uses graphic objects for shared text while MC uses fields with a sharedText property (that's a thread in itself); SC windows can have scrollbars while MC uses scrolling groups (a slightly shorter thread); SC always saves when you move card-to-card while MC controls saving in scripts; etc.
Given these differences, for complex applications a lot of business, universities, and other organizations 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 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.
But 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 watched others do it, learning Rev/MC as a second language tends to follow this pattern:
Two days: Omigawd, the potential is incredible!
Two weeks: After reading the language guide and trying
One month: Now I can do productive work efficiently.
Three months: With the flexibility of the language and the handy
Six months : I love this thing.One year: I love this thing like no other.
FWIW: 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):