hypercard domenu comptability

[Richard Gaskin]

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
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com