Eric Engle wrote:
First, I must say: I don't just want a solution for me. I want a solution for
anyone using revolution or metacard.
It would only matter to the subset of Rev and MC developers who still
have HyperCard stacks to port.
And really it's the smaller subset who will deal with other conversion
issues (AddColor, etc. as outlined in Jacque Gays' article at
<http://hyperactivesw.com/mctutorial/index.html>) but still expect
complete automation for this one issue with doMenu.
If you want to write an AddColor library that'll do more for conversion
than the proposed engine change.
Richard gives me the impression that there is in fact no way out.
On the contrary I gave you a solution, albeit one that asks the
developer to think in terms of the tool they're currently using rather
than the one they're leaving behind:
...you could write a menuPick handler at the stack level
and move your doMenu stuff there. That way you could
handle visible menu items there and also makes calls to
it from other scripts by writing:
menuPick "Menu Item Name"
...rather than HC's:
doMenu "Menu Item Name"
Remember that menus are implemented differently in Rev than in HC,
arguably somewhere in the middle between HC's text-only implementation
and SuperCard's object-only variant.
Even if we slowed down the engine to accomodate those who feel the need
to type "doMenu" rather than handle the native "menuPick" in Rev, you'd
still need to figure out how to handle all of HyperCard's prefab menus
that don't exist in this engine if instant out-of-the-box complete
compatibility is the goal.
I think Alain's original approach of providing an alternative IDE and
supporting libraries aimed at giving the HyperCard experience to those
using the Rev engine is the better way to go.
Alain has mentioned the only thing that stands between where FreeGUI is
today and a fully completed version is a little volunteer help. Know
anyone who feels that providing that level of HyperCard compatibility is
important enough to lend a hand with?
Also, Scott very much still owns metacard. He has licensed its engine to
revolution in exchange for a GUI, nothing more or less.
Actually, Scott has sold the engine to RunRev in July 2003, as described
in the acquisition press release:
<http://www.runrev.com/section/press/10.php>
RunRev Ltd. is a completely separate business from MetaCard Corp.
MC Corp still retains the copyright on its own IDE, though it has
licensed its use by others under the X11 open source license.
Neither Scott Raney nor MetaCard Corp. have ownership of the Rev IDE.
Like the engine, that's fully ownwed by RunRev Ltd of Edinburgh, Scotland.
Anyway, my point remains: this is an unimplemented feature. In the interest of
compatability it should be implemented. It need not be implemented in a manner
that either interferes with speed of other functions. However it must be
implemented such that revolution/metacard can properly import hypercard stacks.
Which means while it could be scripted using open source it would have to be
implemented by MC/RR.
No two tools are completely the same as each other. After all these
years and nearly a dozen xTalk dialects later, it seems that for a tool
to justify it's existence it will differ from HyperCard; indeed, if it
did not why would they bother?
But with those differences come conflicting paradigms, such as AddColor
vs. built-in color, or script-only menus vs Rev's object menus.
These differences invariably require changes to a stack to run.
While Rev has that in common with all other xTalk tools, to its credit
it's the only one which reads the HyperCard file format natively and
supports more of HC's syntax than anything tool but HC itself.
Once upon a time metacard had no native bitmap art tools just vector tools and
there was no art compatability. Now there is and most art stacks run fine under
metacard. Currently many domenu items are not implemented. They could be.
There's a big difference, however: bitmap tools weren't added for the
Mac platform for HyperCard compatibility. In fact, the person who
lobbied hardest for them was porting something from VB.
Paint tools were added because they benefit all developers, not just the
subset looking for HyperCard compatibility.
Mostly though my domenu commands return "no such menu". Which to me means that
they could be implemented just by adding invisible menu items to the metacard
menu bar. Richard is implying that that is not possible.
What happened when you tried it?
In my experience anything in the menu group will appear in the Mac OS
menubar.
But there's no need to be adding additional objects, invisible or
otherwise, if you'll simply handle the scripts as suggested above.
Menus aren't objects in HC, so the behaviors are defined in scripts
anyway. Just handle those at the stack level and you're done and can
move on to bigger and better things, like writing an AddColor library. :)
If I implement a change on my version of metacard that does
nothing for the other people using metacard. I don't want a
solution just for myself.
Contributing to Alain's FreeGUI would seem a useful path to consider.
one of the reasons MC is so darn fast is that it doesn't allow the
overriding of built-in commands and functions (it cuts the token search
space down dramatically). Fortunately, for the few cases where that
might be useful it isn't hard to work around it:
That argument ignores the processor speed of machines is increasing and will
continue to increase such that any speed gain is really not that important and
will become less and less important.
And that argument ignores what other people are doing with the engine.
Very few of us have any HC stacks to port any more, and haven't for
years. But most of us are working on some complex code now and then
that could benefit from every efficiency we can get.
The bottom line is simply that I doubt very much that at this late stage
in the game Rev would consider slowing down the engine for a relatively
minor convenience that would be needed by only a relative handful of users.
So the more productive path for those who want to use Rev to behave like
HyperCard would be to accept that a number of areas will require script
changes (changing "doMenu" to "menuPick" is one of the simpler ones) and
for everything else help the development of Alain's FreeGUI.
--
Richard Gaskin
Fourth World Media Corporation
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________
metacard mailing list
metacard@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard
