On Mar 25, 2013 5:04 PM, "Alex Harui" <aha...@adobe.com> wrote:
>
>
>
>
> On 3/25/13 3:41 PM, "Om" <bigosma...@gmail.com> wrote:
>
> > On Mon, Mar 25, 2013 at 3:25 PM, Alex Harui <aha...@adobe.com> wrote:
> >
> >> Hmm.  But at the top-level is a non-FXG element like Skin or something
like
> >> that, right?
> >
> >
> > I plan to use the <div> or <svg> elements for this.
> Well, in FlexJS, we aren't translating MXML tags into HTML tags.  The
> component API surface is the contract.  You need to have wrapping code
> around the DOM elements in order to handle the abstraction.

Agreed.

> >
> >
> >> And, you don't know if script is going to change any of these
> >> entities at run-time.  How are you going to make that happen when
> >> converted to SVG?
> >
> >
> > You can manipulate <div> and <svg> using Javascript or CSS.
> See my note above.  Again, you will need JS wrapping to abstract the
> differences.

I think we can still handle that.

> >
> > I am working on an example of doing just this.  Give me a couple of
days to
> > put out some sample code.
> >
> >
> >>   Finally, nobody "drew" this skin in a design tool.  It was
> >> hand-coded so it could have script code change things at runtime.
> >>
> >
> > Which is exactly why I want to transform the MXML/FXG code instead of
> > relying on Illustrator spit out SVG for me.  This way, we preserve all
the
> > custom skins that users might create for themselves directly in MXML.
 I am
> > just relying on the fact that it resembles FXG which can be transformed
> > into SVG relatively easily.
> >
> Well, if you want to re-use Spark skins, then FlexJS is not for you.

I don't want to reuse spark skins.  I just want to use the spark paradigm
for skinning.  I am using the current spark skins as examples for the POC.

 FlexJS
> is a rewrite of Flex and the skinning model will likely be different
because
> I want to try to fix the problems of Spark skins like the skin part
> contract, the extra display object, and the fact that most default skins
had
> code in them.  Over time, we can add enough alternative beads to fully
mimic
> Spark Skins, but I really don't want to make that the default pattern for
> FlexJS.

As long as we use MXMLG for the skins I would be happy.   Do you still plan
to use MXMLG in FlexJS?

>
> Erik thinks he can do all of this in VanillaJS.  I still think it will
take
> him too long to get to a minimal viable product and VanillaJS will have a
> huge minimal download and worry that folks are waiting for him instead of
> jumping in on FlexJS hoping he can provide the magic bullet.

I would be happy to help out with FlexJS if I knew more about how you plan
to implement skinning if components.

Thanks,
Om

> >
> >>
> >> IMO, a vector skinning model would leverage FXG as it is spec'd.
 Maybe we
> >> need to allow FXG in "sub-documents" in a skin (like we do for in-line
item
> >> renderers with fx:Component), but I think you can also simply declare
an
> >> FXG
> >> class as a tag in a skin.  But from an MXML skin perspective, every tag
> >> maps
> >> to a class.
> >>
> >
> > Got it.  I dont think it would take too much to support just pure FXG.
 In
> > fact, that is what I started with.  Now I am adding more Flex
constructs on
> > top of it.  But the XSLT right now only supports the "s:" namespace.  It
> > shouldnt be hard to support the fxg namespace as well.
> >
> > Thanks,
> > Om
> >
> >
> >>
> >>
> >> On 3/25/13 3:18 PM, "Om" <bigosma...@gmail.com> wrote:
> >>
> >>> On Mon, Mar 25, 2013 at 12:26 PM, Alex Harui <aha...@adobe.com> wrote:
> >>>
> >>>> Om, can you give an example?
> >>>>
> >>>> IMO, there is a difference between MXML Graphics and FXG.  To me,
FXG is
> >>>> stuff in an FXG file exported from several Adobe design tools.  The
> >>>> internal
> >>>> pieces are not manipulated at run time.  Today, FXG assets are
compiled
> >>>> into
> >>>> Sprites and other SWF primitives.
> >>>>
> >>>
> >>> You are right, I am mixing my terms FXG and MXMLG when I speak.  My
> >>> workflow when working with FXG is more like this [1]  Which really is
> >> just
> >>> changing the namespace from FXG namespace to Spark namespace.  Which
is
> >> why
> >>> the confusion, I guess.  But to make it clear, I am less worried about
> >>> about bringing FXG documents as graphic primitives into the HTML5/JS
> >> space.
> >>>  That would be nice, but not worth much.
> >>>
> >>> Here is a concrete example
> >>> from \frameworks\projects\spark\src\spark\skins\spark\ButtonSkin.mxml
> >>>
> >>> <snip>
> >>>     <!-- layer 1: shadow -->
> >>>     <!--- @private -->
> >>>     <s:Rect id="shadow" left="-1" right="-1" top="-1" bottom="-1"
> >>> radiusX="2">
> >>>         <s:fill>
> >>>             <s:LinearGradient rotation="90">
> >>>                 <s:GradientEntry color="0x000000"
> >>>                                  color.down="0xFFFFFF"
> >>>                                  alpha="0.01"
> >>>                                  alpha.down="0" />
> >>>                 <s:GradientEntry color="0x000000"
> >>>                                  color.down="0xFFFFFF"
> >>>                                  alpha="0.07"
> >>>                                  alpha.down="0.5" />
> >>>             </s:LinearGradient>
> >>>         </s:fill>
> >>>     </s:Rect>
> >>> </snip>
> >>>
> >>> This specifies an FXG Rect element with the attribute radiusX.  So
far so
> >>> good.  But the left, right, bottom and top are not part of the FXG
spec
> >> [2]
> >>>  They are implemented as part of the ILayoutElement that one of the
> >>> ancestors of s:Rect i.e. GraphicElement class.
> >>>
> >>> The way I am approaching is to make it a combination of SVG and CSS.
> >>  This
> >>> means that I can translate FXG's @radiusX into SVG's @rx.  And I can
> >>> translate MXMLG's @top into style="position:relative; top=-1"
> >>>
> >>> Is this the kind of example you wanted?  I can go into more detail on
my
> >>> approach if you want.  Let me know.
> >>>
> >>> Thanks,
> >>> Om
> >>>
> >>> [1]
> >>>
> >>
>
http://help.adobe.com/en_US/flex/using/WSda78ed3a750d6b8f26c150d412357de3591-
>>
> 8
> >>> 000.html#WSDAD87261-09E9-4091-8169-F2758607F125
> >>> [2]
http://sourceforge.net/adobe/flexsdk/wiki/FXG%202.0%20Specification/
> >>>
> >>>
> >>>>
> >>>> MXML Graphics in a skin are generally there for manipulation.  The
> >>>> top-level
> >>>> tag is some component class.  I think in FlexJS, I would suggest just
> >>>> writing components for Rect, Path, etc, so they can also be
manipulated
> >> at
> >>>> runtime.
> >>>>
> >>>>
> >>>> On 3/25/13 12:15 PM, "Om" <bigosma...@gmail.com> wrote:
> >>>>
> >>>>> On Mon, Mar 25, 2013 at 11:55 AM, Erik de Bruin <e...@ixsoftware.nl>
> >>>> wrote:
> >>>>>
> >>>>>> Om,
> >>>>>>
> >>>>>> 1) the wiki is mostly current, but as a work in progress: if it
> >>>>>> doesn't work, ask and we will fix ;-)
> >>>>>>
> >>>>>> 2) CSS resulting from...? I'm not familiar with FXG etc., so my
> >>>>>> questions are bound to be naive as well, as you'll notice.
Basically
> >>>>>> we have access to whatever the compiler (Falcon-main, if you will)
has
> >>>>>> access to, but some thing might be easier than others. Mike S. is
our
> >>>>>> wizard, he'll know what to do if we can't figure it out.
> >>>>>>
> >>>>>
> >>>>> Just to be clear, for all practical purposes, when I say FXG, I
really
> >>>> mean
> >>>>> MXML.  This is because, the Flex implementation of FXG ensures that
FXG
> >>>>> elements can be pluggable inline into any MXML component.  So, if we
> >> are
> >>>> to
> >>>>> support MXML, then we must support FXG.
> >>>>>
> >>>>> In what I am doing currently, I am actually processing an MXML file,
> >>>> ignore
> >>>>> things that I dont care about (like fx:Script, fx:Metadata, and any
> >>>>> non-visual component)
> >>>>>
> >>>>> It just happens that for Spark components, the FXG elements appear
only
> >>>> in
> >>>>> their Spark skins.  This makes my job easier because if I target
only
> >> the
> >>>>> spark skins, I wont have to deal with a lot of other MXML functional
> >>>> (i.e.
> >>>>> non view) elements.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> 3) Ah, there is the CSS, I guess (fxg -> svg + css). The AS code
will
> >>>>>> be cross-compiled to AS (weird, I know) or any form of JS we chose,
> >>>>>> most likely 'goog' JS, as it will have to be compatible with FlexJS
> >>>>>> and the VanillaSDK. Due to the way FalconJx is set up, it will be
easy
> >>>>>> to add FXG specific JS parsing, if needed.
> >>>>>>
> >>>>>
> >>>>> What if I want to handcode some javascript?  For example, if I want
to
> >>>>> support the current 'states' paradigm used in spark skins, I need to
> >>>> write
> >>>>> some javascript to make it a reusable component.  I am not sure if
this
> >>>> is
> >>>>> the right approach, though.  What do you guys think?
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> 4) Sounds like and excellent starting point... however, you'll
> >>>>>> probably have to tweak your local SDK 'a bit' to get both the Flex
and
> >>>>>> JS side working.  Or should be start one of those much rumored
> >>>>>> 'shared' feature branches of the SDK?
> >>>>>>
> >>>>>
> >>>>> What kind of tweaking do you mean?  Actually, I dont understand
> >> anything
> >>>>> you just said.  Please explain like I am 5 years old :-)
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> I love how everything seems to be converging and it really feels
like
> >>>>>> Flex -> HTML5/JS is doable!
> >>>>>>
> >>>>>
> >>>>> Cautious optimism abounds!
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> EdB
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Mar 25, 2013 at 7:21 PM, Om <bigosma...@gmail.com> wrote:
> >>>>>>> Erik,
> >>>>>>>
> >>>>>>> I am planning to get FalconJX working on my machine soon.  Before
I
> >>>> start
> >>>>>>> digging into it,
> >>>>>>>
> >>>>>>> 1. Are these wiki pages current?
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
https://cwiki.apache.org/confluence/display/FLEX/AS+to+JS+-+the+%27goog%27+Wa
> >>>>>>
> >>>> y
> >>>>>>>
> >>>>>>>
https://cwiki.apache.org/confluence/display/FLEX/FalconJx+Prototype
> >>>>>>>
> >>>>>>> 2.  Do you have any thoughts on how we want to handle the
resulting
> >>>> CSS?
> >>>>>>>  Inlining everything or have it as separate files?
> >>>>>>>
> >>>>>>> 3.  My approach would take in a spark skin file and convert the
fxg
> >>>>>>> elements into svg+css.  There is going to some AS code that needs
to
> >> be
> >>>>>>> converted JS.  I believe your approach already handles this right?
> >>>>>>>
> >>>>>>> 4.  I see that the VanillaSDK supports the Button component in
HTML5.
> >>>>>>>  Maybe that is where I should start and get my code working there?
> >>>>>>>
> >>>>>>> Sorry if I am asking naive questions, but I am looking for some
> >>>> guidance
> >>>>>> on
> >>>>>>> how to get my work integrated into FalconJx (or FalconJS)
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Om
> >>>>>>>
> >>>>>>> On Mon, Mar 25, 2013 at 8:45 AM, Erik de Bruin <e...@ixsoftware.nl
>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Just 'checking in': FalconJx can now compile the FlexJSTest_again
> >>>>>>>> example from the command line, using these arguments:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
+env.PLAYERGLOBAL_HOME=/Users/erik/Documents/ApacheFlex/dependencies/PlayerGl
> >>>>>> obal/player
> >>>>>>>> +playerglobal.version=11.1
> >>>>>>>> -load-config="/Applications/Adobe Flash Builder
> >>>>>>>> 4.7/sdks/4.9.1/frameworks/flex-config.xml"
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
-library-path+=/Users/erik/Documents/ApacheFlex/git/flex-asjs/frameworks/as/l
> >>>>>> ibs/FlexJSUI.swc
> >>>>>>>> -js-output-type=FLEXJS
> >>>>>>>> -output=/Users/erik/Desktop/FlexJS/fromEclipse/FlexJSTest.js
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
/Users/erik/Documents/ApacheFlex/git/flex-asjs/examples/FlexJSTest_again/src/
> >>>>>> FlexJSTest.mxml
> >>>>>>>>
> >>>>>>>> Well, not exactly those, please change the paths to fit your
local
> >>>>>>>> environment ;-)
> >>>>>>>>
> >>>>>>>> Next up:
> >>>>>>>> - support for publishing with the GCC and associated tricks
> >> (SourceMap
> >>>>>>>> etc.)
> >>>>>>>> - full FlexJS type AS -> JS support (the current implementation
is
> >>>>>>>> custom tailored to the FlexJSTest_Again example code)
> >>>>>>>>
> >>>>>>>> Have fun!
> >>>>>>>>
> >>>>>>>> EdB
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Ix Multimedia Software
> >>>>>>>>
> >>>>>>>> Jan Luykenstraat 27
> >>>>>>>> 3521 VB Utrecht
> >>>>>>>>
> >>>>>>>> T. 06-51952295
> >>>>>>>> I. www.ixsoftware.nl
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Ix Multimedia Software
> >>>>>>
> >>>>>> Jan Luykenstraat 27
> >>>>>> 3521 VB Utrecht
> >>>>>>
> >>>>>> T. 06-51952295
> >>>>>> I. www.ixsoftware.nl
> >>>>>>
> >>>>
> >>>> --
> >>>> Alex Harui
> >>>> Flex SDK Team
> >>>> Adobe Systems, Inc.
> >>>> http://blogs.adobe.com/aharui
> >>>>
> >>>>
> >>
> >> --
> >> Alex Harui
> >> Flex SDK Team
> >> Adobe Systems, Inc.
> >> http://blogs.adobe.com/aharui
> >>
> >>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>

Reply via email to