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