MC IDE

[jbv]

Robert Brenstein a écrit:

> >
> >If Revolution were modified so that only the basic functionality was
> >implemented in the IDE and all other features were implemented as modules
> >that could be turned off would that satisfy everyone? If so, perhaps we
> >could develop a proposal for RunRev to implement such a design.
> >
> >The ability to develop custom modules that would fully integrate into the
> >IDE would be fantastic as far as I'm concerned.
>
> >
> >Monte
>
> 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...
I don't think that turning on/off modules on the fly is necessary :
IMHO most users don't change their preferences very often once
they get a GUI that suits their needs...
Perhaps this could be achieved by dropping stacks into a Preferences
folder, whose content would be loaded at MC startup, a bit like
you drop extensions into the Mac system folder...
This way, private features could be added very easily...

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...
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.

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...

JB