On Mon, Mar 25, 2013 at 8:27 PM, Alex Harui <aha...@adobe.com> wrote:
> > > > Well, first off, thanks for motivating me to spend more time thinking about > skinning. Honestly, I don't have a formal plan and your input is quite > welcome. I spent a fair amount of time mulling over how to re-use as much > of existing spark skins as possible and how to leverage your FXG->SVG work. > Sure. Glad to help wherever I can. > > On 3/25/13 6:28 PM, "Om" <bigosma...@gmail.com> wrote: > > >>> > >> Well, if you want to re-use Spark skins, then FlexJS is not for you. > > > > I don't want to reuse spark skins. I just want to use the spark paradigm > > for skinning. I am using the current spark skins as examples for the > POC. > I'm not sure what it means if you don't want to reuse spark skins but want > to use the spark paradigm. What are the key pieces? > I am comparing that with Halo skinning. That workflow was quite tedious. The key pieces from my point of view would be skins as xml (mxmlg or fxg) instead of drawing skins in actionscript. There are three ways to skin Flex apps with vector graphics - 1. Use FXG/MXMLG, 2. Use SWFs created from Flash Pro 3. Use ActionScript to draw the skins Of the three (1) is great because it lets us use other tools outside the Flash world, i.e. Illustrator, Fireworks, Photoshop (dare I say Catalyst?). This led to a pretty good workflow between the designers and developers. This led to high fidelity because we could always tweak the finer details of a particular graphic even after being passed over to the developers world. This has become our preferred way of skinning. (2) Halo skinning used this approach. While a good option, this meant that designers had to learn a new tool which was not already in their skillset. Moreover, Flash Pro has a bad rap of being pretty bad for vector graphic creation (not my words, I love Flash Pro!) (3) This great for advanced skinning and gives us total control, but it pretty much removes the designer out of the loop. Given a choice, I would choose (1) and then (3) but I dont care much for (2) > > > > > FlexJS > >> is a rewrite of Flex and the skinning model will likely be different > > because > >> I want to try to fix the problems of Spark skins like the skin part > >> contract, the extra display object, and the fact that most default skins > > had > >> code in them. Over time, we can add enough alternative beads to fully > > mimic > >> Spark Skins, but I really don't want to make that the default pattern > for > >> FlexJS. > > > > As long as we use MXMLG for the skins I would be happy. Do you still > plan > > to use MXMLG in FlexJS? > I hadn't given it much thought. At minimum, we could create components > like > Rect, Line, Path like we have for Button, CheckBox and Label. They would > inject SVG into the DOM as appropriate. > > Now that I am looking at the skins more closely, pretty much everything we draw seems to be a rectangle with rounded corners :-) But yes, I agree - a few primitives will go a long way in supporting the current (spark) skinning paradigm. > But in thinking more about it, your transform of MXMLG or FXG to SVG is > essentially an optimization. I would characterize it more as laziness. An XSLT transform is the easiest way to get to our end goal, which is rendering fidelity between the two platforms. > The reason I say that is because, if you start > from SparkSkin, you have the problem that in more complex components, the > skin is not pure MXMLG/FXG, it is comprised of other top-level components. > It is only in cases where you have an uninterrupted stream of graphics that > you can apply this transform. I guess we could make the compiler that > smart, but that sounds like advanced work. > I dont think it needs to be an uninterrupted stream. As I showed in my latest prototype, the XSLT can skip over certain parts of the MXML file which does not interest it. > > One way I think about developing FlexJS is that we are trying to identify > the smallest, most self-contained, best practice for doing things in HTML > (whether it is skinning, drag-drop, effects) and then designing an > ActionScript equivalent for it, and then tweaking both sides to make it > more > Flex-like. At least for now, that is the most efficient way to get more > components up and running faster because there is less mucking around in JS > trying to get it to do something that was easy in Flash. > > So, I need to research more about how skinning works in HTML5, but I have > this vague recollection that skins in HTML5 are entirely graphics. I dont think so. SVG is part of the HTML5 spec now, so what we are doing is completely legitimate. > IOW, a > complex component comprised of subcomponents doesn't have a skin that > describes those sub-components like Spark does. Instead, the set of > sub-components is fixed and you can alter the visuals of those > sub-components via CSS. For example, you use advanced CSS selectors to set > the visuals for a Button in a ComboBox. > This is one thing I wish Flex had better support for. In my FXG -> SVG approach, we should be able to do this (example coming soon). We just need to figure out the stuff on the Flash/AS side. > > I also need to understand how an HTML5 button skin changes its visuals with > hover/down/selected/focused/emphasized. That would also educate how we set > up a skinning model for FlexJS. > Here is an example: http://demos.madeinthenorth.com/slicker-buttons/# Notice how they use SVG in IE9 and CSS3 for Firefox and Webkit. This also shows how to use CSS to control the various states. > > And something like that is more in tune with FlexJS. Today, the AS > components have a view bead that determines the subcomponents. Those > subcomponents have their own view beads. The leaves of that tree of view > beads is entirely graphics (today in AS, next stop for me was bitmaps, you > are welcome to take on MXML or FXG or some vector description). I havent followed your new SDK in a while. Once I am done with the prototypes I am working on, I will get into it. > Someday, > I'll get enough CSS working so that you can set the view beads at the > leaves > of the tree, and then we can say that you can define those view beads > entirely in graphics with certain restrictions, like no sub-components. > Maybe we'll give that a separate file suffix, then the compiler can know to > run your transform on it. > A restriction on skins to not have sub-components would be great IMHO. A new suffix would be great as well. One more modification from our current spark skins would be to perhaps have a HostInterface instead of a HostComponent in skins. Thanks, Om > > Thoughts on that? > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > >
