Speaking of IDE Updates

Sun Dec 28 01:24:55 EST 2003

This messages is being copied to both the MetaCard list and the MC_IDE group
at Yahoo to update folks about the IDE and to ask the question:  do we need
two mailing lists?

While Yahoo Groups require membership in a group in order to access its
files, I hadn't intended to suggest that we also use the mailing list that
comes with the group to augment/displace the conversation on the existing
MetaCard list.  If I recall correctly, when we took an informal poll of the
topic in the MetaCard list back in August it seemed that most folks
preferred to keep discussion of the MetaCard IDE on the main list.

I have no objection to using the mailing list at the MC_IDE Group if it's
useful, but since we're all subscribed to MetaCard list there may be merit
in keeping the discussion there as much as possible.  For myself, to
minimize duplicate posts in people's In Boxes while reaching the most MC IDE
users, going forward I'll post just to the MetaCard list unless there's a
compelling reason to use the MC_IDE group list that I may have overlooked.

On the status of the MC IDE:

It took us a while to iron out licensing and stuff, but we finlly have an
initial open source release of the MC IDE.

Looking ahead we see two camps forming:  those who say "The MC IDE must
change" and those who say "The MC IDE must remain the same."  As my
grandpappy used to say, "When faced with two compelling options, the earnest
designer finds a way to choose both."  :)

So here's my proposal for the next set of changes to the MC IDE:

Regardless of whatever other changes which might be made, any future options
can, and arguably should, include the addition of a Plugins menu.

I think it would be easier to use it as a main menu in the menubar as
opposed to a submenu in the Tools menu, but if there's a reason that
wouldn't be a good idea we should discuss it.

As RunRev's marketing continues to expand the Rev audience, I think it makes
sense to implement a Plugins menu in a way which is compatible with Rev
plugins and would encourage developers to use methods that allow a plugin to
be used in the Rev IDE also.  Since a plugin is just a stack and a Plugins
menu simply a way to open the stack, this shouldn't be too hard. :)

Keeping with the spirit of MC's engine-centric focus, I would propose that
we use the built-in style property of stacks to govern mode, with the
default being modeless unless you hold down the Option key (Mac) or Alt key
(Win) in which case it opens as toplevel so it can be easily modified.  If
you want your plugin to be a palette just set the style and save it.  We
could just as well use palette as the default - opinions?

The Rev IDE provides other custom properties for plugins, and I think it
makes sense to support the style property for those plugins that already
have it.  Other IDE-specific custom properties, such as those that register
a plugin for custom IDE messages, can be supported as an option settable in
a Plugins Manager window, which would be off by default to keep the message
path as clean and simple as possible.

While the mechanism for custom IDE messages like revSelectedObjectChanged
can be easily supported, for simplicity I would encourage the use of
frontscripts to handle messages directly, so long as we all play nice and
maintain the good habit of always passing system messages.

Once we have a Plugins menu in place you can mix and match your favorite
editing components without bothering with wacky stuff like my UmbrellaMan
tool. :)  We can play around with those and start a duscussion of candidates
for inclusion in the main distribution, possibly including some directly in
mctools.mc.  I'm anxious to see what Ken and Hugh are cooking up with their
script library, and Scott Rossi has some good ideas about a resize tool....

I'm game for implementing a first pass at a Plugins menu and posting it for
your review, but I should warn you that I won't be able to get back to the
IDE again until after the Rev Seminar at MacWorld on Jan. 9 & 10
<http://www.runrev.com/macworldschedule.html>.  So if one of you has time
and energy to dig into that before then that would be cool but we should
probably coordinate it on the MetaCard list to avoid duplication of effort.
If not, I'll be able to resume work on the IDE on the 11th.

In the meantime you can always trade plugins easily in RevNet, so if you
want to extend IDEs you can start yesterday -- all you need for a plugin is
a stack file and a way to open it. :)

Notes about plugin design:

There's not much to it since it's just a stack file, but there are a few
basics worth keeping in mind with any IDE components:

- Pass system messages.
  Never assume your plugin will be last in line; any library or
  backscript inserted after yours may need that message.  This
  is especially important with frontscripts, because if they
  don't pass a message nothing in the user's stack will get it
  either.

- Keep it simple.
  Most plugins do one thing really well.  There may be good
  reason to do something deep like Geoff Canyon did with his
  Navigator tool, but usually the pugins people will enjoy
  most often are the simple gems that shine at one specific
  task.  Specialization is not just for insects. :)

- Restore any changed global properties.
  If you change global properties, save them first and restore
  those values again as soon as possible before your routine
  exits. You never know what values a developer might be relying
  on for global properties, or when.

- Make it self-contained.
  Reliance on IDE-specific features may limit your tool's
  audience, and with IDEs being in a process of continual
  improvement this may help prevent having to update your
  tool each time an IDE changes.

- Frontscripts are your friend.
  You can insert them when your stack opens and remove them
  when it closes and you get access to all messages sent to
  any object.  Very handy -- just be sure to pass such messages
  when you're done with them.

- Write for explicitVars.
  A developer using your tool may be working with the
  explicitVariables global property set the true.  If
  you leave it on as you write plugins you can catch
  any undeclared variables before your users does.

- Test.
  You know how it goes.

Side note about messges: If you're making anything that responds to the
selectedbjectChanged message you might want to consider using the "message
buffering" technique used in 4W Props (downloadable from
<http://www.fourthworld.com/rev/index.html>).  This method allows palettes
to appear much more responsive when updating their UIs after user selection
changes; keep MC's Inspector, Colors, and Font palettes open and drag-select
around 50 objects and you'll see what I mean. :)

That's more than enough for now. I gotta get back to work wrapping up
year-end projects and preparing for the Rev seminar.  Hope to see you folks
in SF....

-- 
 Richard Gaskin 
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc