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
_______________________________________________
metacard mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/metacard
