Thanks, Om, for taking the initiative on this matter! I still doubt, though, that this designing and skinning tool, you are proposing, can be created by one person alone. If the Adobe Catalyst team couldn't finish Flash Catalyst within 4 years of development, how could you possibly do that just on your own?
The way I see it: The Flash Catalyst development should be reopened and splited up into an open source project and into a commercial project. The open source project should be hosted on Github and codenamed Adobe Thermo again [1] - just like Adobe Brackets [2]. Further, the commercial product, called Flash Catalyst again, should reenter the Adobe Creative Suite product line in CS7. In case that Adobe blocks those affords then, maybe, the Spoon project would have some financial resources left to start this initiative. Thoughts? Sincerely Yours, Sebastian Mohr Apache Flex Developer (PPMC), Interaction Designer & Musician http://www.linkedin.com/in/masuland [1] https://github.com/adobe/thermo [2] https://github.com/adobe/brackets On Oct 2, 2012, at 9:56 PM, Om wrote: > I am very interested in building the design view as an AIR app. Lets talk > design/architecture now. > > Here is a brain-dead architecture design of the AIR app, that lets the user > interactively drag and drop components, apply layouts, change labels/titles > etc. > > Conceptually, this is simple enough. This contains the following > components: > > 1. Components list: We read the list of available components from a > manifest file and populate a toolbox on the side. > 2. Design area: This would be a container where we will draw the objects > 3. Interactive layer: Any object or group of objects in the design area > can be selected, resized, rotated, constrained. > 4. Properties area: Properties such as: styles, skins, layout of selected > components could be changed here. > 5. Skins could be created/edited in the same way. They could also be > applied onto their corresponding Host Components as well. > 6. Generate MXML: This is the part that I am unclear. My first thought > is to walk through the flash player display hierarchy and create an XML > containing all the components in the screen along with their properties and > styles. Feed this primitive XML into Falcon (lots of hand-waving here) > which spits out MXML. This MXML can be edited in the IDE. > > Bonus features: > 1. Hooking up to Data services > 2. Round-tripping between Design View <=> IDE > 3. Writing Eclipse/IDEA plugins as wrappers around this AIR app so that it > can be integrated into IDEs. > > I *know* I am missing something obvious above. Please provide your > feedback so that we can iteratively fill out the design. > > Thanks, > Om > > On Tue, Oct 2, 2012 at 12:20 PM, <teoti...@teotigraphix.com> wrote: > >> Quoting Alex Harui <aha...@adobe.com>: >> >> >> You are welcome to open a JIRA ticket for Apache Flex and try to see if >>> you >>> can define requirements in priority order. Remember that this is a >>> volunteer organization so you can't just say "replicate DV". What are the >>> most important aspects of DV? Is one of them IDE integration? If so, >>> why? >>> An AIR DV could certainly launch an ant script to build your changes. >>> >>> >> Just reiterating on something I said in a previous post to this; If a >> project could start, start small with a prototype only doing the basic. >> Then slowly add functionality. This would be very important for an endeavor >> like a DesignView. >> >> I have written Eclipse plugins before, I have no idea how to write an IDEA >> plugin, I looked and saw I would have to learn a very different framework. >> >> With the new compiler and it's AST and definitions, it would make >> something like this a whole lot easier, and I'm speaking from 2 weeks >> experience with the code. >> >> I want to mention one more thing here. Acting as a developer of something >> like a design view, there is a huge overwhelming fear that it could lose >> interest and get abandoned purely out of volunteers moving, or working on >> other things. Loosing traction on a project like this when you spent time >> developing it and know you could have been doing something else is always >> in developers minds. >> >> So add the risk factor as well. For years I have heard Flex developers say >> they use it all the time to others saying it was a waste of time and time >> should have been spent on the more important features. >> >> Mike >> >> PS On the plus side with an AIR implementation, being written with Flex >> would be a boost to the whole project because you would be using the >> framework components and creating new ones purely out of the need for the >> new functionality. It could almost act as a live garden of growth for the >> framework. >> >> >>
