Metacard 4

[Richard Gaskin]

Richmond Mathewson wrote:
> 1. You need to own some sort of RunRev Studio or Enterprise to be able to
>     pop the engine into the MC environment.

True.  The engine-based licensing Mr. Waddingham introduced in v2.7 has 
opened up whole new worlds for developers, allowing anyone to make any 
IDE environment they want with no risk to RunRev since any of them 
require a licensed installation of the core Rev product.


> 2. The Metacard standalone builder does not allow one to build the MC
>     equivalent of revlets: not even sure what they would be called:
> 
>     "MetaCrudlets" ?  "Metalets" ?   "Metlets"  ?

Not currently, but neither does the shipping version of Rev. Based on 
comments from Kevin on the improve-rev list we can expect this to be 
supportable in the MC IDE by the time Rev 4 ships.

As for terminology, it seems simpler to just call them Revlets.  MC is 
just a colection of tools; the engine is always the engine, the format 
always the format.


> 3. The difficulty of getting "under the hood" with the MC IDE is awful,
>     and is becoming increasingly awful.

I find very much the opposite. What would you like to do that you found 
difficult. I'm no fan of Raney's code style, but with about 1/10th as 
much code and no mirrored messages or custom props being added to ones 
work I find mucking around in MC much simpler.


> Having paid for RunRev (you cannot make MC from the Free revMedia as
> the RunRev engine is wrapped up with everything else) why not just us
> it?

I think it's largely a matter of taste.

For myself, I prefer to minimize the differences between development and 
runtime, and MC's lean workflow provides higher fidelity between the two 
than with Rev.

For example, just last week I was stuck trying to fix a bug that only 
occurs at runtime when building EXEs in Rev, since Rev alters your 
objects by adding a hidden group containing a number of buttons which 
will take up to seven of the ten available backscript slots, and at 
least one of the frontScript slots.  For many apps this may be fine, but 
I make extensive use of backscripts and need the slots the engine provides.

But moreover, if there's anything wrong with the Rev scripts you have no 
choice in the matter - it will always include at least some of them, and 
in my case it was trapping Apple event messages in ways I could only 
work around by moving my handler into a frontScript to get it before 
RunRev's code did.  In MC this is never a problem, since its standalones 
requires no frontScripts or backScripts, and the only two libraries 
which it may included leave you in control of how they're loaded.

Know the engine.
Trust the engine.
Use the engine.

:)


--
  Richard Gaskin
  Fourth World
  Revolution training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com