> >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. _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard