The Aborted Plunge (Metacard to Revolution)

Tue May 29 10:55:36 CDT 2007

Shari wrote:

> Richard wrote:
>> The meta-question implied by all of this seems to be: Why switch?
>>
>> More specifically, what features in the Rev IDE make it interesting,
>> and  what could be done to the MC IDE to exceed it?
>
> The logic was two-fold.... the Metacard GUI is supported by
> volunteers. Anything supported by volunteers eventually gets
> very stressed.
...
> So.....what are the odds that my beloved GUI will be around
> for a very long time?

I hope my last post addressed that question.  I maintain the belief that
it's in the best interest of MC fans, Rev fans, and RunRev Ltd. to see
that the MC IDE continues to be maintained and expanded.

When a gene pool is too limited we get deformity.
Diversity is nature's guide to success.

> I remember the disappearance of Hypercard, and the demise of that
> program hurt me.

It hurt all of us, and none more so than Apple (yet I doubt they have 
anyone left with enough imagination to understand what it could have 
been; the world is bigger than Widgets).

With HC the whole product died.  The only thing that would prevent MC
from running would be the demise of RunRev, in which case it wouldn't
matter which IDE you'd been using.  But as long as Rev is kicking, MC
can continue dancing right alongside; they're both just a bunch of
stack, and they both use the same engine.

While it is a volunteer effort, the MC IDE is maintained by 
professionals who need to remain close to the engine.  As long as there 
are developers who appreciate the benefits of clearly discerning the 
difference between development and runtime and enjoy streamlining their 
work by reducing these differences to the barest possible, there will be 
a future for MC.

Long live the Revolution.

Let's see if we can make it revolutionary. Having addressed the "Why",
let's look at the "How":

> The second part of the logic was that yes, the Rev GUI has a few
> (and I do say few) things I seriously wish the MC GUI had.

Historically the MC IDE project had maintained a mandate for minimal
change to preserve the things we liked about it.  As a baseline I think
that mandate still has some value, but I have to admit that it's too 
sparse to let me get my work done efficiently by itself, which is why I 
invested the time making devolution.

Maintaining the minimal-change mandate makes sense in many respects, and 
  keeping it current lets use add the parts we want with plugins, which
means they can also interoperate with Rev and Galaxy as well.

This example is a good test case:

> One is the Search All Scripts function.  This is pretty major.  I
> cannot jump back and forth between the two GUI's to take advantage
> of one function or another, if my programs don't work in the Rev GUI.

Even if your stacks could be moved back and forth without error, why 
bother with the extra work?

Short-term:  devolution has a GUI script search tool, allowing searches
of all objects in a stack or the current message path.

Longer-term: Who wants to write a Transcript equivalent of HC's ss
command?  Any problems with asking Klaus to put that in MC's backScript?

> The ability to set parameters for a standalone and have it remember
> my settings, so that every update I didn't have to do it again,
> would be nice.

Remember, Rev has one-click builds because Ken and I have been using my
Standalone Ranger for so long we insisted on it. :)

Short-term:  My Standalone Ranger is a front-end to MC's Standalone
Builder, which lets you save the settings to a custom prop in the target
stack's first card (yes, I know it's  prop, but it's optional and you're
made aware of what it's doing; no behind-you-back property hijacking).
If you promise to provide feedback I can email it to you.

Long-term:  In my spare time I've been integrating MC's builder directly
  into my Standalone Ranger UI, with more options for an even easier 
build (taking advantage of RIP properties) and allowing it to be used in 
Rev as a plugin as well.  This will take a bit to finish, but it puts an
interesting twist on the build process which I think folks will find 
handy.  This more complete implementation will provide all of the 
conveniences of Rev's, and then some.

> In some ways it has better documentation as well, though in others
> it fails pretty seriously.

Agreed.  Ideally we'd get a volunteer to be the owner for the
mcDictionary project.  There's an earlier version in MC Yahoo Group
which grabs all the thousands of tiny XML files and puts them into a
stack which can take advantage of the performance and flexibility of the
object model.

If someone would be willing to do the small task of updating that for
the latest docs format (extra bonus points: convince RunRev to stop
changing the format <g>), it may be good to include it with the IDE
installation, perhaps replacing the outdated Dictionary stack it has now.

> I'm sure there are other things I cannot think of at the
> moment.

I have one:  simpler, smarter installation.

I started down this road with FlipsIDE, which let you flip into other
IDEs from within Rev.  But if you like another IDE why would you want to
launch Rev first only to flip out of it?

So I started sketching out it's successor, DarksIDE: a Rev plugin with
just one button:  "Install MetaCard".  It would do all the steps we
currently do manually, from rebuilding the engine to downloading the IDE 
to importing the Dictionary content, putting everything into a new 
folder all tidy and ready to go.

Using RIP properties this would be a snap to design, and would be a real
boon to MC usage -- one click, wait a few seconds, and any Rev user can
try MC quickly and easily.

If someone in this group would like to be the owner of this component,
I'd gladly share my notes.  Tariel, Sims, got a couple free hours?

> I have asked several times since using MC about searching all scripts,
> and never got a really good solution.  I MISS the Hypercard ss
> function.  That was awesome!  It just took you to each instance,
> let you change it, then moved on to the next one.

Was HC's script editor modal?  I'd thought it wasn't.  If not, how did
ss suspend while the script was being edited?

> 1.  Search (and edit) all scripts in a stack, including substacks
> 2.  More advanced standalone saving
> 3.  More detailed info in the Help docs
>       a.  Often the Help Index assumes you know something already,
> sometimes I want to learn something new, and the Help Index doesn't
> give me enough to even make the attempt, I must search thru the online
> archives in the hopes that somebody posted detailed code in answering
> somebody else's question.  Even a line or two of example code would be
> useful, but often isn't there.

Great summary.

I think the path forward is an invitation to the open source advocates
in the Rev community to put up:

With Klaus maintaining his role in coordinating things (thank you 
Klaus!), we could use owners for these components just as we've had 
owners for other components (e.g. Ken's done a wonderful job managing 
the Variable Watcher).

I'm willing to be owner of the Standalone Builder.  Do we have folks
here willing to take on Search and Docs?

What other areas might we consider?

The philosophy of a lightweight IDE continues to hold appeal for serious 
developers.  If we can elevate MC's usability and affordances to meet or 
exceed Rev's while still holding true to that philosophy, I see no 
reason why any switching couldn't be happening in the other direction, 
just as it is with Galaxy.

There are many who expound on the benefits of open source.  This is an 
opportunity to demonstrate those benefits, delivering an IDE which is to 
Rev what Firefox is to Internet Explorer.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com