You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Om <bi...@gmail.com> on 2013/03/15 12:03:40 UTC
FXG to SVG - working example
I quickly whipped up a proof of concept proving the FXG to SVG
interoperability.
The working demo can be found here:
http://people.apache.org/~bigosmallm/fxg2svg/svg.html (Tested to be working
fine on Chrome 25, Firefox 19 and IE 10 on Windows)
I did not have time to write a stylesheet, so I hand created a simple SVG
element based on an FXG element. I chose the most basic element: "Rect"
which is available as "rect" in SVG. Once I had the basic set up working,
all I had to do was modify the svg's attributes using Javascript. This
happens during runtime, but we could totally move this to the compilation
stage.
As you can see, I have proven that rendering fidelity can be achieved using
this route. At the same time, this can be plugged into the AS to JS
translation piece that Mike, Erik, et al. are working on. From what I see
in that project, there is no faithful rendering solution (yet) You
probably discussed about rendering that I might have missed.
When I get some more time, I will start fiddling with more and more FXG
elements and see how SVG handles them. At some point, writing a stylesheet
would be more efficient.
Just right click either the Flex app or the HTML content to view the source
of both. Comments and suggestions for improvement highly appreciated.
This is a very basic demo, dealing mostly about rendering fidelity. But
IMHO, this unleashes a ton of possibilities.
(And no, FXG is not dead - yet. ;-) )
Thanks,
Om
Re: FXG to SVG - working example
Posted by Erik de Bruin <er...@ixsoftware.nl>.
My iPhone 5 shows the red square with rounded corner, text above it
and within it and an onclick alert.
EdB
On Fri, Mar 15, 2013 at 1:01 PM, Om <bi...@gmail.com> wrote:
> BTW, the html svg part works fine on the Android browser as well, with
> exactly the same look and feel as the Flex app!
>
> Can someone test on an iOS device, please?
>
> Thanks,
> Om
> On Mar 15, 2013 4:03 AM, "Om" <bi...@gmail.com> wrote:
>
>> I quickly whipped up a proof of concept proving the FXG to SVG
>> interoperability.
>>
>> The working demo can be found here:
>> http://people.apache.org/~bigosmallm/fxg2svg/svg.html (Tested to be
>> working fine on Chrome 25, Firefox 19 and IE 10 on Windows)
>>
>> I did not have time to write a stylesheet, so I hand created a simple SVG
>> element based on an FXG element. I chose the most basic element: "Rect"
>> which is available as "rect" in SVG. Once I had the basic set up working,
>> all I had to do was modify the svg's attributes using Javascript. This
>> happens during runtime, but we could totally move this to the compilation
>> stage.
>>
>> As you can see, I have proven that rendering fidelity can be achieved
>> using this route. At the same time, this can be plugged into the AS to JS
>> translation piece that Mike, Erik, et al. are working on. From what I see
>> in that project, there is no faithful rendering solution (yet) You
>> probably discussed about rendering that I might have missed.
>>
>> When I get some more time, I will start fiddling with more and more FXG
>> elements and see how SVG handles them. At some point, writing a stylesheet
>> would be more efficient.
>>
>> Just right click either the Flex app or the HTML content to view the
>> source of both. Comments and suggestions for improvement highly
>> appreciated. This is a very basic demo, dealing mostly about rendering
>> fidelity. But IMHO, this unleashes a ton of possibilities.
>>
>> (And no, FXG is not dead - yet. ;-) )
>>
>> Thanks,
>> Om
>>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FXG to SVG - working example
Posted by Om <bi...@gmail.com>.
BTW, the html svg part works fine on the Android browser as well, with
exactly the same look and feel as the Flex app!
Can someone test on an iOS device, please?
Thanks,
Om
On Mar 15, 2013 4:03 AM, "Om" <bi...@gmail.com> wrote:
> I quickly whipped up a proof of concept proving the FXG to SVG
> interoperability.
>
> The working demo can be found here:
> http://people.apache.org/~bigosmallm/fxg2svg/svg.html (Tested to be
> working fine on Chrome 25, Firefox 19 and IE 10 on Windows)
>
> I did not have time to write a stylesheet, so I hand created a simple SVG
> element based on an FXG element. I chose the most basic element: "Rect"
> which is available as "rect" in SVG. Once I had the basic set up working,
> all I had to do was modify the svg's attributes using Javascript. This
> happens during runtime, but we could totally move this to the compilation
> stage.
>
> As you can see, I have proven that rendering fidelity can be achieved
> using this route. At the same time, this can be plugged into the AS to JS
> translation piece that Mike, Erik, et al. are working on. From what I see
> in that project, there is no faithful rendering solution (yet) You
> probably discussed about rendering that I might have missed.
>
> When I get some more time, I will start fiddling with more and more FXG
> elements and see how SVG handles them. At some point, writing a stylesheet
> would be more efficient.
>
> Just right click either the Flex app or the HTML content to view the
> source of both. Comments and suggestions for improvement highly
> appreciated. This is a very basic demo, dealing mostly about rendering
> fidelity. But IMHO, this unleashes a ton of possibilities.
>
> (And no, FXG is not dead - yet. ;-) )
>
> Thanks,
> Om
>
Re: FXG to SVG - working example
Posted by Om <bi...@gmail.com>.
On Fri, Mar 15, 2013 at 8:22 AM, Alex Harui <ah...@adobe.com> wrote:
> FWIW, Peter and I are pretty much done with the basic set of unstyleable,
> unskinnable HTML4 components. Peter and I were going to work on styleable
> HTML4 components next then tackle HTML5 and bitmap skinning, but maybe we
> should jump to wrapping the HTML5 components so you can try getting your
> skinning model to work on them.
>
>
Sounds exciting. I am in! I can help as much as I can.
Thanks,
Om
>
> On 3/15/13 4:16 AM, "Om" <bi...@gmail.com> wrote:
>
> > On Fri, Mar 15, 2013 at 4:11 AM, Michael Schmalle
> > <ap...@teotigraphix.com>wrote:
> >
> >> Om,
> >>
> >> At this point and time, I am not worried about rendering. I am more
> >> concerned about straight business logic getting cross compiled.
> >>
> >>
> > I am worried about it and hence scratching my itch :-) I have not seen
> any
> > proposal better than mine so far.
> >
> >
> >> This is probably why you have heard anything, I talk a lot on this forum
> >> and haven't said anything about it. :)
> >>
> >> I don't even own up to date Adobe programs that even export FXG, I
> think I
> >> have CS3, and love it. I think giving the View to web developers using
> HTML
> >> and CSS should be explored by this group as well, instead of relying on
> >> cross compiling views.
> >>
> >
> > My goal is to have a solution that does not make the user touch HTML, JS
> or
> > CSS. The current workflow we have with Flex + FXG is far superior than
> > anything out there. I am just trying to see how to keep these workflows
> > going forward but still support cross compilation.
> >
> >
> >>
> >> Mike
> >>
> >>
> >>
> >> Quoting Om <bi...@gmail.com>:
> >>
> >> I quickly whipped up a proof of concept proving the FXG to SVG
> >>> interoperability.
> >>>
> >>> The working demo can be found here:
> >>> http://people.apache.org/~**bigosmallm/fxg2svg/svg.html<
> http://people.apache
> >>> .org/~bigosmallm/fxg2svg/svg.html>(Tested to be working
> >>> fine on Chrome 25, Firefox 19 and IE 10 on Windows)
> >>>
> >>> I did not have time to write a stylesheet, so I hand created a simple
> SVG
> >>> element based on an FXG element. I chose the most basic element:
> "Rect"
> >>> which is available as "rect" in SVG. Once I had the basic set up
> working,
> >>> all I had to do was modify the svg's attributes using Javascript. This
> >>> happens during runtime, but we could totally move this to the
> compilation
> >>> stage.
> >>>
> >>> As you can see, I have proven that rendering fidelity can be achieved
> >>> using
> >>> this route. At the same time, this can be plugged into the AS to JS
> >>> translation piece that Mike, Erik, et al. are working on. From what I
> see
> >>> in that project, there is no faithful rendering solution (yet) You
> >>> probably discussed about rendering that I might have missed.
> >>>
> >>> When I get some more time, I will start fiddling with more and more FXG
> >>> elements and see how SVG handles them. At some point, writing a
> >>> stylesheet
> >>> would be more efficient.
> >>>
> >>> Just right click either the Flex app or the HTML content to view the
> >>> source
> >>> of both. Comments and suggestions for improvement highly appreciated.
> >>> This is a very basic demo, dealing mostly about rendering fidelity. But
> >>> IMHO, this unleashes a ton of possibilities.
> >>>
> >>> (And no, FXG is not dead - yet. ;-) )
> >>>
> >>> Thanks,
> >>> Om
> >>>
> >>>
> >> --
> >> Michael Schmalle - Teoti Graphix, LLC
> >> http://www.teotigraphix.com
> >> http://blog.teotigraphix.com
> >>
> >>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: FXG to SVG - working example
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Right,
And this is why I wrote another compiler for as to js. Try doing what
you want with the FalconJS code base, good luck, if you can I salute
you.
Don't take what I said as arrogance, I am saying I am a framework
architect, I can't concern myself with what you are worried about. I
have no opinion on it (UI wise), since its not my cup of tea. I see
flaws in trying to compile things to HTML5/JS considering I am the
one(of 2) writing the compiler.
Mike
Quoting Om <bi...@gmail.com>:
> On Fri, Mar 15, 2013 at 4:11 AM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> Om,
>>
>> At this point and time, I am not worried about rendering. I am more
>> concerned about straight business logic getting cross compiled.
>>
>>
> I am worried about it and hence scratching my itch :-) I have not seen any
> proposal better than mine so far.
>
>
>> This is probably why you have heard anything, I talk a lot on this forum
>> and haven't said anything about it. :)
>>
>> I don't even own up to date Adobe programs that even export FXG, I think I
>> have CS3, and love it. I think giving the View to web developers using HTML
>> and CSS should be explored by this group as well, instead of relying on
>> cross compiling views.
>>
>
> My goal is to have a solution that does not make the user touch HTML, JS or
> CSS. The current workflow we have with Flex + FXG is far superior than
> anything out there. I am just trying to see how to keep these workflows
> going forward but still support cross compilation.
>
>
>>
>> Mike
>>
>>
>>
>> Quoting Om <bi...@gmail.com>:
>>
>> I quickly whipped up a proof of concept proving the FXG to SVG
>>> interoperability.
>>>
>>> The working demo can be found here:
>>> http://people.apache.org/~**bigosmallm/fxg2svg/svg.html<http://people.apache.org/~bigosmallm/fxg2svg/svg.html>(Tested to be
>>> working
>>> fine on Chrome 25, Firefox 19 and IE 10 on Windows)
>>>
>>> I did not have time to write a stylesheet, so I hand created a simple SVG
>>> element based on an FXG element. I chose the most basic element: "Rect"
>>> which is available as "rect" in SVG. Once I had the basic set up working,
>>> all I had to do was modify the svg's attributes using Javascript. This
>>> happens during runtime, but we could totally move this to the compilation
>>> stage.
>>>
>>> As you can see, I have proven that rendering fidelity can be achieved
>>> using
>>> this route. At the same time, this can be plugged into the AS to JS
>>> translation piece that Mike, Erik, et al. are working on. From what I see
>>> in that project, there is no faithful rendering solution (yet) You
>>> probably discussed about rendering that I might have missed.
>>>
>>> When I get some more time, I will start fiddling with more and more FXG
>>> elements and see how SVG handles them. At some point, writing a
>>> stylesheet
>>> would be more efficient.
>>>
>>> Just right click either the Flex app or the HTML content to view the
>>> source
>>> of both. Comments and suggestions for improvement highly appreciated.
>>> This is a very basic demo, dealing mostly about rendering fidelity. But
>>> IMHO, this unleashes a ton of possibilities.
>>>
>>> (And no, FXG is not dead - yet. ;-) )
>>>
>>> Thanks,
>>> Om
>>>
>>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: FXG to SVG - working example
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Om <bi...@gmail.com>:
> On Fri, Mar 15, 2013 at 8:31 AM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> BTW,
>>
>> When I say I am not interested in the view cross compilation... All that
>> means is that I am saying don't wait for me to implement any of it. I am
>> being very direct in what my goals are with FlaconJx anyways, I just wanted
>> something that would cross compile actionscript to a multiple output
>> possibilities. This allows others as Erik is proving to do what they need
>> with the end product.
>>
>>
> Thanks for clarifying, Mike. I really want to play along with what good
> work you folks have been doing. I dont think I can sustain starting a new
> top-down approach on my own.
Well if you did, you would have the traversing, emitters and compiler
to write. :) It ain't no small task. Understanding how Falcon parses
and uses FutureTasks etc, takes a but of time to get the feet wet.
I am sure in the future, I will have time to share my experience with
others about the lower level of the compiler so we can fix things if
the need arises.
> Om
>
>
>> My days of flex components are over, thank goodness. :)
>>
>
> I've ready your old blog posts. Lets see :-)
>
Ha, I think I get your joke, yeah well 8 years of ui component dev
killed me. :)
Mike
>>
>> Mike
>>
>>
>>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>> FWIW, Peter and I are pretty much done with the basic set of unstyleable,
>>> unskinnable HTML4 components. Peter and I were going to work on styleable
>>> HTML4 components next then tackle HTML5 and bitmap skinning, but maybe we
>>> should jump to wrapping the HTML5 components so you can try getting your
>>> skinning model to work on them.
>>>
>>>
>>> On 3/15/13 4:16 AM, "Om" <bi...@gmail.com> wrote:
>>>
>>> On Fri, Mar 15, 2013 at 4:11 AM, Michael Schmalle
>>>> <ap...@teotigraphix.com>**wrote:
>>>>
>>>> Om,
>>>>>
>>>>> At this point and time, I am not worried about rendering. I am more
>>>>> concerned about straight business logic getting cross compiled.
>>>>>
>>>>>
>>>>> I am worried about it and hence scratching my itch :-) I have not
>>>> seen any
>>>> proposal better than mine so far.
>>>>
>>>>
>>>> This is probably why you have heard anything, I talk a lot on this forum
>>>>> and haven't said anything about it. :)
>>>>>
>>>>> I don't even own up to date Adobe programs that even export FXG, I
>>>>> think I
>>>>> have CS3, and love it. I think giving the View to web developers using
>>>>> HTML
>>>>> and CSS should be explored by this group as well, instead of relying on
>>>>> cross compiling views.
>>>>>
>>>>>
>>>> My goal is to have a solution that does not make the user touch HTML, JS
>>>> or
>>>> CSS. The current workflow we have with Flex + FXG is far superior than
>>>> anything out there. I am just trying to see how to keep these workflows
>>>> going forward but still support cross compilation.
>>>>
>>>>
>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>> Quoting Om <bi...@gmail.com>:
>>>>>
>>>>> I quickly whipped up a proof of concept proving the FXG to SVG
>>>>>
>>>>>> interoperability.
>>>>>>
>>>>>> The working demo can be found here:
>>>>>> http://people.apache.org/~****bigosmallm/fxg2svg/svg.html<http://people.apache.org/~**bigosmallm/fxg2svg/svg.html>
>>>>>> <ht**tp://people.apache <http://people.apache>
>>>>>> .org/~bigosmallm/fxg2svg/svg.**html>(Tested to be working
>>>>>> fine on Chrome 25, Firefox 19 and IE 10 on Windows)
>>>>>>
>>>>>> I did not have time to write a stylesheet, so I hand created a simple
>>>>>> SVG
>>>>>> element based on an FXG element. I chose the most basic element:
>>>>>> "Rect"
>>>>>> which is available as "rect" in SVG. Once I had the basic set up
>>>>>> working,
>>>>>> all I had to do was modify the svg's attributes using Javascript. This
>>>>>> happens during runtime, but we could totally move this to the
>>>>>> compilation
>>>>>> stage.
>>>>>>
>>>>>> As you can see, I have proven that rendering fidelity can be achieved
>>>>>> using
>>>>>> this route. At the same time, this can be plugged into the AS to JS
>>>>>> translation piece that Mike, Erik, et al. are working on. From what I
>>>>>> see
>>>>>> in that project, there is no faithful rendering solution (yet) You
>>>>>> probably discussed about rendering that I might have missed.
>>>>>>
>>>>>> When I get some more time, I will start fiddling with more and more FXG
>>>>>> elements and see how SVG handles them. At some point, writing a
>>>>>> stylesheet
>>>>>> would be more efficient.
>>>>>>
>>>>>> Just right click either the Flex app or the HTML content to view the
>>>>>> source
>>>>>> of both. Comments and suggestions for improvement highly appreciated.
>>>>>> This is a very basic demo, dealing mostly about rendering fidelity. But
>>>>>> IMHO, this unleashes a ton of possibilities.
>>>>>>
>>>>>> (And no, FXG is not dead - yet. ;-) )
>>>>>>
>>>>>> Thanks,
>>>>>> Om
>>>>>>
>>>>>>
>>>>>> --
>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>> http://www.teotigraphix.com
>>>>> http://blog.teotigraphix.com
>>>>>
>>>>>
>>>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: FXG to SVG - working example
Posted by Om <bi...@gmail.com>.
On Fri, Mar 15, 2013 at 8:31 AM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> BTW,
>
> When I say I am not interested in the view cross compilation... All that
> means is that I am saying don't wait for me to implement any of it. I am
> being very direct in what my goals are with FlaconJx anyways, I just wanted
> something that would cross compile actionscript to a multiple output
> possibilities. This allows others as Erik is proving to do what they need
> with the end product.
>
>
Thanks for clarifying, Mike. I really want to play along with what good
work you folks have been doing. I dont think I can sustain starting a new
top-down approach on my own.
Om
> My days of flex components are over, thank goodness. :)
>
I've ready your old blog posts. Lets see :-)
>
> Mike
>
>
>
> Quoting Alex Harui <ah...@adobe.com>:
>
> FWIW, Peter and I are pretty much done with the basic set of unstyleable,
>> unskinnable HTML4 components. Peter and I were going to work on styleable
>> HTML4 components next then tackle HTML5 and bitmap skinning, but maybe we
>> should jump to wrapping the HTML5 components so you can try getting your
>> skinning model to work on them.
>>
>>
>> On 3/15/13 4:16 AM, "Om" <bi...@gmail.com> wrote:
>>
>> On Fri, Mar 15, 2013 at 4:11 AM, Michael Schmalle
>>> <ap...@teotigraphix.com>**wrote:
>>>
>>> Om,
>>>>
>>>> At this point and time, I am not worried about rendering. I am more
>>>> concerned about straight business logic getting cross compiled.
>>>>
>>>>
>>>> I am worried about it and hence scratching my itch :-) I have not
>>> seen any
>>> proposal better than mine so far.
>>>
>>>
>>> This is probably why you have heard anything, I talk a lot on this forum
>>>> and haven't said anything about it. :)
>>>>
>>>> I don't even own up to date Adobe programs that even export FXG, I
>>>> think I
>>>> have CS3, and love it. I think giving the View to web developers using
>>>> HTML
>>>> and CSS should be explored by this group as well, instead of relying on
>>>> cross compiling views.
>>>>
>>>>
>>> My goal is to have a solution that does not make the user touch HTML, JS
>>> or
>>> CSS. The current workflow we have with Flex + FXG is far superior than
>>> anything out there. I am just trying to see how to keep these workflows
>>> going forward but still support cross compilation.
>>>
>>>
>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>> Quoting Om <bi...@gmail.com>:
>>>>
>>>> I quickly whipped up a proof of concept proving the FXG to SVG
>>>>
>>>>> interoperability.
>>>>>
>>>>> The working demo can be found here:
>>>>> http://people.apache.org/~****bigosmallm/fxg2svg/svg.html<http://people.apache.org/~**bigosmallm/fxg2svg/svg.html>
>>>>> <ht**tp://people.apache <http://people.apache>
>>>>> .org/~bigosmallm/fxg2svg/svg.**html>(Tested to be working
>>>>> fine on Chrome 25, Firefox 19 and IE 10 on Windows)
>>>>>
>>>>> I did not have time to write a stylesheet, so I hand created a simple
>>>>> SVG
>>>>> element based on an FXG element. I chose the most basic element:
>>>>> "Rect"
>>>>> which is available as "rect" in SVG. Once I had the basic set up
>>>>> working,
>>>>> all I had to do was modify the svg's attributes using Javascript. This
>>>>> happens during runtime, but we could totally move this to the
>>>>> compilation
>>>>> stage.
>>>>>
>>>>> As you can see, I have proven that rendering fidelity can be achieved
>>>>> using
>>>>> this route. At the same time, this can be plugged into the AS to JS
>>>>> translation piece that Mike, Erik, et al. are working on. From what I
>>>>> see
>>>>> in that project, there is no faithful rendering solution (yet) You
>>>>> probably discussed about rendering that I might have missed.
>>>>>
>>>>> When I get some more time, I will start fiddling with more and more FXG
>>>>> elements and see how SVG handles them. At some point, writing a
>>>>> stylesheet
>>>>> would be more efficient.
>>>>>
>>>>> Just right click either the Flex app or the HTML content to view the
>>>>> source
>>>>> of both. Comments and suggestions for improvement highly appreciated.
>>>>> This is a very basic demo, dealing mostly about rendering fidelity. But
>>>>> IMHO, this unleashes a ton of possibilities.
>>>>>
>>>>> (And no, FXG is not dead - yet. ;-) )
>>>>>
>>>>> Thanks,
>>>>> Om
>>>>>
>>>>>
>>>>> --
>>>> Michael Schmalle - Teoti Graphix, LLC
>>>> http://www.teotigraphix.com
>>>> http://blog.teotigraphix.com
>>>>
>>>>
>>>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
Re: FXG to SVG - working example
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I'll leave the question on how much FalconJx is different from
FalconJS - and if you can "just copy" stuff over - to Mike. I'm just
the guy who copy-pastes (?) bits of code around and tries to look cool
doing it.
Mike?
EdB
On Fri, Mar 15, 2013 at 9:03 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 3/15/13 12:56 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>> don't believe that any of the work I am doing is wasted. FalconJS is not
>>> the competition, it is just a stop-gap place for me to experiment until
>>> FalconJX catches up.
>>
>> Ok, I wrote too long a statement (as ususal). The TL;DR version is: if
>> you continue to work on FalconJS, I won't be able to keep up on the
>> FalconJx side.
>>
> My point is that there is nothing to keep up with. All the work I'm doing
> is not in the MXML emitter work you are doing and should just copy over,
> unless you and Mike have done major surgery to the rest of Falcon.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FXG to SVG - working example
Posted by Daniel Freeman <ma...@gmail.com>.
Sorry, I read this thread too quickly, and without thinking. FXG -> SVG.
I was talking about going in the other direction. Parsing and displaying
SVG or FXG in Flash (Dynamically, at run time). Nevertheless, if someone
is interested in that - you may find my comment useful.
On Sat, Mar 23, 2013 at 11:39 AM, Daniel Freeman <ma...@gmail.com>wrote:
> I wrote one of those. I wrote SVG -> AS3 graphics. And extending that
> class, I wrote FXG -> AS3 graphics.
>
> It wasn't a complete implementation of the SVG or FXG standards. It
> didn't handle text, and complex gradients weren't perfect. The FXG class
> was based on Adobe's first FXG definition. But it worked pretty well.
>
> This was one of the features of the applications I offered to donate.
>
> Actually, if you go back to build r53 of extendedMadness. SVG was in
> there. I took it out, because I didn't think too may people would be
> interested - and to reduce the bloat. (I didn't want my Framework getting
> like Flex - did I),
>
> http://code.google.com/p/mad-components/source/detail?r=53#
>
> See example here:
> http://code.google.com/p/mad-components/source/browse/trunk/MadComponentStuff/src/MadComponentsDesktop.as?spec=svn53&r=53
>
> FXG isn't too different from SVG.
>
>
> ... I've mentioned this before, but I'd like to relinquish control a
> little over maintaining MadComponents, ExtendedMadness, and MC3D. I've
> offered before to donate them to this Apache group.
>
> Bear in mind that people aren't using Flex to build mobile apps. They're
> using MadComponents (General Purpose / Enterprise) or Feathers (Game UI).
> In fact, I've had clients engage my freelance services because they tried
> to build a mobile app using bloated Flex - and regretted it.
>
>
> http://madskool.wordpress.com/2012/01/23/why-developers-are-using-madcomponents/
>
> Is there any interest in this group in MadComponents?
>
>
> On Sat, Mar 16, 2013 at 4:01 AM, Michael Schmalle <apache@teotigraphix.com
> > wrote:
>
>>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>> In my simple mind, Falcon generates the AST then at some point in time
>>> the
>>> futures task for that compilation unit is asked for output. Current
>>> Falcon
>>> code calls the BURM which eventually calls an emitter, I'm assuming
>>> FalconJX
>>> does an AST tree walk instead of calling the BURM. There is no
>>> reduction,
>>> just emitting. CSS for JS is probably just going emit text from the
>>> tree.
>>>
>>
>> Yes this is correct basically.
>>
>> Each compilation unit implements its own handleASBRequest() that gets
>> called during a generator request. This request ONLY happens AFTER the
>> handle AST and Scope requests have been processed.
>>
>> Its very complicated below that principle because of the future tasks and
>> outgoing dependency requests that trigger other files to be parsed, scopes
>> built etc.
>>
>> THe framework is elegant. The only thing I wish I could tear out and
>> abstract is how they have SWF baked into ITarget and Target.
>>
>> This really makes it hard to do what we are doing without all this
>> "baggage".
>>
>> As I said, parsing is multithreaded right now in FalconJx, I can easily
>> get the source code generation multithreaded to now that I have learned how
>> the framework wheels move together.
>>
>> I'm just not at the point to worry to much about it at the moment because
>> in a couple of my test projects, the compiler is wicked fast, I also have
>> an implementation that uses the Workspace and only loads config once, which
>> is using the framework like and IDE does...
>>
>> Mike
>>
>>
>>
>>
>>> On 3/15/13 1:44 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>>
>>> BTW,
>>>>
>>>> I have not seen one thing that you are asking for that doesn't contain
>>>> an AST and node framework in the Falcon package.
>>>>
>>>> If it was me, I would create all the emitters exactly the same way be
>>>> parsing the file, handling the AST, traversing it while outputting to
>>>> the target, then writing it in its file format.
>>>>
>>>> Its simple and I guess the FalconJx framework is mainly due to me
>>>> dealing with inheritance and dependency madness with Flex components
>>>> for years. I said all my future projects will use composition, this
>>>> one does big time.
>>>>
>>>> Mike
>>>>
>>>> Quoting Michael Schmalle <ap...@teotigraphix.com>:
>>>>
>>>>
>>>>> Quoting Alex Harui <ah...@adobe.com>:
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/15/13 1:14 PM, "Michael Schmalle" <ap...@teotigraphix.com>
>>>>>> wrote:
>>>>>>
>>>>>> The problem is, SWF is so
>>>>>>> interconnected in the generator packages that you might have a
>>>>>>> problem
>>>>>>> getting a polarity with using the BURM.
>>>>>>>
>>>>>> Don't know what "polarity" meant, but hopefully it doesn't really
>>>>>> matter.
>>>>>>
>>>>>
>>>>> Bad word, I meant polarity in emitters as what the BURM generators
>>>>> offer right now with FalconJS, properties, css, as, mxml.
>>>>>
>>>>>
>>>>> On that note; This would take more study to fully understand, but at
>>>>>>> the moment I don't have time to investigate. I guess you will have to
>>>>>>> weigh the options or get a "feel" for the Falcon framework when your
>>>>>>> not under as much of a timeline/deadline?
>>>>>>>
>>>>>>> That being said, the FalconJx framework was meant to be created in
>>>>>>> component sections, so if your end goal is to create things with it
>>>>>>> fully, I would suggest things being ported to its emitter, or it will
>>>>>>> for ever have a crutch on SWF.
>>>>>>>
>>>>>>> Good point about the generators being tied to SWF constructs. But
>>>>>> I am
>>>>>> assuming you that, in order to service different file types we will
>>>>>> have
>>>>>> several emitters? One for AS, one for MXML/AS? I think I will
>>>>>> create one
>>>>>> for CSS and someone will create one for FXG->SVG? And since these two
>>>>>> probably won't generate JS "classes", I think they won't be tied to
>>>>>> the SWF
>>>>>> constructs in the generator and thus will copy over "easily".
>>>>>>
>>>>>
>>>>> Right, if I was getting paid for this stuff, I could have most of it
>>>>> done in a month or two, so using the pattern I have created with
>>>>> FalconJx all your emitters with file handlers are possible.
>>>>>
>>>>> To realize what you need Alex, the knife is already built, its just
>>>>> adding the blades.
>>>>>
>>>>> Mike
>>>>>
>>>>> --
>>>>>> Alex Harui
>>>>>> Flex SDK Team
>>>>>> Adobe Systems, Inc.
>>>>>> http://blogs.adobe.com/aharui
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>> http://www.teotigraphix.com
>>>>> http://blog.teotigraphix.com
>>>>>
>>>>>
>>>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
>
Re: FXG to SVG - working example
Posted by Harbs <ha...@gmail.com>.
I barely touch mobile (at the moment). If I did I would probably be interested. I'm hoping someone else picks up on this…
Harbs
On Mar 23, 2013, at 6:39 AM, Daniel Freeman wrote:
> I wrote one of those. I wrote SVG -> AS3 graphics. And extending that
> class, I wrote FXG -> AS3 graphics.
>
> It wasn't a complete implementation of the SVG or FXG standards. It didn't
> handle text, and complex gradients weren't perfect. The FXG class was
> based on Adobe's first FXG definition. But it worked pretty well.
>
> This was one of the features of the applications I offered to donate.
>
> Actually, if you go back to build r53 of extendedMadness. SVG was in
> there. I took it out, because I didn't think too may people would be
> interested - and to reduce the bloat. (I didn't want my Framework getting
> like Flex - did I),
>
> http://code.google.com/p/mad-components/source/detail?r=53#
>
> See example here:
> http://code.google.com/p/mad-components/source/browse/trunk/MadComponentStuff/src/MadComponentsDesktop.as?spec=svn53&r=53
>
> FXG isn't too different from SVG.
>
>
> ... I've mentioned this before, but I'd like to relinquish control a little
> over maintaining MadComponents, ExtendedMadness, and MC3D. I've offered
> before to donate them to this Apache group.
>
> Bear in mind that people aren't using Flex to build mobile apps. They're
> using MadComponents (General Purpose / Enterprise) or Feathers (Game UI).
> In fact, I've had clients engage my freelance services because they tried
> to build a mobile app using bloated Flex - and regretted it.
>
> http://madskool.wordpress.com/2012/01/23/why-developers-are-using-madcomponents/
>
> Is there any interest in this group in MadComponents?
>
>
> On Sat, Mar 16, 2013 at 4:01 AM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>> In my simple mind, Falcon generates the AST then at some point in time the
>>> futures task for that compilation unit is asked for output. Current
>>> Falcon
>>> code calls the BURM which eventually calls an emitter, I'm assuming
>>> FalconJX
>>> does an AST tree walk instead of calling the BURM. There is no reduction,
>>> just emitting. CSS for JS is probably just going emit text from the tree.
>>>
>>
>> Yes this is correct basically.
>>
>> Each compilation unit implements its own handleASBRequest() that gets
>> called during a generator request. This request ONLY happens AFTER the
>> handle AST and Scope requests have been processed.
>>
>> Its very complicated below that principle because of the future tasks and
>> outgoing dependency requests that trigger other files to be parsed, scopes
>> built etc.
>>
>> THe framework is elegant. The only thing I wish I could tear out and
>> abstract is how they have SWF baked into ITarget and Target.
>>
>> This really makes it hard to do what we are doing without all this
>> "baggage".
>>
>> As I said, parsing is multithreaded right now in FalconJx, I can easily
>> get the source code generation multithreaded to now that I have learned how
>> the framework wheels move together.
>>
>> I'm just not at the point to worry to much about it at the moment because
>> in a couple of my test projects, the compiler is wicked fast, I also have
>> an implementation that uses the Workspace and only loads config once, which
>> is using the framework like and IDE does...
>>
>> Mike
>>
>>
>>
>>
>>> On 3/15/13 1:44 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>>
>>> BTW,
>>>>
>>>> I have not seen one thing that you are asking for that doesn't contain
>>>> an AST and node framework in the Falcon package.
>>>>
>>>> If it was me, I would create all the emitters exactly the same way be
>>>> parsing the file, handling the AST, traversing it while outputting to
>>>> the target, then writing it in its file format.
>>>>
>>>> Its simple and I guess the FalconJx framework is mainly due to me
>>>> dealing with inheritance and dependency madness with Flex components
>>>> for years. I said all my future projects will use composition, this
>>>> one does big time.
>>>>
>>>> Mike
>>>>
>>>> Quoting Michael Schmalle <ap...@teotigraphix.com>:
>>>>
>>>>
>>>>> Quoting Alex Harui <ah...@adobe.com>:
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/15/13 1:14 PM, "Michael Schmalle" <ap...@teotigraphix.com>
>>>>>> wrote:
>>>>>>
>>>>>> The problem is, SWF is so
>>>>>>> interconnected in the generator packages that you might have a problem
>>>>>>> getting a polarity with using the BURM.
>>>>>>>
>>>>>> Don't know what "polarity" meant, but hopefully it doesn't really
>>>>>> matter.
>>>>>>
>>>>>
>>>>> Bad word, I meant polarity in emitters as what the BURM generators
>>>>> offer right now with FalconJS, properties, css, as, mxml.
>>>>>
>>>>>
>>>>> On that note; This would take more study to fully understand, but at
>>>>>>> the moment I don't have time to investigate. I guess you will have to
>>>>>>> weigh the options or get a "feel" for the Falcon framework when your
>>>>>>> not under as much of a timeline/deadline?
>>>>>>>
>>>>>>> That being said, the FalconJx framework was meant to be created in
>>>>>>> component sections, so if your end goal is to create things with it
>>>>>>> fully, I would suggest things being ported to its emitter, or it will
>>>>>>> for ever have a crutch on SWF.
>>>>>>>
>>>>>>> Good point about the generators being tied to SWF constructs. But I
>>>>>> am
>>>>>> assuming you that, in order to service different file types we will
>>>>>> have
>>>>>> several emitters? One for AS, one for MXML/AS? I think I will create
>>>>>> one
>>>>>> for CSS and someone will create one for FXG->SVG? And since these two
>>>>>> probably won't generate JS "classes", I think they won't be tied to
>>>>>> the SWF
>>>>>> constructs in the generator and thus will copy over "easily".
>>>>>>
>>>>>
>>>>> Right, if I was getting paid for this stuff, I could have most of it
>>>>> done in a month or two, so using the pattern I have created with
>>>>> FalconJx all your emitters with file handlers are possible.
>>>>>
>>>>> To realize what you need Alex, the knife is already built, its just
>>>>> adding the blades.
>>>>>
>>>>> Mike
>>>>>
>>>>> --
>>>>>> Alex Harui
>>>>>> Flex SDK Team
>>>>>> Adobe Systems, Inc.
>>>>>> http://blogs.adobe.com/aharui
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>> http://www.teotigraphix.com
>>>>> http://blog.teotigraphix.com
>>>>>
>>>>>
>>>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
Re: FXG to SVG - working example
Posted by Daniel Freeman <ma...@gmail.com>.
I wrote one of those. I wrote SVG -> AS3 graphics. And extending that
class, I wrote FXG -> AS3 graphics.
It wasn't a complete implementation of the SVG or FXG standards. It didn't
handle text, and complex gradients weren't perfect. The FXG class was
based on Adobe's first FXG definition. But it worked pretty well.
This was one of the features of the applications I offered to donate.
Actually, if you go back to build r53 of extendedMadness. SVG was in
there. I took it out, because I didn't think too may people would be
interested - and to reduce the bloat. (I didn't want my Framework getting
like Flex - did I),
http://code.google.com/p/mad-components/source/detail?r=53#
See example here:
http://code.google.com/p/mad-components/source/browse/trunk/MadComponentStuff/src/MadComponentsDesktop.as?spec=svn53&r=53
FXG isn't too different from SVG.
... I've mentioned this before, but I'd like to relinquish control a little
over maintaining MadComponents, ExtendedMadness, and MC3D. I've offered
before to donate them to this Apache group.
Bear in mind that people aren't using Flex to build mobile apps. They're
using MadComponents (General Purpose / Enterprise) or Feathers (Game UI).
In fact, I've had clients engage my freelance services because they tried
to build a mobile app using bloated Flex - and regretted it.
http://madskool.wordpress.com/2012/01/23/why-developers-are-using-madcomponents/
Is there any interest in this group in MadComponents?
On Sat, Mar 16, 2013 at 4:01 AM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
>
> Quoting Alex Harui <ah...@adobe.com>:
>
> In my simple mind, Falcon generates the AST then at some point in time the
>> futures task for that compilation unit is asked for output. Current
>> Falcon
>> code calls the BURM which eventually calls an emitter, I'm assuming
>> FalconJX
>> does an AST tree walk instead of calling the BURM. There is no reduction,
>> just emitting. CSS for JS is probably just going emit text from the tree.
>>
>
> Yes this is correct basically.
>
> Each compilation unit implements its own handleASBRequest() that gets
> called during a generator request. This request ONLY happens AFTER the
> handle AST and Scope requests have been processed.
>
> Its very complicated below that principle because of the future tasks and
> outgoing dependency requests that trigger other files to be parsed, scopes
> built etc.
>
> THe framework is elegant. The only thing I wish I could tear out and
> abstract is how they have SWF baked into ITarget and Target.
>
> This really makes it hard to do what we are doing without all this
> "baggage".
>
> As I said, parsing is multithreaded right now in FalconJx, I can easily
> get the source code generation multithreaded to now that I have learned how
> the framework wheels move together.
>
> I'm just not at the point to worry to much about it at the moment because
> in a couple of my test projects, the compiler is wicked fast, I also have
> an implementation that uses the Workspace and only loads config once, which
> is using the framework like and IDE does...
>
> Mike
>
>
>
>
>> On 3/15/13 1:44 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>
>> BTW,
>>>
>>> I have not seen one thing that you are asking for that doesn't contain
>>> an AST and node framework in the Falcon package.
>>>
>>> If it was me, I would create all the emitters exactly the same way be
>>> parsing the file, handling the AST, traversing it while outputting to
>>> the target, then writing it in its file format.
>>>
>>> Its simple and I guess the FalconJx framework is mainly due to me
>>> dealing with inheritance and dependency madness with Flex components
>>> for years. I said all my future projects will use composition, this
>>> one does big time.
>>>
>>> Mike
>>>
>>> Quoting Michael Schmalle <ap...@teotigraphix.com>:
>>>
>>>
>>>> Quoting Alex Harui <ah...@adobe.com>:
>>>>
>>>>
>>>>>
>>>>>
>>>>> On 3/15/13 1:14 PM, "Michael Schmalle" <ap...@teotigraphix.com>
>>>>> wrote:
>>>>>
>>>>> The problem is, SWF is so
>>>>>> interconnected in the generator packages that you might have a problem
>>>>>> getting a polarity with using the BURM.
>>>>>>
>>>>> Don't know what "polarity" meant, but hopefully it doesn't really
>>>>> matter.
>>>>>
>>>>
>>>> Bad word, I meant polarity in emitters as what the BURM generators
>>>> offer right now with FalconJS, properties, css, as, mxml.
>>>>
>>>>
>>>> On that note; This would take more study to fully understand, but at
>>>>>> the moment I don't have time to investigate. I guess you will have to
>>>>>> weigh the options or get a "feel" for the Falcon framework when your
>>>>>> not under as much of a timeline/deadline?
>>>>>>
>>>>>> That being said, the FalconJx framework was meant to be created in
>>>>>> component sections, so if your end goal is to create things with it
>>>>>> fully, I would suggest things being ported to its emitter, or it will
>>>>>> for ever have a crutch on SWF.
>>>>>>
>>>>>> Good point about the generators being tied to SWF constructs. But I
>>>>> am
>>>>> assuming you that, in order to service different file types we will
>>>>> have
>>>>> several emitters? One for AS, one for MXML/AS? I think I will create
>>>>> one
>>>>> for CSS and someone will create one for FXG->SVG? And since these two
>>>>> probably won't generate JS "classes", I think they won't be tied to
>>>>> the SWF
>>>>> constructs in the generator and thus will copy over "easily".
>>>>>
>>>>
>>>> Right, if I was getting paid for this stuff, I could have most of it
>>>> done in a month or two, so using the pattern I have created with
>>>> FalconJx all your emitters with file handlers are possible.
>>>>
>>>> To realize what you need Alex, the knife is already built, its just
>>>> adding the blades.
>>>>
>>>> Mike
>>>>
>>>> --
>>>>> Alex Harui
>>>>> Flex SDK Team
>>>>> Adobe Systems, Inc.
>>>>> http://blogs.adobe.com/aharui
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Michael Schmalle - Teoti Graphix, LLC
>>>> http://www.teotigraphix.com
>>>> http://blog.teotigraphix.com
>>>>
>>>>
>>>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
Re: FXG to SVG - working example
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Alex Harui <ah...@adobe.com>:
> In my simple mind, Falcon generates the AST then at some point in time the
> futures task for that compilation unit is asked for output. Current Falcon
> code calls the BURM which eventually calls an emitter, I'm assuming FalconJX
> does an AST tree walk instead of calling the BURM. There is no reduction,
> just emitting. CSS for JS is probably just going emit text from the tree.
Yes this is correct basically.
Each compilation unit implements its own handleASBRequest() that gets
called during a generator request. This request ONLY happens AFTER the
handle AST and Scope requests have been processed.
Its very complicated below that principle because of the future tasks
and outgoing dependency requests that trigger other files to be
parsed, scopes built etc.
THe framework is elegant. The only thing I wish I could tear out and
abstract is how they have SWF baked into ITarget and Target.
This really makes it hard to do what we are doing without all this "baggage".
As I said, parsing is multithreaded right now in FalconJx, I can
easily get the source code generation multithreaded to now that I have
learned how the framework wheels move together.
I'm just not at the point to worry to much about it at the moment
because in a couple of my test projects, the compiler is wicked fast,
I also have an implementation that uses the Workspace and only loads
config once, which is using the framework like and IDE does...
Mike
>
> On 3/15/13 1:44 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>> BTW,
>>
>> I have not seen one thing that you are asking for that doesn't contain
>> an AST and node framework in the Falcon package.
>>
>> If it was me, I would create all the emitters exactly the same way be
>> parsing the file, handling the AST, traversing it while outputting to
>> the target, then writing it in its file format.
>>
>> Its simple and I guess the FalconJx framework is mainly due to me
>> dealing with inheritance and dependency madness with Flex components
>> for years. I said all my future projects will use composition, this
>> one does big time.
>>
>> Mike
>>
>> Quoting Michael Schmalle <ap...@teotigraphix.com>:
>>
>>>
>>> Quoting Alex Harui <ah...@adobe.com>:
>>>
>>>>
>>>>
>>>>
>>>> On 3/15/13 1:14 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>>>
>>>>> The problem is, SWF is so
>>>>> interconnected in the generator packages that you might have a problem
>>>>> getting a polarity with using the BURM.
>>>> Don't know what "polarity" meant, but hopefully it doesn't really matter.
>>>
>>> Bad word, I meant polarity in emitters as what the BURM generators
>>> offer right now with FalconJS, properties, css, as, mxml.
>>>
>>>
>>>>> On that note; This would take more study to fully understand, but at
>>>>> the moment I don't have time to investigate. I guess you will have to
>>>>> weigh the options or get a "feel" for the Falcon framework when your
>>>>> not under as much of a timeline/deadline?
>>>>>
>>>>> That being said, the FalconJx framework was meant to be created in
>>>>> component sections, so if your end goal is to create things with it
>>>>> fully, I would suggest things being ported to its emitter, or it will
>>>>> for ever have a crutch on SWF.
>>>>>
>>>> Good point about the generators being tied to SWF constructs. But I am
>>>> assuming you that, in order to service different file types we will have
>>>> several emitters? One for AS, one for MXML/AS? I think I will create one
>>>> for CSS and someone will create one for FXG->SVG? And since these two
>>>> probably won't generate JS "classes", I think they won't be tied
>>>> to the SWF
>>>> constructs in the generator and thus will copy over "easily".
>>>
>>> Right, if I was getting paid for this stuff, I could have most of it
>>> done in a month or two, so using the pattern I have created with
>>> FalconJx all your emitters with file handlers are possible.
>>>
>>> To realize what you need Alex, the knife is already built, its just
>>> adding the blades.
>>>
>>> Mike
>>>
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>>
>>>>
>>>
>>> --
>>> Michael Schmalle - Teoti Graphix, LLC
>>> http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: FXG to SVG - working example
Posted by Alex Harui <ah...@adobe.com>.
In my simple mind, Falcon generates the AST then at some point in time the
futures task for that compilation unit is asked for output. Current Falcon
code calls the BURM which eventually calls an emitter, I'm assuming FalconJX
does an AST tree walk instead of calling the BURM. There is no reduction,
just emitting. CSS for JS is probably just going emit text from the tree.
On 3/15/13 1:44 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> BTW,
>
> I have not seen one thing that you are asking for that doesn't contain
> an AST and node framework in the Falcon package.
>
> If it was me, I would create all the emitters exactly the same way be
> parsing the file, handling the AST, traversing it while outputting to
> the target, then writing it in its file format.
>
> Its simple and I guess the FalconJx framework is mainly due to me
> dealing with inheritance and dependency madness with Flex components
> for years. I said all my future projects will use composition, this
> one does big time.
>
> Mike
>
> Quoting Michael Schmalle <ap...@teotigraphix.com>:
>
>>
>> Quoting Alex Harui <ah...@adobe.com>:
>>
>>>
>>>
>>>
>>> On 3/15/13 1:14 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>>
>>>> The problem is, SWF is so
>>>> interconnected in the generator packages that you might have a problem
>>>> getting a polarity with using the BURM.
>>> Don't know what "polarity" meant, but hopefully it doesn't really matter.
>>
>> Bad word, I meant polarity in emitters as what the BURM generators
>> offer right now with FalconJS, properties, css, as, mxml.
>>
>>
>>>> On that note; This would take more study to fully understand, but at
>>>> the moment I don't have time to investigate. I guess you will have to
>>>> weigh the options or get a "feel" for the Falcon framework when your
>>>> not under as much of a timeline/deadline?
>>>>
>>>> That being said, the FalconJx framework was meant to be created in
>>>> component sections, so if your end goal is to create things with it
>>>> fully, I would suggest things being ported to its emitter, or it will
>>>> for ever have a crutch on SWF.
>>>>
>>> Good point about the generators being tied to SWF constructs. But I am
>>> assuming you that, in order to service different file types we will have
>>> several emitters? One for AS, one for MXML/AS? I think I will create one
>>> for CSS and someone will create one for FXG->SVG? And since these two
>>> probably won't generate JS "classes", I think they won't be tied to the SWF
>>> constructs in the generator and thus will copy over "easily".
>>
>> Right, if I was getting paid for this stuff, I could have most of it
>> done in a month or two, so using the pattern I have created with
>> FalconJx all your emitters with file handlers are possible.
>>
>> To realize what you need Alex, the knife is already built, its just
>> adding the blades.
>>
>> Mike
>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FXG to SVG - working example
Posted by Michael Schmalle <ap...@teotigraphix.com>.
BTW,
I have not seen one thing that you are asking for that doesn't contain
an AST and node framework in the Falcon package.
If it was me, I would create all the emitters exactly the same way be
parsing the file, handling the AST, traversing it while outputting to
the target, then writing it in its file format.
Its simple and I guess the FalconJx framework is mainly due to me
dealing with inheritance and dependency madness with Flex components
for years. I said all my future projects will use composition, this
one does big time.
Mike
Quoting Michael Schmalle <ap...@teotigraphix.com>:
>
> Quoting Alex Harui <ah...@adobe.com>:
>
>>
>>
>>
>> On 3/15/13 1:14 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>>
>>> The problem is, SWF is so
>>> interconnected in the generator packages that you might have a problem
>>> getting a polarity with using the BURM.
>> Don't know what "polarity" meant, but hopefully it doesn't really matter.
>
> Bad word, I meant polarity in emitters as what the BURM generators
> offer right now with FalconJS, properties, css, as, mxml.
>
>
>>> On that note; This would take more study to fully understand, but at
>>> the moment I don't have time to investigate. I guess you will have to
>>> weigh the options or get a "feel" for the Falcon framework when your
>>> not under as much of a timeline/deadline?
>>>
>>> That being said, the FalconJx framework was meant to be created in
>>> component sections, so if your end goal is to create things with it
>>> fully, I would suggest things being ported to its emitter, or it will
>>> for ever have a crutch on SWF.
>>>
>> Good point about the generators being tied to SWF constructs. But I am
>> assuming you that, in order to service different file types we will have
>> several emitters? One for AS, one for MXML/AS? I think I will create one
>> for CSS and someone will create one for FXG->SVG? And since these two
>> probably won't generate JS "classes", I think they won't be tied to the SWF
>> constructs in the generator and thus will copy over "easily".
>
> Right, if I was getting paid for this stuff, I could have most of it
> done in a month or two, so using the pattern I have created with
> FalconJx all your emitters with file handlers are possible.
>
> To realize what you need Alex, the knife is already built, its just
> adding the blades.
>
> Mike
>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: FXG to SVG - working example
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Alex Harui <ah...@adobe.com>:
>
>
>
> On 3/15/13 1:14 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
>
>> The problem is, SWF is so
>> interconnected in the generator packages that you might have a problem
>> getting a polarity with using the BURM.
> Don't know what "polarity" meant, but hopefully it doesn't really matter.
Bad word, I meant polarity in emitters as what the BURM generators
offer right now with FalconJS, properties, css, as, mxml.
>> On that note; This would take more study to fully understand, but at
>> the moment I don't have time to investigate. I guess you will have to
>> weigh the options or get a "feel" for the Falcon framework when your
>> not under as much of a timeline/deadline?
>>
>> That being said, the FalconJx framework was meant to be created in
>> component sections, so if your end goal is to create things with it
>> fully, I would suggest things being ported to its emitter, or it will
>> for ever have a crutch on SWF.
>>
> Good point about the generators being tied to SWF constructs. But I am
> assuming you that, in order to service different file types we will have
> several emitters? One for AS, one for MXML/AS? I think I will create one
> for CSS and someone will create one for FXG->SVG? And since these two
> probably won't generate JS "classes", I think they won't be tied to the SWF
> constructs in the generator and thus will copy over "easily".
Right, if I was getting paid for this stuff, I could have most of it
done in a month or two, so using the pattern I have created with
FalconJx all your emitters with file handlers are possible.
To realize what you need Alex, the knife is already built, its just
adding the blades.
Mike
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: FXG to SVG - working example
Posted by Alex Harui <ah...@adobe.com>.
On 3/15/13 1:14 PM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> The problem is, SWF is so
> interconnected in the generator packages that you might have a problem
> getting a polarity with using the BURM.
Don't know what "polarity" meant, but hopefully it doesn't really matter.
>
> On that note; This would take more study to fully understand, but at
> the moment I don't have time to investigate. I guess you will have to
> weigh the options or get a "feel" for the Falcon framework when your
> not under as much of a timeline/deadline?
>
> That being said, the FalconJx framework was meant to be created in
> component sections, so if your end goal is to create things with it
> fully, I would suggest things being ported to its emitter, or it will
> for ever have a crutch on SWF.
>
Good point about the generators being tied to SWF constructs. But I am
assuming you that, in order to service different file types we will have
several emitters? One for AS, one for MXML/AS? I think I will create one
for CSS and someone will create one for FXG->SVG? And since these two
probably won't generate JS "classes", I think they won't be tied to the SWF
constructs in the generator and thus will copy over "easily".
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FXG to SVG - working example
Posted by Michael Schmalle <ap...@teotigraphix.com>.
There is no major surgery anywhere.
If you study the framework like I have, there is really only one way
to assemble a compiler in Falcon.
What I haven't done is allow for this other processing (css,
properties). Honestly this has not even fit into a use case for me and
I never thought about needing it for the project.
Falcon is not a compiler, its a framework of components that can be
put together to make a compiler front end. The problem is, SWF is so
interconnected in the generator packages that you might have a problem
getting a polarity with using the BURM.
On that note; This would take more study to fully understand, but at
the moment I don't have time to investigate. I guess you will have to
weigh the options or get a "feel" for the Falcon framework when your
not under as much of a timeline/deadline?
That being said, the FalconJx framework was meant to be created in
component sections, so if your end goal is to create things with it
fully, I would suggest things being ported to its emitter, or it will
for ever have a crutch on SWF.
Mike
Quoting Alex Harui <ah...@adobe.com>:
>
>
>
> On 3/15/13 12:56 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>>> don't believe that any of the work I am doing is wasted. FalconJS is not
>>> the competition, it is just a stop-gap place for me to experiment until
>>> FalconJX catches up.
>>
>> Ok, I wrote too long a statement (as ususal). The TL;DR version is: if
>> you continue to work on FalconJS, I won't be able to keep up on the
>> FalconJx side.
>>
> My point is that there is nothing to keep up with. All the work I'm doing
> is not in the MXML emitter work you are doing and should just copy over,
> unless you and Mike have done major surgery to the rest of Falcon.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: FXG to SVG - working example
Posted by Alex Harui <ah...@adobe.com>.
On 3/15/13 12:56 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> don't believe that any of the work I am doing is wasted. FalconJS is not
>> the competition, it is just a stop-gap place for me to experiment until
>> FalconJX catches up.
>
> Ok, I wrote too long a statement (as ususal). The TL;DR version is: if
> you continue to work on FalconJS, I won't be able to keep up on the
> FalconJx side.
>
My point is that there is nothing to keep up with. All the work I'm doing
is not in the MXML emitter work you are doing and should just copy over,
unless you and Mike have done major surgery to the rest of Falcon.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FXG to SVG - working example
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> don't believe that any of the work I am doing is wasted. FalconJS is not
> the competition, it is just a stop-gap place for me to experiment until
> FalconJX catches up.
Ok, I wrote too long a statement (as ususal). The TL;DR version is: if
you continue to work on FalconJS, I won't be able to keep up on the
FalconJx side.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FXG to SVG - working example
Posted by Alex Harui <ah...@adobe.com>.
On 3/15/13 11:54 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>> My personal goals:
>> 1) For the year: get a major Adobe customer to buy into using this
>> technology. This helps ensure I can continue to work on it full time. I
>> will shift my priorities in order to grab such a customer. For example
>> today I am enhancing HTTPService because a potential customer is interested.
>> 2) For next month: get data-binding {} syntax to work
>> 3) For the month after that: finish CSS to JS
>> 4) For next quarter: Try to port something like "old FlexStore"
>> 5) Also for next quarter: Cut an official release (alpha-level)
>> 6) Continously: get more people to try it and get involved.
>
> Alex, this has me a bit concerned. There is no way I can keep up with
> you in my spare time, if you continue to keep working in FalconJS full
> time. If I don't keep up with you, the switch to FalconJx will become
> more and more difficult. Having looked into the soul of FalconJS the
> past weeks, I agree with Mike and others that it doesn't look like the
> way forward for AS -> JS. Also, with FalconJx we can offer future
> users (customers?) options - VanillaSDK, AMD, FlexJS, the new FXG
> stuff I don't understand the first thing about - something that I'm
> sure will help "sell" Apache Flex to them. And one cross-compiler to
> rule them all will focus this community and give it a sense of
> direction.
>
> So... can we convince you to make the move to FalconJx a priority?
> Moving FlexJS over will mean that we all cooperate on the same
> codebase, something I'm sure will help your cause along much more
> efficient than keeping up the fragmented approach we have right now.
> With the move behind us, I would be very willing to make your goals my
> own as I believe your involvement is crucial for the continued success
> of the project.
>
As soon as we get out of this Git transition and you check in even a partial
implementation of MXML handling, I plan to get FalconJX and take a closer
look.
My understanding is that it is still based on Falcon and uses the futures
mechanism to compile compilation units. I am assuming it has not changed
the notion of "subcompilers". There are different "subcompilers" for
different kinds of file types: FXG, CSS, SWC, MXML, AS. Mike and you
reworked the AS "subcompiler". You are working on the MXML subcompiler. #3
in the list above involves working with the CSS sub-compiler. Om may be
working with the FXG subcompiler. These things should generally "just work"
with FalconJX.
The databinding stuff appears to be a bunch of classes in the MXML
subcompiler and more classes elsewhere. For me, I want to understand how it
works in classic Falcon so I can understand how we're going to deal with it
in both the AS side and JS side of FlexJS. And once I figure it out, I hope
I can just copy the implementation in FalconJX.
It is true that the CSS subcompiler uses the BURM, but it works for FlexJS
and I don't know if we are in any hurry to change that. Do we have to
un-BURM FalconJX or can we just not use the BURM for AS/MXML? BTW, the JS
output for CSS is actually just going to be text/css so I might just pass
over the BURM on the JS/JX but I don't know if it is worth re-coding the AS
side just to un-BURM it. At least not right away.
I have to keep doing my work in FalconJS until you are mostly ready with
MXML in FalconJX because I am feeling lots of pressure to establish FlexJS
ASAP. I am currently trying to sell one internal team at Adobe on it. If I
had waited for FalconJX I would not be able to demo what I can today. And I
don't believe that any of the work I am doing is wasted. FalconJS is not
the competition, it is just a stop-gap place for me to experiment until
FalconJX catches up.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FXG to SVG - working example
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> My personal goals:
> 1) For the year: get a major Adobe customer to buy into using this
> technology. This helps ensure I can continue to work on it full time. I
> will shift my priorities in order to grab such a customer. For example
> today I am enhancing HTTPService because a potential customer is interested.
> 2) For next month: get data-binding {} syntax to work
> 3) For the month after that: finish CSS to JS
> 4) For next quarter: Try to port something like "old FlexStore"
> 5) Also for next quarter: Cut an official release (alpha-level)
> 6) Continously: get more people to try it and get involved.
Alex, this has me a bit concerned. There is no way I can keep up with
you in my spare time, if you continue to keep working in FalconJS full
time. If I don't keep up with you, the switch to FalconJx will become
more and more difficult. Having looked into the soul of FalconJS the
past weeks, I agree with Mike and others that it doesn't look like the
way forward for AS -> JS. Also, with FalconJx we can offer future
users (customers?) options - VanillaSDK, AMD, FlexJS, the new FXG
stuff I don't understand the first thing about - something that I'm
sure will help "sell" Apache Flex to them. And one cross-compiler to
rule them all will focus this community and give it a sense of
direction.
So... can we convince you to make the move to FalconJx a priority?
Moving FlexJS over will mean that we all cooperate on the same
codebase, something I'm sure will help your cause along much more
efficient than keeping up the fragmented approach we have right now.
With the move behind us, I would be very willing to make your goals my
own as I believe your involvement is crucial for the continued success
of the project.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FXG to SVG - working example
Posted by Alex Harui <ah...@adobe.com>.
On 3/15/13 10:00 AM, "Om" <bi...@gmail.com> wrote:
>> Once this ever extending forced (or self imposed?) period of
>> inactivity while we wait for git might be just the thing we need to
>> synchronise our efforts and (dare one say it...) talk about a near
>> future roadmap a bit?
>>
>> EdB
>>
>
> +1 for some sort of a roadmap for this project. If someone wants to build
> a reasonably complex (pure) Flex app, we can use that as our end goal.
> This would help us look beyond the abstract concentrate on real world
> problems.
>
Roadmap!? There are no roadmaps in Apache Flex :-)
We are in prototype stage. I think it is ok to have different goals. For
sure, we all agree we're trying to get from AS/MXML to JS, but IMO, the next
level down can have some wiggle room for now. What is important to you
doesn't have to truly match me. I'm actually glad you want to take on
vector skinning because it will help prove we don't create a skinning model
that is too biased one way or the other.
My personal goals:
1) For the year: get a major Adobe customer to buy into using this
technology. This helps ensure I can continue to work on it full time. I
will shift my priorities in order to grab such a customer. For example
today I am enhancing HTTPService because a potential customer is interested.
2) For next month: get data-binding {} syntax to work
3) For the month after that: finish CSS to JS
4) For next quarter: Try to port something like "old FlexStore"
5) Also for next quarter: Cut an official release (alpha-level)
6) Continously: get more people to try it and get involved.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FXG to SVG - working example
Posted by Om <bi...@gmail.com>.
On Fri, Mar 15, 2013 at 9:33 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> I think we need one "little big" push to get FlexJS to work on
> FalconJx. From that point on, all of these efforts will be on one
> stack (Falcon - FalconJx - output classes/modules/plugins). This
> integration will benefit all of these components in that we can report
> bugs and define requirements back and forth, as well as write tests on
> a single base, ensuring operability between releases.
>
>
Agree 100% with you there.
> Once this ever extending forced (or self imposed?) period of
> inactivity while we wait for git might be just the thing we need to
> synchronise our efforts and (dare one say it...) talk about a near
> future roadmap a bit?
>
> EdB
>
+1 for some sort of a roadmap for this project. If someone wants to build
a reasonably complex (pure) Flex app, we can use that as our end goal.
This would help us look beyond the abstract concentrate on real world
problems.
Thanks,
Om
>
>
>
> On Fri, Mar 15, 2013 at 4:31 PM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
> > BTW,
> >
> > When I say I am not interested in the view cross compilation... All that
> > means is that I am saying don't wait for me to implement any of it. I am
> > being very direct in what my goals are with FlaconJx anyways, I just
> wanted
> > something that would cross compile actionscript to a multiple output
> > possibilities. This allows others as Erik is proving to do what they need
> > with the end product.
> >
> > My days of flex components are over, thank goodness. :)
> >
> > Mike
> >
> >
> >
> > Quoting Alex Harui <ah...@adobe.com>:
> >
> >> FWIW, Peter and I are pretty much done with the basic set of
> unstyleable,
> >> unskinnable HTML4 components. Peter and I were going to work on
> styleable
> >> HTML4 components next then tackle HTML5 and bitmap skinning, but maybe
> we
> >> should jump to wrapping the HTML5 components so you can try getting your
> >> skinning model to work on them.
> >>
> >>
> >> On 3/15/13 4:16 AM, "Om" <bi...@gmail.com> wrote:
> >>
> >>> On Fri, Mar 15, 2013 at 4:11 AM, Michael Schmalle
> >>> <ap...@teotigraphix.com>wrote:
> >>>
> >>>> Om,
> >>>>
> >>>> At this point and time, I am not worried about rendering. I am more
> >>>> concerned about straight business logic getting cross compiled.
> >>>>
> >>>>
> >>> I am worried about it and hence scratching my itch :-) I have not seen
> >>> any
> >>> proposal better than mine so far.
> >>>
> >>>
> >>>> This is probably why you have heard anything, I talk a lot on this
> forum
> >>>> and haven't said anything about it. :)
> >>>>
> >>>> I don't even own up to date Adobe programs that even export FXG, I
> think
> >>>> I
> >>>> have CS3, and love it. I think giving the View to web developers using
> >>>> HTML
> >>>> and CSS should be explored by this group as well, instead of relying
> on
> >>>> cross compiling views.
> >>>>
> >>>
> >>> My goal is to have a solution that does not make the user touch HTML,
> JS
> >>> or
> >>> CSS. The current workflow we have with Flex + FXG is far superior than
> >>> anything out there. I am just trying to see how to keep these
> workflows
> >>> going forward but still support cross compilation.
> >>>
> >>>
> >>>>
> >>>> Mike
> >>>>
> >>>>
> >>>>
> >>>> Quoting Om <bi...@gmail.com>:
> >>>>
> >>>> I quickly whipped up a proof of concept proving the FXG to SVG
> >>>>>
> >>>>> interoperability.
> >>>>>
> >>>>> The working demo can be found here:
> >>>>>
> >>>>> http://people.apache.org/~**bigosmallm/fxg2svg/svg.html<
> http://people.apache
> >>>>> .org/~bigosmallm/fxg2svg/svg.html>(Tested to be working
> >>>>> fine on Chrome 25, Firefox 19 and IE 10 on Windows)
> >>>>>
> >>>>> I did not have time to write a stylesheet, so I hand created a simple
> >>>>> SVG
> >>>>> element based on an FXG element. I chose the most basic element:
> >>>>> "Rect"
> >>>>> which is available as "rect" in SVG. Once I had the basic set up
> >>>>> working,
> >>>>> all I had to do was modify the svg's attributes using Javascript.
> This
> >>>>> happens during runtime, but we could totally move this to the
> >>>>> compilation
> >>>>> stage.
> >>>>>
> >>>>> As you can see, I have proven that rendering fidelity can be achieved
> >>>>> using
> >>>>> this route. At the same time, this can be plugged into the AS to JS
> >>>>> translation piece that Mike, Erik, et al. are working on. From what
> I
> >>>>> see
> >>>>> in that project, there is no faithful rendering solution (yet) You
> >>>>> probably discussed about rendering that I might have missed.
> >>>>>
> >>>>> When I get some more time, I will start fiddling with more and more
> FXG
> >>>>> elements and see how SVG handles them. At some point, writing a
> >>>>> stylesheet
> >>>>> would be more efficient.
> >>>>>
> >>>>> Just right click either the Flex app or the HTML content to view the
> >>>>> source
> >>>>> of both. Comments and suggestions for improvement highly
> appreciated.
> >>>>> This is a very basic demo, dealing mostly about rendering fidelity.
> But
> >>>>> IMHO, this unleashes a ton of possibilities.
> >>>>>
> >>>>> (And no, FXG is not dead - yet. ;-) )
> >>>>>
> >>>>> Thanks,
> >>>>> Om
> >>>>>
> >>>>>
> >>>> --
> >>>> Michael Schmalle - Teoti Graphix, LLC
> >>>> http://www.teotigraphix.com
> >>>> http://blog.teotigraphix.com
> >>>>
> >>>>
> >>
> >> --
> >> Alex Harui
> >> Flex SDK Team
> >> Adobe Systems, Inc.
> >> http://blogs.adobe.com/aharui
> >>
> >>
> >
> > --
> > Michael Schmalle - Teoti Graphix, LLC
> > http://www.teotigraphix.com
> > http://blog.teotigraphix.com
> >
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: FXG to SVG - working example
Posted by jude <fl...@gmail.com>.
On Fri, Mar 15, 2013 at 11:33 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> I think we need one "little big" push to get FlexJS to work on
> FalconJx. From that point on, all of these efforts will be on one
> stack (Falcon - FalconJx - output classes/modules/plugins). This
> integration will benefit all of these components in that we can report
> bugs and define requirements back and forth, as well as write tests on
> a single base, ensuring operability between releases.
>
That's part of what I'm waiting for. If I can see a clear path then I can
jump in and help (time permitting). When I say clear I mean clear to me.
Getting a full stack, "...(Falcon - FalconJx - output
classes/modules/plugins)" sounds likes the clearing in the forest. But as I
said in an earlier post I'll try and get things setup and help myself get a
clearer picture as well.
>
> Once this ever extending forced (or self imposed?) period of
> inactivity while we wait for git might be just the thing we need to
> synchronise our efforts and (dare one say it...) talk about a near
> future roadmap a bit?
There's nothing that says we can't have roadmaps or goals in a project. It
says it's up to the head of the project how they want to do it. I think
where the fuss comes in is when trying to set globally scoped roadmaps. No
one will make a fuss if we set locally scoped or cellular roadmaps. Knowing
what people in the group are trying to do would help other people in the
group help them with respect to what I mentioned above.
Re: FXG to SVG - working example
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I think we need one "little big" push to get FlexJS to work on
FalconJx. From that point on, all of these efforts will be on one
stack (Falcon - FalconJx - output classes/modules/plugins). This
integration will benefit all of these components in that we can report
bugs and define requirements back and forth, as well as write tests on
a single base, ensuring operability between releases.
Once this ever extending forced (or self imposed?) period of
inactivity while we wait for git might be just the thing we need to
synchronise our efforts and (dare one say it...) talk about a near
future roadmap a bit?
EdB
On Fri, Mar 15, 2013 at 4:31 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> BTW,
>
> When I say I am not interested in the view cross compilation... All that
> means is that I am saying don't wait for me to implement any of it. I am
> being very direct in what my goals are with FlaconJx anyways, I just wanted
> something that would cross compile actionscript to a multiple output
> possibilities. This allows others as Erik is proving to do what they need
> with the end product.
>
> My days of flex components are over, thank goodness. :)
>
> Mike
>
>
>
> Quoting Alex Harui <ah...@adobe.com>:
>
>> FWIW, Peter and I are pretty much done with the basic set of unstyleable,
>> unskinnable HTML4 components. Peter and I were going to work on styleable
>> HTML4 components next then tackle HTML5 and bitmap skinning, but maybe we
>> should jump to wrapping the HTML5 components so you can try getting your
>> skinning model to work on them.
>>
>>
>> On 3/15/13 4:16 AM, "Om" <bi...@gmail.com> wrote:
>>
>>> On Fri, Mar 15, 2013 at 4:11 AM, Michael Schmalle
>>> <ap...@teotigraphix.com>wrote:
>>>
>>>> Om,
>>>>
>>>> At this point and time, I am not worried about rendering. I am more
>>>> concerned about straight business logic getting cross compiled.
>>>>
>>>>
>>> I am worried about it and hence scratching my itch :-) I have not seen
>>> any
>>> proposal better than mine so far.
>>>
>>>
>>>> This is probably why you have heard anything, I talk a lot on this forum
>>>> and haven't said anything about it. :)
>>>>
>>>> I don't even own up to date Adobe programs that even export FXG, I think
>>>> I
>>>> have CS3, and love it. I think giving the View to web developers using
>>>> HTML
>>>> and CSS should be explored by this group as well, instead of relying on
>>>> cross compiling views.
>>>>
>>>
>>> My goal is to have a solution that does not make the user touch HTML, JS
>>> or
>>> CSS. The current workflow we have with Flex + FXG is far superior than
>>> anything out there. I am just trying to see how to keep these workflows
>>> going forward but still support cross compilation.
>>>
>>>
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>> Quoting Om <bi...@gmail.com>:
>>>>
>>>> I quickly whipped up a proof of concept proving the FXG to SVG
>>>>>
>>>>> interoperability.
>>>>>
>>>>> The working demo can be found here:
>>>>>
>>>>> http://people.apache.org/~**bigosmallm/fxg2svg/svg.html<http://people.apache
>>>>> .org/~bigosmallm/fxg2svg/svg.html>(Tested to be working
>>>>> fine on Chrome 25, Firefox 19 and IE 10 on Windows)
>>>>>
>>>>> I did not have time to write a stylesheet, so I hand created a simple
>>>>> SVG
>>>>> element based on an FXG element. I chose the most basic element:
>>>>> "Rect"
>>>>> which is available as "rect" in SVG. Once I had the basic set up
>>>>> working,
>>>>> all I had to do was modify the svg's attributes using Javascript. This
>>>>> happens during runtime, but we could totally move this to the
>>>>> compilation
>>>>> stage.
>>>>>
>>>>> As you can see, I have proven that rendering fidelity can be achieved
>>>>> using
>>>>> this route. At the same time, this can be plugged into the AS to JS
>>>>> translation piece that Mike, Erik, et al. are working on. From what I
>>>>> see
>>>>> in that project, there is no faithful rendering solution (yet) You
>>>>> probably discussed about rendering that I might have missed.
>>>>>
>>>>> When I get some more time, I will start fiddling with more and more FXG
>>>>> elements and see how SVG handles them. At some point, writing a
>>>>> stylesheet
>>>>> would be more efficient.
>>>>>
>>>>> Just right click either the Flex app or the HTML content to view the
>>>>> source
>>>>> of both. Comments and suggestions for improvement highly appreciated.
>>>>> This is a very basic demo, dealing mostly about rendering fidelity. But
>>>>> IMHO, this unleashes a ton of possibilities.
>>>>>
>>>>> (And no, FXG is not dead - yet. ;-) )
>>>>>
>>>>> Thanks,
>>>>> Om
>>>>>
>>>>>
>>>> --
>>>> Michael Schmalle - Teoti Graphix, LLC
>>>> http://www.teotigraphix.com
>>>> http://blog.teotigraphix.com
>>>>
>>>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FXG to SVG - working example
Posted by Michael Schmalle <ap...@teotigraphix.com>.
BTW,
When I say I am not interested in the view cross compilation... All
that means is that I am saying don't wait for me to implement any of
it. I am being very direct in what my goals are with FlaconJx anyways,
I just wanted something that would cross compile actionscript to a
multiple output possibilities. This allows others as Erik is proving
to do what they need with the end product.
My days of flex components are over, thank goodness. :)
Mike
Quoting Alex Harui <ah...@adobe.com>:
> FWIW, Peter and I are pretty much done with the basic set of unstyleable,
> unskinnable HTML4 components. Peter and I were going to work on styleable
> HTML4 components next then tackle HTML5 and bitmap skinning, but maybe we
> should jump to wrapping the HTML5 components so you can try getting your
> skinning model to work on them.
>
>
> On 3/15/13 4:16 AM, "Om" <bi...@gmail.com> wrote:
>
>> On Fri, Mar 15, 2013 at 4:11 AM, Michael Schmalle
>> <ap...@teotigraphix.com>wrote:
>>
>>> Om,
>>>
>>> At this point and time, I am not worried about rendering. I am more
>>> concerned about straight business logic getting cross compiled.
>>>
>>>
>> I am worried about it and hence scratching my itch :-) I have not seen any
>> proposal better than mine so far.
>>
>>
>>> This is probably why you have heard anything, I talk a lot on this forum
>>> and haven't said anything about it. :)
>>>
>>> I don't even own up to date Adobe programs that even export FXG, I think I
>>> have CS3, and love it. I think giving the View to web developers using HTML
>>> and CSS should be explored by this group as well, instead of relying on
>>> cross compiling views.
>>>
>>
>> My goal is to have a solution that does not make the user touch HTML, JS or
>> CSS. The current workflow we have with Flex + FXG is far superior than
>> anything out there. I am just trying to see how to keep these workflows
>> going forward but still support cross compilation.
>>
>>
>>>
>>> Mike
>>>
>>>
>>>
>>> Quoting Om <bi...@gmail.com>:
>>>
>>> I quickly whipped up a proof of concept proving the FXG to SVG
>>>> interoperability.
>>>>
>>>> The working demo can be found here:
>>>> http://people.apache.org/~**bigosmallm/fxg2svg/svg.html<http://people.apache
>>>> .org/~bigosmallm/fxg2svg/svg.html>(Tested to be working
>>>> fine on Chrome 25, Firefox 19 and IE 10 on Windows)
>>>>
>>>> I did not have time to write a stylesheet, so I hand created a simple SVG
>>>> element based on an FXG element. I chose the most basic element: "Rect"
>>>> which is available as "rect" in SVG. Once I had the basic set up working,
>>>> all I had to do was modify the svg's attributes using Javascript. This
>>>> happens during runtime, but we could totally move this to the compilation
>>>> stage.
>>>>
>>>> As you can see, I have proven that rendering fidelity can be achieved
>>>> using
>>>> this route. At the same time, this can be plugged into the AS to JS
>>>> translation piece that Mike, Erik, et al. are working on. From what I see
>>>> in that project, there is no faithful rendering solution (yet) You
>>>> probably discussed about rendering that I might have missed.
>>>>
>>>> When I get some more time, I will start fiddling with more and more FXG
>>>> elements and see how SVG handles them. At some point, writing a
>>>> stylesheet
>>>> would be more efficient.
>>>>
>>>> Just right click either the Flex app or the HTML content to view the
>>>> source
>>>> of both. Comments and suggestions for improvement highly appreciated.
>>>> This is a very basic demo, dealing mostly about rendering fidelity. But
>>>> IMHO, this unleashes a ton of possibilities.
>>>>
>>>> (And no, FXG is not dead - yet. ;-) )
>>>>
>>>> Thanks,
>>>> Om
>>>>
>>>>
>>> --
>>> Michael Schmalle - Teoti Graphix, LLC
>>> http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: FXG to SVG - working example
Posted by Alex Harui <ah...@adobe.com>.
FWIW, Peter and I are pretty much done with the basic set of unstyleable,
unskinnable HTML4 components. Peter and I were going to work on styleable
HTML4 components next then tackle HTML5 and bitmap skinning, but maybe we
should jump to wrapping the HTML5 components so you can try getting your
skinning model to work on them.
On 3/15/13 4:16 AM, "Om" <bi...@gmail.com> wrote:
> On Fri, Mar 15, 2013 at 4:11 AM, Michael Schmalle
> <ap...@teotigraphix.com>wrote:
>
>> Om,
>>
>> At this point and time, I am not worried about rendering. I am more
>> concerned about straight business logic getting cross compiled.
>>
>>
> I am worried about it and hence scratching my itch :-) I have not seen any
> proposal better than mine so far.
>
>
>> This is probably why you have heard anything, I talk a lot on this forum
>> and haven't said anything about it. :)
>>
>> I don't even own up to date Adobe programs that even export FXG, I think I
>> have CS3, and love it. I think giving the View to web developers using HTML
>> and CSS should be explored by this group as well, instead of relying on
>> cross compiling views.
>>
>
> My goal is to have a solution that does not make the user touch HTML, JS or
> CSS. The current workflow we have with Flex + FXG is far superior than
> anything out there. I am just trying to see how to keep these workflows
> going forward but still support cross compilation.
>
>
>>
>> Mike
>>
>>
>>
>> Quoting Om <bi...@gmail.com>:
>>
>> I quickly whipped up a proof of concept proving the FXG to SVG
>>> interoperability.
>>>
>>> The working demo can be found here:
>>> http://people.apache.org/~**bigosmallm/fxg2svg/svg.html<http://people.apache
>>> .org/~bigosmallm/fxg2svg/svg.html>(Tested to be working
>>> fine on Chrome 25, Firefox 19 and IE 10 on Windows)
>>>
>>> I did not have time to write a stylesheet, so I hand created a simple SVG
>>> element based on an FXG element. I chose the most basic element: "Rect"
>>> which is available as "rect" in SVG. Once I had the basic set up working,
>>> all I had to do was modify the svg's attributes using Javascript. This
>>> happens during runtime, but we could totally move this to the compilation
>>> stage.
>>>
>>> As you can see, I have proven that rendering fidelity can be achieved
>>> using
>>> this route. At the same time, this can be plugged into the AS to JS
>>> translation piece that Mike, Erik, et al. are working on. From what I see
>>> in that project, there is no faithful rendering solution (yet) You
>>> probably discussed about rendering that I might have missed.
>>>
>>> When I get some more time, I will start fiddling with more and more FXG
>>> elements and see how SVG handles them. At some point, writing a
>>> stylesheet
>>> would be more efficient.
>>>
>>> Just right click either the Flex app or the HTML content to view the
>>> source
>>> of both. Comments and suggestions for improvement highly appreciated.
>>> This is a very basic demo, dealing mostly about rendering fidelity. But
>>> IMHO, this unleashes a ton of possibilities.
>>>
>>> (And no, FXG is not dead - yet. ;-) )
>>>
>>> Thanks,
>>> Om
>>>
>>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: FXG to SVG - working example
Posted by Om <bi...@gmail.com>.
On Fri, Mar 15, 2013 at 4:11 AM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> Om,
>
> At this point and time, I am not worried about rendering. I am more
> concerned about straight business logic getting cross compiled.
>
>
I am worried about it and hence scratching my itch :-) I have not seen any
proposal better than mine so far.
> This is probably why you have heard anything, I talk a lot on this forum
> and haven't said anything about it. :)
>
> I don't even own up to date Adobe programs that even export FXG, I think I
> have CS3, and love it. I think giving the View to web developers using HTML
> and CSS should be explored by this group as well, instead of relying on
> cross compiling views.
>
My goal is to have a solution that does not make the user touch HTML, JS or
CSS. The current workflow we have with Flex + FXG is far superior than
anything out there. I am just trying to see how to keep these workflows
going forward but still support cross compilation.
>
> Mike
>
>
>
> Quoting Om <bi...@gmail.com>:
>
> I quickly whipped up a proof of concept proving the FXG to SVG
>> interoperability.
>>
>> The working demo can be found here:
>> http://people.apache.org/~**bigosmallm/fxg2svg/svg.html<http://people.apache.org/~bigosmallm/fxg2svg/svg.html>(Tested to be working
>> fine on Chrome 25, Firefox 19 and IE 10 on Windows)
>>
>> I did not have time to write a stylesheet, so I hand created a simple SVG
>> element based on an FXG element. I chose the most basic element: "Rect"
>> which is available as "rect" in SVG. Once I had the basic set up working,
>> all I had to do was modify the svg's attributes using Javascript. This
>> happens during runtime, but we could totally move this to the compilation
>> stage.
>>
>> As you can see, I have proven that rendering fidelity can be achieved
>> using
>> this route. At the same time, this can be plugged into the AS to JS
>> translation piece that Mike, Erik, et al. are working on. From what I see
>> in that project, there is no faithful rendering solution (yet) You
>> probably discussed about rendering that I might have missed.
>>
>> When I get some more time, I will start fiddling with more and more FXG
>> elements and see how SVG handles them. At some point, writing a
>> stylesheet
>> would be more efficient.
>>
>> Just right click either the Flex app or the HTML content to view the
>> source
>> of both. Comments and suggestions for improvement highly appreciated.
>> This is a very basic demo, dealing mostly about rendering fidelity. But
>> IMHO, this unleashes a ton of possibilities.
>>
>> (And no, FXG is not dead - yet. ;-) )
>>
>> Thanks,
>> Om
>>
>>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
Re: FXG to SVG - working example
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Om,
At this point and time, I am not worried about rendering. I am more
concerned about straight business logic getting cross compiled.
This is probably why you have heard anything, I talk a lot on this
forum and haven't said anything about it. :)
I don't even own up to date Adobe programs that even export FXG, I
think I have CS3, and love it. I think giving the View to web
developers using HTML and CSS should be explored by this group as
well, instead of relying on cross compiling views.
Mike
Quoting Om <bi...@gmail.com>:
> I quickly whipped up a proof of concept proving the FXG to SVG
> interoperability.
>
> The working demo can be found here:
> http://people.apache.org/~bigosmallm/fxg2svg/svg.html (Tested to be working
> fine on Chrome 25, Firefox 19 and IE 10 on Windows)
>
> I did not have time to write a stylesheet, so I hand created a simple SVG
> element based on an FXG element. I chose the most basic element: "Rect"
> which is available as "rect" in SVG. Once I had the basic set up working,
> all I had to do was modify the svg's attributes using Javascript. This
> happens during runtime, but we could totally move this to the compilation
> stage.
>
> As you can see, I have proven that rendering fidelity can be achieved using
> this route. At the same time, this can be plugged into the AS to JS
> translation piece that Mike, Erik, et al. are working on. From what I see
> in that project, there is no faithful rendering solution (yet) You
> probably discussed about rendering that I might have missed.
>
> When I get some more time, I will start fiddling with more and more FXG
> elements and see how SVG handles them. At some point, writing a stylesheet
> would be more efficient.
>
> Just right click either the Flex app or the HTML content to view the source
> of both. Comments and suggestions for improvement highly appreciated.
> This is a very basic demo, dealing mostly about rendering fidelity. But
> IMHO, this unleashes a ton of possibilities.
>
> (And no, FXG is not dead - yet. ;-) )
>
> Thanks,
> Om
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: FXG to SVG - working example
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Nobody said it was simple... it's just that he put it together really
quickly ;-)
EdB
On Fri, Mar 15, 2013 at 5:30 PM, Sebastian Mohr <fl...@gmail.com> wrote:
> Thanks Om,
>
> Didn't expect that the FXG to SVG interoperability could be so simple. Will
> think about its implications :)
>
>
> --
> Sebastian (PPMC)
> Interaction Designer
>
> Looking for a Login Example with Apache Flex? Please check out this code:
> http://code.google.com/p/masuland/wiki/LoginExample
>
>
>
> On Fri, Mar 15, 2013 at 12:03 PM, Om <bi...@gmail.com> wrote:
>
>> I quickly whipped up a proof of concept proving the FXG to SVG
>> interoperability.
>>
>> The working demo can be found here:
>> http://people.apache.org/~bigosmallm/fxg2svg/svg.html (Tested to be
>> working
>> fine on Chrome 25, Firefox 19 and IE 10 on Windows)
>>
>> I did not have time to write a stylesheet, so I hand created a simple SVG
>> element based on an FXG element. I chose the most basic element: "Rect"
>> which is available as "rect" in SVG. Once I had the basic set up working,
>> all I had to do was modify the svg's attributes using Javascript. This
>> happens during runtime, but we could totally move this to the compilation
>> stage.
>>
>> As you can see, I have proven that rendering fidelity can be achieved using
>> this route. At the same time, this can be plugged into the AS to JS
>> translation piece that Mike, Erik, et al. are working on. From what I see
>> in that project, there is no faithful rendering solution (yet) You
>> probably discussed about rendering that I might have missed.
>>
>> When I get some more time, I will start fiddling with more and more FXG
>> elements and see how SVG handles them. At some point, writing a stylesheet
>> would be more efficient.
>>
>> Just right click either the Flex app or the HTML content to view the source
>> of both. Comments and suggestions for improvement highly appreciated.
>> This is a very basic demo, dealing mostly about rendering fidelity. But
>> IMHO, this unleashes a ton of possibilities.
>>
>> (And no, FXG is not dead - yet. ;-) )
>>
>> Thanks,
>> Om
>>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: FXG to SVG - working example
Posted by Sebastian Mohr <fl...@gmail.com>.
Thanks Om,
Didn't expect that the FXG to SVG interoperability could be so simple. Will
think about its implications :)
--
Sebastian (PPMC)
Interaction Designer
Looking for a Login Example with Apache Flex? Please check out this code:
http://code.google.com/p/masuland/wiki/LoginExample
On Fri, Mar 15, 2013 at 12:03 PM, Om <bi...@gmail.com> wrote:
> I quickly whipped up a proof of concept proving the FXG to SVG
> interoperability.
>
> The working demo can be found here:
> http://people.apache.org/~bigosmallm/fxg2svg/svg.html (Tested to be
> working
> fine on Chrome 25, Firefox 19 and IE 10 on Windows)
>
> I did not have time to write a stylesheet, so I hand created a simple SVG
> element based on an FXG element. I chose the most basic element: "Rect"
> which is available as "rect" in SVG. Once I had the basic set up working,
> all I had to do was modify the svg's attributes using Javascript. This
> happens during runtime, but we could totally move this to the compilation
> stage.
>
> As you can see, I have proven that rendering fidelity can be achieved using
> this route. At the same time, this can be plugged into the AS to JS
> translation piece that Mike, Erik, et al. are working on. From what I see
> in that project, there is no faithful rendering solution (yet) You
> probably discussed about rendering that I might have missed.
>
> When I get some more time, I will start fiddling with more and more FXG
> elements and see how SVG handles them. At some point, writing a stylesheet
> would be more efficient.
>
> Just right click either the Flex app or the HTML content to view the source
> of both. Comments and suggestions for improvement highly appreciated.
> This is a very basic demo, dealing mostly about rendering fidelity. But
> IMHO, this unleashes a ton of possibilities.
>
> (And no, FXG is not dead - yet. ;-) )
>
> Thanks,
> Om
>