> Using a prefix implies that there is the possibility of extending the MC IDE
> in the future and a potential getting-in-the-way. This is something we don't
I clearly agree that the "getting in the way" is something we don't want,
but can you clarify what you mean by "extending the MC IDE"?
> Although it isn't a big deal, I think that using a prefix like "mc" is very
> RunRev-like and not the right approach. Since the number of IDE stacks is
> supposed to stay at a minimum, a prefix should be unnecessary. If we ever need
> something like this, it would be nice to come up with a really clever and
> friendly solution.
I'd *love* for there to be less IDE stacks - currently there are *70*
substacks of the Metacard Menu Bar stack. Granted that some of these are old
copies that can be deleted or are for dialogs to set really old settings, or
are copies of the Script Editor, but without some significant changes it's
not going to get much smaller.
I think the issue is that until RunRev creates namespaces inside LC, the IDE
stacks should be renamed to get out of the way of the developer, at least
the more common ones like Preferences and Properties. The only issue with
only renaming *some* stacks is it becomes inconsistent, which is also a
The good thing though is that unless one is working on tools to manipulate
the IDE itself, they shouldn't encounter the internal stack names of the IDE
stacks very often, so it may not matter what they get called as long as they
get out of the way.
Just my 2 cents,
Sons of Thunder Software, Inc.
Web Site: http://www.sonsothunder.com/
metacard mailing list