MC IDE

[Robert Brenstein]

>  > What you suggest would be only a half solution IMHO.
>>  Hiding/deactivating undesirable or not needed elements could
>>  unclutter the display. However, the large memory requirements will
>>  likely remain and so will the background activity to name a few
>>  things that affect some of my work. Plus this will complicate the Rev
>>  IDE even further, hencefore making it potentially less stable.
>
>May be, but also may be not : I think the idea of modules to beturned on/off
>is a great one (actually I had the same not so long ago :)
>And IMHO the possible memory / bg activity / stability problems
>mentioned by Robert could probably be bypassed by using an
>adequate structure : modules would be selected so that to update a
>preferences file that would be taken into account at the next launch of
>Rev only. This way, only modules used would be loaded into memory
>and therefore would reduced the amount of memory needed as well as
>the bg activity, and a simpler configuration would certainly mean
>more stability...

Modules as in plugins, yes. But I am afraid that there are too many 
interdependencies in Rev's IDE and untangle that may be too much 
effort to satisfy a few of us. Theoretically, yes, it is possible.

>Anyway, I could be wrong, but I think that from a commercial /
>marketing point of view, now that RR owns the MC engine, a
>sophisticated GUI should become less important...

I am not sure I follow. I'd think that GUI has the same importance 
regarding who owns the engine. The plus of owning the engine is that 
some of non-GUI features can be moved into the engine.

>Well it should still be an option (especially for Director afficionados
>and other developpers wannabes who think tons of palettes mean
>a more sophisticated / productive piece of software), but the
>main goal needs to be the improvement of the engine of course.

It may be tempting to put GUI into the engine but I hope and doubt 
that this will happen. The engine is used to produce standalones that 
do not use any of the development GUI. Unless of course, Rev follow 
the suggestion posted here to make engine as a collection of 
libraries/modules that are included on as needed basis.

>Another great thing I'd like to see implemented in the engine
>(already mentioned on this list by me about 1 year ago) is that
>the interpreter would be structured as librairies (like in C/C++) :
>standard, math, graphics...
>This way, when building a standalone, only librairies used in
>the stack would be added to the stack, and not the whole engine.
>Of course, this process should be 100% transparent to the end user :
>the engine should be able to analyse which librairies are needed
>and would add those only. This would perhaps lead to a slower
>standalone building process, but also (and mainly) to slimmer apps.
>Well, I'm not sure if this is feasable... Perhaps does that imply
>to re-write the whole engine... But I don't think so : seeing how
>new features are added to MC at every update (without ruining
>what already exists) shows that obviously some modularity already
>exists...
>

But that may be tricky if impossible considering that 'do' and 
dynamic script setting introduce element of unpredictability. This 
could only work for separating the development IDE if that ends up in 
the engine.

Robert