I barely touch mobile (at the moment). If I did I would probably be interested. I'm hoping someone else picks up on this…
Harbs On Mar 23, 2013, at 6:39 AM, Daniel Freeman wrote: > I wrote one of those. I wrote SVG -> AS3 graphics. And extending that > class, I wrote FXG -> AS3 graphics. > > It wasn't a complete implementation of the SVG or FXG standards. It didn't > handle text, and complex gradients weren't perfect. The FXG class was > based on Adobe's first FXG definition. But it worked pretty well. > > This was one of the features of the applications I offered to donate. > > Actually, if you go back to build r53 of extendedMadness. SVG was in > there. I took it out, because I didn't think too may people would be > interested - and to reduce the bloat. (I didn't want my Framework getting > like Flex - did I), > > http://code.google.com/p/mad-components/source/detail?r=53# > > See example here: > http://code.google.com/p/mad-components/source/browse/trunk/MadComponentStuff/src/MadComponentsDesktop.as?spec=svn53&r=53 > > FXG isn't too different from SVG. > > > ... I've mentioned this before, but I'd like to relinquish control a little > over maintaining MadComponents, ExtendedMadness, and MC3D. I've offered > before to donate them to this Apache group. > > Bear in mind that people aren't using Flex to build mobile apps. They're > using MadComponents (General Purpose / Enterprise) or Feathers (Game UI). > In fact, I've had clients engage my freelance services because they tried > to build a mobile app using bloated Flex - and regretted it. > > http://madskool.wordpress.com/2012/01/23/why-developers-are-using-madcomponents/ > > Is there any interest in this group in MadComponents? > > > On Sat, Mar 16, 2013 at 4:01 AM, Michael Schmalle > <apa...@teotigraphix.com>wrote: > >> >> Quoting Alex Harui <aha...@adobe.com>: >> >> In my simple mind, Falcon generates the AST then at some point in time the >>> futures task for that compilation unit is asked for output. Current >>> Falcon >>> code calls the BURM which eventually calls an emitter, I'm assuming >>> FalconJX >>> does an AST tree walk instead of calling the BURM. There is no reduction, >>> just emitting. CSS for JS is probably just going emit text from the tree. >>> >> >> Yes this is correct basically. >> >> Each compilation unit implements its own handleASBRequest() that gets >> called during a generator request. This request ONLY happens AFTER the >> handle AST and Scope requests have been processed. >> >> Its very complicated below that principle because of the future tasks and >> outgoing dependency requests that trigger other files to be parsed, scopes >> built etc. >> >> THe framework is elegant. The only thing I wish I could tear out and >> abstract is how they have SWF baked into ITarget and Target. >> >> This really makes it hard to do what we are doing without all this >> "baggage". >> >> As I said, parsing is multithreaded right now in FalconJx, I can easily >> get the source code generation multithreaded to now that I have learned how >> the framework wheels move together. >> >> I'm just not at the point to worry to much about it at the moment because >> in a couple of my test projects, the compiler is wicked fast, I also have >> an implementation that uses the Workspace and only loads config once, which >> is using the framework like and IDE does... >> >> Mike >> >> >> >> >>> On 3/15/13 1:44 PM, "Michael Schmalle" <apa...@teotigraphix.com> wrote: >>> >>> BTW, >>>> >>>> I have not seen one thing that you are asking for that doesn't contain >>>> an AST and node framework in the Falcon package. >>>> >>>> If it was me, I would create all the emitters exactly the same way be >>>> parsing the file, handling the AST, traversing it while outputting to >>>> the target, then writing it in its file format. >>>> >>>> Its simple and I guess the FalconJx framework is mainly due to me >>>> dealing with inheritance and dependency madness with Flex components >>>> for years. I said all my future projects will use composition, this >>>> one does big time. >>>> >>>> Mike >>>> >>>> Quoting Michael Schmalle <apa...@teotigraphix.com>: >>>> >>>> >>>>> Quoting Alex Harui <aha...@adobe.com>: >>>>> >>>>> >>>>>> >>>>>> >>>>>> On 3/15/13 1:14 PM, "Michael Schmalle" <apa...@teotigraphix.com> >>>>>> wrote: >>>>>> >>>>>> The problem is, SWF is so >>>>>>> interconnected in the generator packages that you might have a problem >>>>>>> getting a polarity with using the BURM. >>>>>>> >>>>>> Don't know what "polarity" meant, but hopefully it doesn't really >>>>>> matter. >>>>>> >>>>> >>>>> Bad word, I meant polarity in emitters as what the BURM generators >>>>> offer right now with FalconJS, properties, css, as, mxml. >>>>> >>>>> >>>>> On that note; This would take more study to fully understand, but at >>>>>>> the moment I don't have time to investigate. I guess you will have to >>>>>>> weigh the options or get a "feel" for the Falcon framework when your >>>>>>> not under as much of a timeline/deadline? >>>>>>> >>>>>>> That being said, the FalconJx framework was meant to be created in >>>>>>> component sections, so if your end goal is to create things with it >>>>>>> fully, I would suggest things being ported to its emitter, or it will >>>>>>> for ever have a crutch on SWF. >>>>>>> >>>>>>> Good point about the generators being tied to SWF constructs. But I >>>>>> am >>>>>> assuming you that, in order to service different file types we will >>>>>> have >>>>>> several emitters? One for AS, one for MXML/AS? I think I will create >>>>>> one >>>>>> for CSS and someone will create one for FXG->SVG? And since these two >>>>>> probably won't generate JS "classes", I think they won't be tied to >>>>>> the SWF >>>>>> constructs in the generator and thus will copy over "easily". >>>>>> >>>>> >>>>> Right, if I was getting paid for this stuff, I could have most of it >>>>> done in a month or two, so using the pattern I have created with >>>>> FalconJx all your emitters with file handlers are possible. >>>>> >>>>> To realize what you need Alex, the knife is already built, its just >>>>> adding the blades. >>>>> >>>>> Mike >>>>> >>>>> -- >>>>>> Alex Harui >>>>>> Flex SDK Team >>>>>> Adobe Systems, Inc. >>>>>> http://blogs.adobe.com/aharui >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Michael Schmalle - Teoti Graphix, LLC >>>>> http://www.teotigraphix.com >>>>> http://blog.teotigraphix.com >>>>> >>>>> >>>>> >>> -- >>> Alex Harui >>> Flex SDK Team >>> Adobe Systems, Inc. >>> http://blogs.adobe.com/aharui >>> >>> >>> >> -- >> Michael Schmalle - Teoti Graphix, LLC >> http://www.teotigraphix.com >> http://blog.teotigraphix.com >> >>
