incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: Design View AIR App (Was: Re: Apache Flex GUI Designer tools)
Date Tue, 02 Oct 2012 21:30:32 GMT
On Tue, Oct 2, 2012 at 1:44 PM, Michael Schmalle <apache@teotigraphix.com>wrote:

> 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.
>
>
Dream on!  We can always try things out and see if they work or not :-)


>
>  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.
>
>
That is fantastic!  I have written something similar, but that is
proprietary code.  I was planning to write everything from scratch.  Any
chance you could contribute your component to Apache Flex?


>
>  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.
>
>
I am not clear on this.  Can you please elaborate?  Are you talking about
re-opening a project in the design view?  Or writing the properties to the
XML?


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


We could invoke an ant script or a batch file from within the AIR app that
triggers the compiler.  Or even invoke the compiler directly as a
NativeProcess.


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

The current design view in Flash Builder is implemented as an AIR app.
Look inside: \Adobe\Adobe Flash Builder
4.6\eclipse\plugins\com.adobe.flexbuilder.designview_4.6.0.328916

I have no idea how it is integrated into Eclipse as a view though.  My best
bet is that the AIR runtime is invoked inside an Eclipse plugin.  The AIR
runtime in turn invokes the design view air app.
Sounds like fun :-)



>
>  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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message