Plugins, fonts

[Monte Goulding]

>
>These are mostly all good, I like it. The only one that probably isn't
>essential though is the "active" type. As Richard said, that can already
>be done using a library type stack. Something like this:
>
>on librarystack
>  doMyOneStartupThing
>  stop using the script of this stack
>end librarystack
>
>Would work, yes? Why invent another type?

Could they also be done via the auto-open type:

on preOpenStack
  doMyOneStartupThing
  close this stack
end preOpenStack

Cheers

Monte

PS Here's my rather long winded draft proposal for Revolution modularity
which is plugin related and could be implemented in mc or a fork of mc as a
demo (it's in Wiki format):

!!!!IDE Modularity

!!!Introduction

In general all the IDE truly needs to do is the basics. Allow setting of
object properties, scripting, standalone building, object creation etc.
Everything else can be done with script libraries and user interfaces for
them that are either part of the IDE or not. What I'm suggesting here is a
way to integrate libraries and user interfaces for them into the IDE in a
general way that can be exposed to third parties.

So what would we need to do this?
#auto loading of modules the user has chosen to load
#module documentation that integrates with the Rev docs yet is clearly
marked as belonging to a particular module as the current libraries are now
#standalone building support (partially implemented)
#manager style stacks able to be listed under the Tools menu
#inspector panels able to be listed for specific objects
#preference panes

So what's the benefit of this effort?
#Third parties can seamlessly extend the IDE (think Jan's reporting package)
#Some of the more complex components of the ide can be moved into optional
modules to simplify maintenance and allow those that don't use them to
switch them off (think Geometry library)
#Simplify management of the IDE differences required for Express, Studio and
Enterprise Editions (think Database Manager and library for Express or
additional CVS Manager for Enterprise)
#Some components that haven't been used much and are costly to maintain
could become community projects (think Animation Manager and library)

!!!Basic IDE components

Script editor and debug tools
Inspector shell including
-All properties pane (cetegorized and using disclosure triangles for main
categories)
-Custom properties pane
Help interface and general documentation
Menubar/Toolbar shell
Tools palette
Icon manager
Standalone builder
Preferences shell including
-preferences for the basic IDE components
-switching on/off modules
Application browser
Message box

!!!Configurable Modules

A configurable module may contain resources to add to the IDE the following
components:
-Toolbar buttons
-Externals
-Library stacks
-Back scripts
-Front scripts
-Inspector panes
-Preference panes
-Documentation
-menuItems/buttons on menubar
-Contextual menuItems on objects
-Contextual menuItems in application browser

!!Module Design

The revPreferences stack will have a custom property set that identifies
which modules are to be loaded at startup. Any modules that don't have a
setting here should be loaded by default. Module names are identified by the
name of the directory in the modules subdirectory. A module name should be
considered like a namespace so custom properties, message names, stack names
etc should be prefixed with it. Looping over the directories of the modules
subdirectory and testing against the custom property set in revPreferences
is the first stage of the module loading process. For each module to be
loaded the IDE must loop over the files in the directory to identify how and
where to extend the IDE. For each stackFile found a custom property set of
the mainStack of the stackFile should identify how it should be integrated
into the IDE. For example, if the custom property set had two keys
(componentType and standaloneOption) with values (libraryStack and true) the
stack would be loaded as a library and it would be provided as an option
during the standalone build process for inclusion into standalones.

Implementation details for each component type are provided below:

!Toolbar buttons (componentType = toolbarButton)

Stack containing X number of buttons each representing 1 toolbar button to
be added to the revMenubar stack. It's possible that we could end up with
too many buttons here so a means to choose which order these are displayed
in might be nice with a button at the end that showed any remainders in a
menu. The icon properties and label of the buttons are copied to the shell
button created on the revMenubar stack. From there it's just a matter of
trapping button related messages and sending them to the original button. If
we have object frontscripts by then that may be the way to go.

!Externals (not stackFiles)

Work needs to be done here to work out the best options for dynamic external
loading but the ideal situation is at loadtime the correct external for that
platform can be loaded and inserted into the message path. It may be that
the best option is to implment externals as an optional key for a library,
front or backscript and set the externals property of that stack, save and
reload before inserting into the message path.

!Library stacks (componentType = libraryStack)

This stack is simply inserted into the message path. If it has a
standaloneOption = true key then the standalone builder will allow the user
to choose to incorporate this library.

!Back scripts (componentType = backScript)

Any buttons found on this stack are inserted into the back of the message
path. If any of the buttons have a standaloneOption = true key then the
standalone builder will allow the user to choose to incorporate the
backScript.

!Front scripts (componentType = frontScript)

Any buttons found on this stack are inserted into the front of the message
path. If any of the buttons have a standaloneOption = true key then the
standalone builder will allow the user to choose to incorporate the
frontScript.

!Inspector panes (componentType = inspectorPane)

The ideal implementation of this would involve a browser object that could
display Rev cards of one stack in a viewer on another stack. Failing that
there are some sub-optimal workarounds that could be explored. Each card of
the stack should have an objects key that defines which objects that card is
an inspector pane for. If there's only one card or no objects value then one
pane for all objects would be assumed.

!Preference panes (componentType = preferencePane)

The ideal implementation of this would involve a browser object that could
display Rev cards of one stack in a viewer on another stack. Failing that
there are some sub-optimal workarounds that could be explored.

!Documentation (not stackFiles)

This requires a redesign of the online documentation to use xml files which
are imported into stacks. Module documentation is clearly marked as such.
Inside the module's folder there is a docs folder that includes
sub-directories for the major documentation categories. Structure of the
docs folder and files are the same as the general docs folder and files.

!menuItems on menubar (componentType = menuItems)

A key menuButton will identify the menubar button name. If it's an unknown
button name then a new one is created and the menuButtonLabel property is
checked for a more user friendly name. This stack will have a getProp
handler to return the menuItem (used in the mouseDown handler on the menu
group) and a menuPick handler which sends the menuPick parameter that the
menuButton recieved.

!Contextual menuItems on objects (componentType = objectMenuItems)

A key objectTypes will identify the objects that have these menuItems added
to their contextual menu. In other respects this is implemented in a similar
way to above.

!Contextual menuItems on application browser (componentType =
appBrowserMenuItems)

This is implemented in a similar way to above.