incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <apa...@teotigraphix.com>
Subject Re: Design View AIR App (Was: Re: Apache Flex GUI Designer tools)
Date Tue, 02 Oct 2012 20:44:23 GMT
Quoting Om <bigosmallm@gmail.com>:

> 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.

This is where the new compiler from my perspective could be really  
fun. During the build of the app when "packaging" I could write  
something that actually created this XML. You could use custom doc  
tags in the source code even to add functionality (like @designview),  
the comments, values, etc of the components could be written to XML as  
well so you could have a wealth of information in the core  
application. Just dreaming here.

> 2.  Design area:  This would be a container where we will draw the objects

I actually wrote a RuledCanvas component 3 years ago that exactly  
mimicked fireworks interface with the sliding rulers, drag and drop  
components onto the "floating canvas". I spent about 2 years on it. It  
has rulers, snap, resize, move, guides a grid etc. hehe Search google  
for ResizeManagerFX That was a commercial component I mad for Flex 2.

> 3.  Interactive layer:  Any object or group of objects in the design area
> can be selected, resized, rotated, constrained.

See above.

> 4.  Properties area:  Properties such as: styles, skins, layout of selected
> components could be changed here.


This could all be created in the build using the compiler to create  
the XML manifest (see above). It would actually use the same type of  
logic I have currently in the documentor I'm working on with Flacon.

> 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.

This I would be listening to others as to the best implementation but  
I know we might be able to even target the compiler from inside the  
app right?


> 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.

This would be very interesting, I never though about it this way if  
it's possible.

> 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, <teotigra@teotigraphix.com> wrote:
>
>> Quoting Alex Harui <aharui@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.
>>
>>
>>
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com


Mime
View raw message