ActionStep Alpha 1 is now available!
It can be downloaded here: actionstep_alpha_1.zip
Welcome to ActionStep
This project is born out of the frustration with the Version 2 Component framework that shipped with Macromedia Flash Professional 2004. There are many problems with V2 components including poor quality code (tis a bit buggy), poor development environment (Flash IDE is a bad coding experience) and a really dreadful licensing policy (you can only use V2 components if you own the Flash IDE). If all of this was not bad enough, the actual implementation of the V2 components is a hybrid model which uses a combination of symbols in the Flash Library and ActionScript 2.0 source. I suppose the idea was that all of the theming would be controlled by the symbols (thus artist-types could craft the look and feel), and all the behavior would be controlled by ActionScript (thus coder-types could add/change behavior). Sounds nice in theory but it creates some severe problems.
The first problem with the V2 component architecture is if you want to use components in a swf file you have to include the Library symbol resources compiled into your movie, even if your movie is loaded into a movie that already includes those resources. The reason for this is Flash symbol resources cannot be shared across swf movies. If you theme a component using the symbol Library, you have to compile those symbols into each movie where you want components to be rendered with that theme. This eliminates a key usage pattern where you build/load a theme swf which customizes all of the components along with other movies that make use of those same components. Theming at runtime is not truly supported. Another problem is if you are a programmer, trying to grok the Flash component theme model is a tad steep from a learning curve perspective. Having to go back and forth from visual symbols to source code is difficult challenge. What to do? Although Library symbols are not shared across movies, it ends up that ActionScript classes can and are shared across movies (they are loaded into a single shared namespace). This led to a potential of a pure ActionScript 2.0 component model that created all visual elements at runtime but did not use symbols in the Library, did not restrict usage from a license perspective, was not buggy and allowed you to use your current development tools.
ActionStep will include a full Responder architecture (NSResponder, NSApplication, NSWindow, NSView, etc) and be heavily based on delegation (rather than inheritance). The brilliant separation of concerns in AppKit will enable theming that is purely coded in ActionScript without requiring the Library of symbols. With ActionStep, you will be able to compile into a base movie the ActionStep classes that you use + customized theming classes, and any other movie that you load that uses ActionStep will 'inherit' those themed components at runtime. This will enable VERY SMALL flash movies that provide the much vaunted Rich Internet Application experience.
Call to Arms
Knowing that this is a big undertaking, my hope is to enlist other like-minded open-source developers in creating ActionStep. A very recent development that makes this possible is the incredibly wonderful open-source Motion-Twin ActionScript 2.0 compiler: MTASC This compiler is all that is needed to develop for the ActionStep project. If you would like to contribute to the ActionStep project, please see the Project links in the right column.