This post goes out to really <anyone> here who's publishing and
dealing with the f8 upgrades, not just the Fuse userbase. (Some
exciting news guys, I've been confirmed to speak on Fuse at Flash
Forward Seattle - hope to meet some of you folks there!) So while I'm
awaiting Aral's resonse on whether Fuse will become an OSFlash
project here's the lowdown.
I'm strategizing on how I add solid f8 support into the kit without
getting into a multiple version situation with my code, and without
ditching on F7 users. I know many designers will tend to lag behind
about a year in upgrading to the F8 authoring tool. Fuse is - for us
- a complete syntax for condensing those pesky, but often necessary
chunks of procedural code we all have to write, into something much
tidier, more readable and OO. But still the base ZigoEngine (tweening
engine) class is for everyone, and is favored by tons of beginning
coders, so I do need to cater to both camps, including non-upgraders.
So here's my idea: Architect one highly extensible package and give
developers the option on what "extensions" to import. It would look
like this (doesn't work with current version!) --
import com.mosesSupposes.fuse.*;
ZigoEngine.extend(PennerEasing, Shortcuts, Flash8Color,
Flash8Filters);
This way, just about everything becomes optional, which lets you
control filesize more accurately. Like if you only plan to use 3
easing equations you could just keep those separate and not use extend
(PennerEasing), or if you never use the shortcuts (obj.alphaTo, etc.)
you could omit extend(Shortcuts), plus select between F7Color vs.
F8Color and so on.
It also makes it easier for you guys, the OS community, to jump in
and write your own additions to the kit which can be tossed in as
separate "extension" classes, without having to muck around in the
engine class itself.
So what do you think about that strategy? Is this "overcomplicating"
things (which I definitely want to avoid) - or keeping things as
simple and flexible as possible?
Thanks for your feedback!
Moses
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
