Ok seeing the fact you were setting the background with an svg element. When you want to start working on this and have a git connection again, let me know, we can hash it out. :)
Mike On Tue, May 19, 2015 at 4:09 PM, OmPrakash Muppirala <bigosma...@gmail.com> wrote: > 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#/ > > > > > > > > > >
