On Tue, May 19, 2015 at 12:36 PM, Michael Schmalle <
teotigraphix...@gmail.com> wrote:

> Ok thanks Om, lots to think about. Some more questions.
>
> I am still a bit naive with HTML and SVG. Can SVG be used to skin an HTML
> button? Or is it that you have to "Wrap" an html button with an SVG tag to
> pretty much draw under it?
>

No, SVG cannot be used to skin a native HTML button. The skin class has to
be just another display object under the component, just like the Spark
Button in the current SDK.


>
> I love the idea of a Spark like skinning system and would totally help on
> this, I am just trying to see how it would be implemented and how it
> coincides with the HTML side, the AS side is obvious, the HTML side the SVG
> is a child of the this.element?
>

Yes, that is correct.  Although, I have not exactly implemented this
approach.  We should know more when I actually start coding a simple skin.


>
> Question: Is SVG meant to be interactive like a Button element or is it
> meant for graphics.


My current thinking is that for each state of the interactive button, a set
of SVG elements would be drawn.  Again, much like today's Spark Button +
skin paradigm.  The good thing about SVG is that event handlers can be
attached to individual elements, so the interaction can be passed to the
component which can respond by changing the state on itself and on its skin.


> I am just trying to see the point at which the
> component in html is either SVG or an HTML element. Since you say the SVG
> is just created on the DOM, then aren't you saying that the SVG element is
> just a child of the main component?
>

Yes, all the SVG elements would be children of the skin, which in turn
would be a child of the main component.


>
> Do you have any prototypes of this going?
>

I have one, but based on the older FXG -> SVG XSLT approach [1], [2]

Left side is Flash, right side is HTML5/SVG.  In this approach, I set the
SVG by setting CSS pseudo-classes .  This is still an option going forward,
but one that I don't like that much.  I prefer MXML states vs. CSS
pseudo-classes because of the greater flexibility we'll get.

Thanks,
Om

[1] http://people.apache.org/~bigosmallm/fxg2svg/buttonskin/flexVhtml5.html




>
> Mike
>
>
>
>
>
> On Tue, May 19, 2015 at 3:21 PM, OmPrakash Muppirala <bigosma...@gmail.com
> >
> wrote:
>
> > On Tue, May 19, 2015 at 11:29 AM, Michael Schmalle <
> > teotigraphix...@gmail.com> wrote:
> >
> > > Ironically Om, this was my next post! SVG and what are we doing to use
> > it.
> > >
> > > Maybe through all my bable of the last thread some might see where I am
> > > coming from, I am really trying to figure out, what are we building on.
> > >
> > > Now SVG I understand, Canvas I understand.
> > >
> > > Om, what are the pluses and minuses of each paradigm? I was just
> reading
> > > about this today, canvas doesn't have event handlers, svg does.
> > >
> >
> > Canvas is a fire and forget mode of rendering.  Think of Canvas as an
> > equivalent to Flash's BitmapData.  Once you draw on a Canvas, you cannot
> > get access to individual elements without doing a lot of complicated
> > hittests or other kind of hacks.  Moreover, it is a raster object.  So,
> if
> > you draw on a Canvas and resize it up, it gets pixelated.
> >
> > SVG, on the other hand is a retained mode of rendering.  All elements
> drawn
> > in SVG become part of the DOM.  This means that you can do event
> handling,
> > animation, etc. much more easily.  Also, SVG is vector drawing.  So
> drawing
> > in any size and scaling keeps the rendering quality intact.
> >
> > Canvas is generally used for drawing a ton of elements in runtime without
> > needing them to be individually interactive.  SVG is less performant
> > because of the added dom related overhead on each element, and is
> (should)
> > generally used for building interactive UI components (charts, maps,
> etc.)
> >
> >
> > >
> > > FXG -> SVG, is there currently a parser/renderer for this? How were you
> > > planning on doing this.
> > >
> >
> > So, my first approach was to write an FXG to SVG transformer[1]
> stylesheet
> > that I imagined would be invoked by the compiler.  It turns out that
> doing
> > it the 'FlexJS' way was much easier.  Basically, I created the
> primitives -
> > Line, Circle, Path, Fill, Stroke, etc. in the AS side [2] Then, I created
> > their JS equivalents [3] where I draw SVG elements via JavaScript.  That
> is
> > pretty much it.  The MXML/FXG parsing, cross-compilation from AS to JS
> etc.
> > is handled automatically by FlexJS (magic for me ;-) )
> >
> > The idea from here on is that anything you draw on the screen via AS3
> will
> > look exactly the same in Flash vs. HTML/JS.  Here is an example of flash
> > [4] vs html [5]  Put them side by side and see if you can tell the
> > difference :-)
> >
> > The next progression was to build FlexJS charts out of these.  Here is a
> > set of chart components that Peter Ent built on top of this core graphics
> > classes:  Flash [6] vs HTML5[7]  There is a pretty detailed wiki page for
> > these charts [8]
> >
> >
> >
> > >
> > > Is this something we could write that would pretty much cross compile
> to
> > > js?
> > >
> >
> > Yes, I believe we are at a point where things are getting more and more
> > cross-compiled as opposed to be hand-written.  Of course, the beauty is
> > that you can draw in MXML/FXG and you can see a drawing in the JS side.
> > Pretty cool.
> >
> >
> > >
> > > Tell me your ideas, I am very interested in this part.
> > >
> > >
> > My next few TODOs are to build a spark like skinning system in FlexJS.
> > Basically create FXG skins on the AS3 side and mirror them with SVG based
> > skins on the JS side.  Peter has built a small example that will let me
> > play around with event driven, states based skins.  I hope to get on this
> > as soon as I get my Git access back.
> >
> > Of course, the core graphics packages needs more love with things like
> > RadialGradients, and more fancy graphics primitives.
> >
> > After that I would like to tackle animation.  I haven't given a lot of
> > thought into this, so not sure how easy/hard this is going to be.
> >
> > Thanks,
> > Om
> >
> >
> > >
> > >
> > > Mike
> > >
> > >
> > [1] https://github.com/apache/flex-asjs/tree/develop/fxg2svg
> > [2]
> >
> >
> https://github.com/apache/flex-asjs/tree/develop/frameworks/projects/Graphics/as/src/org/apache/flex/core/graphics
> > [3]
> >
> >
> https://github.com/apache/flex-asjs/tree/develop/frameworks/projects/Graphics/js/src/org/apache/flex/core/graphics
> > [4] http://people.apache.org/~bigosmallm/flexjs/drawing/flash/
> > [5] http://people.apache.org/~bigosmallm/flexjs/drawing/html5/
> > [6] http://people.apache.org/~pent/chartswf/
> > [7] http://people.apache.org/~pent/chartjs/
> > [8] https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Charts
> >
> >
> > >
> > > > See this is my problem, Randori was a straight cross compile with
> shims
> > > and
> > > > worked awesome. So all my questions to you are like me "unlearning"
> > what
> > > I
> > > > spent 6+ months working on in that project.
> > > >
> > > > The compiler's emitter just puked out js and we locked in SWCs in the
> > > apps
> > > > that used js API surfaces.
> > > >
> > > > Although, the one thing as you know was Mike disagreed with FlexJS's
> > view
> > > > in ActionScript because he said HTML/CSS designers should just do
> what
> > > they
> > > > do and design in HTML/CSS.
> > > >
> > >
> > > I disagree fundamentally with this idea.  For one, HTML/CSS is a
> terrible
> > > terrible paradigm.  No designer is happy with the way things work
> > today.  I
> > > would rather provide a better way of doing the visuals via MXML+FXG
> (like
> > > we do in Flex's spark skins) and cross compile them over to JS + SVG +
> > > Canvas as needed.
> > >
> > > Even the HTML/JS world is waking up to this idea.  This presentation
> [1]
> > > does a great job of explaining why SVG is better than CSS for
> interfaces
> > > building.  FlexJS is in a great position to provide this out of the box
> > to
> > > developers.
> > >
> > > Thanks,
> > > Om
> > >
> > > [1]
> http://slides.com/sarasoueidan/building-better-interfaces-with-svg#/
> > >
> >
>

Reply via email to