[FlexJS] Skinning (was Re: [FlexJS] How to make the drawing APIs work from MXML)

[Alex Harui <ah...@adobe.com>]

Ah yes, skinning in FlexJS.

The general guidance for doing anything in FlexJS is to first consider
what is possible/practical/popular on the HTML/JS/CSS side, find the
patterns, propose encapsulations, then figure out how to implement that in
AS.

I’ve never promised FlexJS would offer Spark-like skinning because I’m not
sure it is possible or practical in HTML/JS/CSS.  Spark skinning basically
adds a child display object to any component.  I am not convinced you can
do that to the HTML built-in widgets I think most folks will want to use.
FlexJS certainly allows for a component set of widgets written to emulate
the built-in HTML widgets that can have an extra display object child, but
practically speaking, I want to leverage the built-in widgets so we don’t
have to invest time now in debugging emulations of them.  Also, FlexJS
hopes to support other component sets that wrap other UI frameworks like
Jquery and the way to customize the visuals may differ from framework to
framework.

The “basic” FlexJS framework tries to support MVC in most of the
components.  The view bead isn’t an extra display object, it adds display
objects (or sub-components) to the host components that can have
sub-components.  Fine tuning of the visuals is controlled via CSS.  On the
HTML/JS/CSS side, the FlexJS Button doesn’t currently have a view bead
since it just thinly wraps the HTML Button and that’s why fine tuning of
the visuals is controlled via CSS:  I think that’s the only way to alter
the way the HTML Button looks.

The one scenario that I keep thinking of, but haven’t fully explored, is
the “closeable tab”.  FlashBuilder/Eclipse users see it all the time:
there are tabs representing the open files in the source editor, and you
can close a file by hovering over the tab and clicking a close button that
will appear.

I have not researched how this is done in HTML/JS/CSS, but in Flash, folks
tried to do this by adding a button to the tab skin, and the tab is
already a button.  I don’t think you can do this to the default HTML
Button, but I could be wrong, but that’s been a factor in why I don’t
think we can replicate Spark skinning in every component.

So, starting from the HTML/JS/CSS side, what can we do?  We can specify
CSS background-image for lots of things, although IIRC, there are some
flicker issues with SVG background-image in Buttons.  We can specify
sub-components for components that aren’t based on HTML widgets.  And are
different things possible for a component set that is HTML5-only?

If you look at FlexJSJX/src/org/apache/flex/html/beads/TitleBarView.mxml
we can now specify the sub-component in the view in MXML.  IIRC, you still
want to convert FXG to SVG so the AS-side could load FXG and the JS-side
could load SVG.  Or we could just make the AS-side understand SVG and
convert to Graphics commands on the fly.

But fundamentally, I think we now have the ability to specify just about
every visual aspect of a FlexJS app as MXML plus some CSS, but I think the
HTML Button might flicker, and not all MXML will work in all components in
the JS side unless I’m wrong about the "closeable tab” scenario.  Maybe
that means there should be some other default Button in FlexJS and we
should give up on the built-in HTML Button or maybe that’s good enough.

What do other think?

-Alex



On 10/16/14, 2:06 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:

>I have checked in the required changes to support FXG/MXMLG style drawing
>in FlexJS.  I have also updated the chart classes to accommodate for these
>changes so that they continue to work properly.
>
>Next up, figure out how to skin a component in FlexJS!
>
>Thoughts, suggestions?
>
>Thanks,
>Om
>
>On Wed, Oct 15, 2014 at 8:31 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 10/15/14, 2:53 PM, "OmPrakash Muppirala" <bi...@gmail.com>
>>wrote:
>>
>> >
>> >On the JS side, I now have GraphicShape extend UIBase as well.  I added
>> >the
>> >same exact code path as in the AS version.
>> >
>> >We now have FXG like drawing on both Flash and HTML5/SVG with close to
>> >100%
>> >fidelity :-)
>> Sweet!
>>
>> -Alex
>>
>>

Re: [FlexJS] Skinning (was Re: [FlexJS] How to make the drawing APIs work from MXML)

[Harbs <ha...@gmail.com>]

I do. Resizable buttons are critical for localization. The button labels can be drastically different sizes, and the buttons need to resize to fit the different labels.

On Oct 17, 2014, at 8:37 AM, Alex Harui <ah...@adobe.com> wrote:

> One other question: having resizable button skins is great for prototyping
> an application, but how many folks go to production with resizable
> buttons?

Re: [FlexJS] Skinning (was Re: [FlexJS] How to make the drawing APIs work from MXML)

[Alex Harui <ah...@adobe.com>]

On 10/17/14, 4:42 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:

>>
>> (assuming you size it and don’t scale it).
>>
>
>I think this is the key.  Scaling is so much more easier to do than resize
>each and every element.
Maybe I don’t understand what that means.  One of the main benefits of
vector graphics is that the graphics can be redrawn at different sizes
with fewer artifacts than scaling raster graphics.  IMO, Scale-9 is
primarily intended to handle raster graphics (bitmaps).  To me, it would
be a flaw in the system if you couldn’t take advantage of vectors to
handle different sizings.

Flex default skins generally use LTRB to essentially redraw the vectors at
different sizes.  LTRB and % makes the skins more “flex”-ible.

>
>Both on the Flash and the SVG side, the power and flexibility comes from
>the fact that they are inherently scalable.  Your resizing approach would
>entail attaching resize handlers to their containers and redrawing the
>graphic element by element.  Is that what you are proposing?

I don’t have enough data to propose anything other than, in principle, if
you have vectors you should be able to redraw them instead of just plain
scaling them.  A linear gradient fill for a rounded rectangle won’t be
linear after you scale it with scale-9, but maybe most folks don’t care.

I’m wondering how folks use SVG in the HTML/JS/CSS/SVG world with respect
to this resizing issue.  SVG seems to support %.  I guess all the SVG tags
goes in some SVG container.  What happens if you give that SVG container a
new width/height?  Do the vectors get redrawn or scaled?.  If scaled, are
people trying to approximate scale-9 or crying about the fact there is no
good vector resizing option?

It never occurred to me until this thread that FXG, if it in fact doesn’t
support % or LTRB, which it probably doesn’t because I don’t think
DefineShape supports it, was flawed in this way.  It made you treat
vectors like bitmaps when resizing, effectively taking away the advantages
of vectors.

I also don’t know what the authoring tools like Illustrator support, and
whether the designers who use them know how, or are willing to learn how
to do vector resizing.  If folks who create SVG for HTML/JS/CSS/SVG are
using an authoring tool, can they specify % values in the SVG?

It always felt in current Flex that we had “code” skins that were written
by developers and handled vector resizing and allowed designers to create
"code-less" skins that didn’t handle vector resizing.  Maybe we still need
that distinction in FlexJS, but if SVG does support vector resizing and
designers know how to leverage that, we should try to take advantage of
that.  It could remove or severely reduce the need to replicate scale-9 on
the JS side.

Technically, resizing doesn’t truly require resize handlers.  Both Flex
and FlexJS are trying to implement top-down sizing.  The “stage” has a
particular size, and containers often specify their sizes via
“constraints” such as % values or LTRB (and also
horizontalCenter/verticalCenter) instead of numbers.  Some layout looks at
the size and constraints and sets the size of the children.  If those
children specify vectors with relative sizes using % or LTRB or
hCenter/vCenter or data binding, then the binding updates the properties
in the vectors and a simple redrawing of the vectors should apply the
constraints against new values and produce the right result.  The author
of the skins should not need to hook up to resize events; the tags in the
markup, binding expressions and the framework should take care of
everything.

If SVG supports both % and LTRB (I heard it does via CSS?) then we might
want to start with SVG and emulate it in the AS-side of FlexJS.  That’s a
general FlexJS philosophy anyway.  IMO there is no requirement to support
FXG in FlexJS if it is less powerful than SVG.

And of course, I could be wrong, so I definitely want to hear what others
have to say.

-Alex

Re: [FlexJS] Skinning (was Re: [FlexJS] How to make the drawing APIs work from MXML)

[OmPrakash Muppirala <bi...@gmail.com>]

>
> (assuming you size it and don’t scale it).
>

I think this is the key.  Scaling is so much more easier to do than resize
each and every element.

Both on the Flash and the SVG side, the power and flexibility comes from
the fact that they are inherently scalable.  Your resizing approach would
entail attaching resize handlers to their containers and redrawing the
graphic element by element.  Is that what you are proposing?

Thanks,
Om

Re: [FlexJS] Skinning (was Re: [FlexJS] How to make the drawing APIs work from MXML)

[Alex Harui <ah...@adobe.com>]

On 10/17/14, 1:31 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:

>
>Specifying percentages or LTRB does not the solve the problem of
>maintaining the stroke thickness while scaling.  When buttons scale, we
>want the stroke widths to remain same.  That is where 9-slice helps.  If
>not, you will have to specify a stroke width for every scale.
>
>
>Take scroll thumb for an example.  It is a button that one can click and
>move.  At the same time, its height (or width, depending on scrollbar
>direction) should adjust according to the amount of content that is being
>scrolled.  It's skin must have a 9-slice grid defined so that it looks
>good
>at any size.
>
>Thanks,
>Om
Maybe I’ve forgotten how computer graphics work, or I am not being clear
enough.  In MXML, if you specify:

<Rect left=“0” right=“0” top=“0” bottom=“0”>
	<stroke>
		<SolidColorLine thickness=“2” />
	<stroke>
</Rect>

then regardless of the size it is drawn, there will be a two-pixel line
around the rectangle, which is what I think you want (assuming you size it
and don’t scale it).  A scroll thumb would have other logic to center any
“grip” graphics.  

That’s because under the covers, the code will call drawRect(0, 0, width,
height), which I think is what you want.

I would expect SVG to be able to do something similar.


-Alex

Re: [FlexJS] Skinning (was Re: [FlexJS] How to make the drawing APIs work from MXML)

[OmPrakash Muppirala <bi...@gmail.com>]

On Fri, Oct 17, 2014 at 1:31 PM, OmPrakash Muppirala <bi...@gmail.com>
wrote:

> On Thu, Oct 16, 2014 at 10:37 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 10/16/14, 1:04 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>>
>> >On Thu, Oct 16, 2014 at 12:49 PM, Alex Harui <ah...@adobe.com> wrote:
>> >
>> >>
>> >>
>> >> On 10/16/14, 12:30 PM, "OmPrakash Muppirala" <bi...@gmail.com>
>> >>wrote:
>> >>
>> >> >
>> >> >Agreed, there does not have to be just one approach.  Most common use
>> >>of
>> >> >9-slice skinning would be in buttons, scroll bars, title bars, icons,
>> >>etc.
>> >> >It should be possible to add this support in a separate namespace.
>> >> Just curious:  If you have vectors, why do you need 9-slice?  Do you
>> >> really want portions of the vectors to scale differently?
>> >>
>> >>
>> >Yes, that is the usage.  For example, a rounded button with with a corner
>> >radius of 10 can be scaled from 100x30 to 150x30 based on the text.  But,
>> >if we want to maintain the same corner radius of 10, we will need regions
>> >in the skin to indicate which portions can scale and which should not.
>> >This is the kind of scenario where we will want to use 9-slice scaling.
>> >
>> >This way, we can build skin for a 100x30 button, specify the 9-slice
>> >scaling rules and let the framework take care of scaling it to various
>> >sizes.
>> Interesting.  It never occurred to me that FXG didn’t have percentages or
>> other constraints and that’s why folks used 9-slice when resizing.  At
>> least, the spec seems to only allow percentages in a few places.
>> MXML-based skins don’t need 9-slice when resized because you can specify
>> percentages or right/left/top/bottom and the vectors like a rectangle with
>> rounded corners gets re-drawn and keeps its rounded corners.  I think
>> 9-slice can cause subtle artifacts in gradients, so re-drawing the vectors
>> is better.
>>
>> A quick look says that SVG does support percentages.  Not sure if it also
>> supports LTRB, but that would imply to me that folks should be able to
>> specify SVG art that does resize cleanly without 9-slice.
>>
>
> Specifying percentages or LTRB does not the solve the problem of
> maintaining the stroke thickness while scaling.  When buttons scale, we
> want the stroke widths to remain same.  That is where 9-slice helps.  If
> not, you will have to specify a stroke width for every scale.
>
>
>>
>> That said, I don’t know if any tools like Illustrator allow you to specify
>> % or LTRB in SVG output.  But maybe we should give up on FXG and focus on
>> runtime rendering of SVG in Flash.  Or extend FXG to support percentages
>> in more places (although then you can’t compile it into a SWF
>> DefineShape/DefineSprite).  Or just use MXMLG-like syntax like I think you
>> just got working.
>>
>> One other question: having resizable button skins is great for prototyping
>> an application, but how many folks go to production with resizable
>> buttons?  One designer I worked with long ago wanted no more than three
>> sizes of buttons in a UI.  The OK and Cancel buttons would be the same
>> size, no shrinking or growing to fit the text.  In current Flex, the SDK
>> ships with resizable MXML skins, but folks can replace some pieces with
>> not-so-resizable FXG graphics.
>>
>
> Take scroll thumb for an example.  It is a button that one can click and
> move.  At the same time, its height (or width, depending on scrollbar
> direction) should adjust according to the amount of content that is being
> scrolled.  It's skin must have a 9-slice grid defined so that it looks good
> at any size.
>

Also relevant is the use case of supporting multiple screen densities.  We
want to use the same vector assets for a button displayed in each supported
dpi.  For example, you create an asset for 160 dpi and specify its scale
grid.  Then we can scale the asset up for 480 dpi and still show the same
stroke width, rounded corners, etc.  The alternative would be to create
multiple assets for multiple dpis.

Thanks,
Om


>
> Thanks,
> Om
>
>
>>
>>
>> >
>> >
>> >I was thinking of re-purposing the Android
>> >4.x skins as well.  It would be fun to see how an Android-y web app looks
>> >like.
>> And the IOS skins as well.
>>
>> -Alex
>>
>>
>

Re: [FlexJS] Skinning (was Re: [FlexJS] How to make the drawing APIs work from MXML)

[OmPrakash Muppirala <bi...@gmail.com>]

On Thu, Oct 16, 2014 at 10:37 PM, Alex Harui <ah...@adobe.com> wrote:

>
>
> On 10/16/14, 1:04 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >On Thu, Oct 16, 2014 at 12:49 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >>
> >>
> >> On 10/16/14, 12:30 PM, "OmPrakash Muppirala" <bi...@gmail.com>
> >>wrote:
> >>
> >> >
> >> >Agreed, there does not have to be just one approach.  Most common use
> >>of
> >> >9-slice skinning would be in buttons, scroll bars, title bars, icons,
> >>etc.
> >> >It should be possible to add this support in a separate namespace.
> >> Just curious:  If you have vectors, why do you need 9-slice?  Do you
> >> really want portions of the vectors to scale differently?
> >>
> >>
> >Yes, that is the usage.  For example, a rounded button with with a corner
> >radius of 10 can be scaled from 100x30 to 150x30 based on the text.  But,
> >if we want to maintain the same corner radius of 10, we will need regions
> >in the skin to indicate which portions can scale and which should not.
> >This is the kind of scenario where we will want to use 9-slice scaling.
> >
> >This way, we can build skin for a 100x30 button, specify the 9-slice
> >scaling rules and let the framework take care of scaling it to various
> >sizes.
> Interesting.  It never occurred to me that FXG didn’t have percentages or
> other constraints and that’s why folks used 9-slice when resizing.  At
> least, the spec seems to only allow percentages in a few places.
> MXML-based skins don’t need 9-slice when resized because you can specify
> percentages or right/left/top/bottom and the vectors like a rectangle with
> rounded corners gets re-drawn and keeps its rounded corners.  I think
> 9-slice can cause subtle artifacts in gradients, so re-drawing the vectors
> is better.
>
> A quick look says that SVG does support percentages.  Not sure if it also
> supports LTRB, but that would imply to me that folks should be able to
> specify SVG art that does resize cleanly without 9-slice.
>

Specifying percentages or LTRB does not the solve the problem of
maintaining the stroke thickness while scaling.  When buttons scale, we
want the stroke widths to remain same.  That is where 9-slice helps.  If
not, you will have to specify a stroke width for every scale.


>
> That said, I don’t know if any tools like Illustrator allow you to specify
> % or LTRB in SVG output.  But maybe we should give up on FXG and focus on
> runtime rendering of SVG in Flash.  Or extend FXG to support percentages
> in more places (although then you can’t compile it into a SWF
> DefineShape/DefineSprite).  Or just use MXMLG-like syntax like I think you
> just got working.
>
> One other question: having resizable button skins is great for prototyping
> an application, but how many folks go to production with resizable
> buttons?  One designer I worked with long ago wanted no more than three
> sizes of buttons in a UI.  The OK and Cancel buttons would be the same
> size, no shrinking or growing to fit the text.  In current Flex, the SDK
> ships with resizable MXML skins, but folks can replace some pieces with
> not-so-resizable FXG graphics.
>

Take scroll thumb for an example.  It is a button that one can click and
move.  At the same time, its height (or width, depending on scrollbar
direction) should adjust according to the amount of content that is being
scrolled.  It's skin must have a 9-slice grid defined so that it looks good
at any size.

Thanks,
Om


>
>
> >
> >
> >I was thinking of re-purposing the Android
> >4.x skins as well.  It would be fun to see how an Android-y web app looks
> >like.
> And the IOS skins as well.
>
> -Alex
>
>

Re: [FlexJS] Skinning (was Re: [FlexJS] How to make the drawing APIs work from MXML)

[Alex Harui <ah...@adobe.com>]

On 10/16/14, 1:04 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:

>On Thu, Oct 16, 2014 at 12:49 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 10/16/14, 12:30 PM, "OmPrakash Muppirala" <bi...@gmail.com>
>>wrote:
>>
>> >
>> >Agreed, there does not have to be just one approach.  Most common use
>>of
>> >9-slice skinning would be in buttons, scroll bars, title bars, icons,
>>etc.
>> >It should be possible to add this support in a separate namespace.
>> Just curious:  If you have vectors, why do you need 9-slice?  Do you
>> really want portions of the vectors to scale differently?
>>
>>
>Yes, that is the usage.  For example, a rounded button with with a corner
>radius of 10 can be scaled from 100x30 to 150x30 based on the text.  But,
>if we want to maintain the same corner radius of 10, we will need regions
>in the skin to indicate which portions can scale and which should not.
>This is the kind of scenario where we will want to use 9-slice scaling.
>
>This way, we can build skin for a 100x30 button, specify the 9-slice
>scaling rules and let the framework take care of scaling it to various
>sizes.
Interesting.  It never occurred to me that FXG didn’t have percentages or
other constraints and that’s why folks used 9-slice when resizing.  At
least, the spec seems to only allow percentages in a few places.
MXML-based skins don’t need 9-slice when resized because you can specify
percentages or right/left/top/bottom and the vectors like a rectangle with
rounded corners gets re-drawn and keeps its rounded corners.  I think
9-slice can cause subtle artifacts in gradients, so re-drawing the vectors
is better.

A quick look says that SVG does support percentages.  Not sure if it also
supports LTRB, but that would imply to me that folks should be able to
specify SVG art that does resize cleanly without 9-slice.

That said, I don’t know if any tools like Illustrator allow you to specify
% or LTRB in SVG output.  But maybe we should give up on FXG and focus on
runtime rendering of SVG in Flash.  Or extend FXG to support percentages
in more places (although then you can’t compile it into a SWF
DefineShape/DefineSprite).  Or just use MXMLG-like syntax like I think you
just got working.

One other question: having resizable button skins is great for prototyping
an application, but how many folks go to production with resizable
buttons?  One designer I worked with long ago wanted no more than three
sizes of buttons in a UI.  The OK and Cancel buttons would be the same
size, no shrinking or growing to fit the text.  In current Flex, the SDK
ships with resizable MXML skins, but folks can replace some pieces with
not-so-resizable FXG graphics.


>
>
>I was thinking of re-purposing the Android
>4.x skins as well.  It would be fun to see how an Android-y web app looks
>like.
And the IOS skins as well.

-Alex

Re: [FlexJS] Skinning (was Re: [FlexJS] How to make the drawing APIs work from MXML)

[OmPrakash Muppirala <bi...@gmail.com>]

On Thu, Oct 16, 2014 at 12:49 PM, Alex Harui <ah...@adobe.com> wrote:

>
>
> On 10/16/14, 12:30 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >
> >Agreed, there does not have to be just one approach.  Most common use of
> >9-slice skinning would be in buttons, scroll bars, title bars, icons, etc.
> >It should be possible to add this support in a separate namespace.
> Just curious:  If you have vectors, why do you need 9-slice?  Do you
> really want portions of the vectors to scale differently?
>
>
Yes, that is the usage.  For example, a rounded button with with a corner
radius of 10 can be scaled from 100x30 to 150x30 based on the text.  But,
if we want to maintain the same corner radius of 10, we will need regions
in the skin to indicate which portions can scale and which should not.
This is the kind of scenario where we will want to use 9-slice scaling.

This way, we can build skin for a 100x30 button, specify the 9-slice
scaling rules and let the framework take care of scaling it to various
sizes.

This tutorial [1] gives a nice, visual explanation.

[1] http://www.sephiroth.it/tutorials/flashPHP/scale9/


> >
> >I think a very good looking default theme for FlexJS which can be
> >customized easily  (like Spark) is a good way to go.
> I was expecting we'd use FlatSpark as the theme.
>

I will try to start with that.  I was thinking of re-purposing the Android
4.x skins as well.  It would be fun to see how an Android-y web app looks
like.

Thanks,
Om


>
> -Alex
>
>

Re: [FlexJS] Skinning (was Re: [FlexJS] How to make the drawing APIs work from MXML)

[Alex Harui <ah...@adobe.com>]

On 10/16/14, 12:30 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:

>
>Agreed, there does not have to be just one approach.  Most common use of
>9-slice skinning would be in buttons, scroll bars, title bars, icons, etc.
>It should be possible to add this support in a separate namespace.
Just curious:  If you have vectors, why do you need 9-slice?  Do you
really want portions of the vectors to scale differently?

>
>I think a very good looking default theme for FlexJS which can be
>customized easily  (like Spark) is a good way to go.
I was expecting we'd use FlatSpark as the theme.

-Alex

Re: [FlexJS] Skinning (was Re: [FlexJS] How to make the drawing APIs work from MXML)

[OmPrakash Muppirala <bi...@gmail.com>]

On Thu, Oct 16, 2014 at 12:03 PM, Alex Harui <ah...@adobe.com> wrote:

> Thanks for that info on Jquery and Dojo.  Do they have skinning models?
> How does it work?
>
>
Styling is strictly through CSS.  There are no other skinning model, per
se.


> More inline..
>
>
> On 10/16/14, 11:29 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >I understand that you want to use the default HTML elements as building
> >blocks.  I think there are major problems with this approach.
> >
> >In essence, we have a very limited set of default HTML elements to start
> >with.  If we want to compose our entire application with these, we will
> >quickly run into cases where we need more complex base components.
> Agreed, and in FlexJS today, we have already composed some higher-level
> components.  There  is a List that just wraps <select> and another one
> that supports item renderers that doesn’t use <select>.
>
> >
> >There are some scenarios where SVG is not good enough for us.  For
> >example,
> >9-slice scaling.  SVG does not support this flat out.  Whereas, there is a
> >way to hack 9-slice skinning using SVG and ForeignObjects.  But none of
> >the
> >drawing tools (Illustrator, Flash Pro or Incscape) support this hack.
> >I plan to interpret the 9-slice attributes (exported from AI, for example)
> >and draw the svg/foreignobject combinations on the JS side.  On the flash
> >side, 9-slice skinning is supported built in.
> >
> >Also, loading SVG instead of drawing it using JS brings its own set of
> >challenges.  I feel drawing SVG using JS is a better approach.
> Sounds reasonable.  There doesn’t have to be one approach.  Different
> component sets can implement different approaches.  Question:  How many
> apps need 9-slice and what will it cost to support it?  In the FlexJS
> pay-as-you-go philosophy, there could be a component set that doesn’t
> support 9-slice if the net result is smaller downloads or better
> performance because the FXG is pre-compiled in SVG and not re-interpreted
> at runtime.
>

Agreed, there does not have to be just one approach.  Most common use of
9-slice skinning would be in buttons, scroll bars, title bars, icons, etc.
It should be possible to add this support in a separate namespace.


>
> >
> >
> >>
> >> But fundamentally, I think we now have the ability to specify just about
> >> every visual aspect of a FlexJS app as MXML plus some CSS, but I think
> >>the
> >> HTML Button might flicker, and not all MXML will work in all components
> >>in
> >> the JS side unless I’m wrong about the "closeable tab” scenario.  Maybe
> >> that means there should be some other default Button in FlexJS and we
> >> should give up on the built-in HTML Button or maybe that’s good enough.
> >>
> >
> >Yes, IMHO, we should give up on the build-in HTML button.  That is good
> >for
> >simple websites, not as a building block for complex applications.
> If it is good enough for simple web sites, then we should probably have a
> component set that supports it.  Originally, I had put the current set
> under a “staticControls” folder thinking they wouldn’t support any
> customization of the sub-components, and called this “basic”, but slowly
> we added some customization.  Then I moved them out of staticControls into
> just org/apache/flex/html
>
> Maybe it is time to start a different, richer component set under
> “skinnable” or in a different swc with different package names
> (org/apache/flex/skinnable) where the JS-side does not use the built-in
> elements and move some of the current components that don’t use the HTML
> elements into that set.
>

Yes, 'skinnable' is the exact namespace I was thinking of too.  I will work
on the set up and share the progress soon.


>
> Someday, I or someone will get around to breaking the Jquery components
> into their own SWC.  Same for Cordova and CreateJS.  So having more than
> one SWC of components needs to work.  We want to offer choices since some
> folks are bound to certain UI libraries.  The main benefit of FlexJS is
> using MXML and AS to glue the components together more quickly and
> reliably.  And if folks can who aren’t bound to a particular toolkit can
> get better and faster visual customization via our toolchain and markup,
> even better.
>

I think a very good looking default theme for FlexJS which can be
customized easily  (like Spark) is a good way to go.

Thanks,
Om


>
> -Alex
>
>

Re: [FlexJS] Skinning (was Re: [FlexJS] How to make the drawing APIs work from MXML)

[Alex Harui <ah...@adobe.com>]

Thanks for that info on Jquery and Dojo.  Do they have skinning models?
How does it work?

More inline..


On 10/16/14, 11:29 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:

>I understand that you want to use the default HTML elements as building
>blocks.  I think there are major problems with this approach.
>
>In essence, we have a very limited set of default HTML elements to start
>with.  If we want to compose our entire application with these, we will
>quickly run into cases where we need more complex base components.
Agreed, and in FlexJS today, we have already composed some higher-level
components.  There  is a List that just wraps <select> and another one
that supports item renderers that doesn’t use <select>.

>
>There are some scenarios where SVG is not good enough for us.  For
>example,
>9-slice scaling.  SVG does not support this flat out.  Whereas, there is a
>way to hack 9-slice skinning using SVG and ForeignObjects.  But none of
>the
>drawing tools (Illustrator, Flash Pro or Incscape) support this hack.
>I plan to interpret the 9-slice attributes (exported from AI, for example)
>and draw the svg/foreignobject combinations on the JS side.  On the flash
>side, 9-slice skinning is supported built in.
>
>Also, loading SVG instead of drawing it using JS brings its own set of
>challenges.  I feel drawing SVG using JS is a better approach.
Sounds reasonable.  There doesn’t have to be one approach.  Different
component sets can implement different approaches.  Question:  How many
apps need 9-slice and what will it cost to support it?  In the FlexJS
pay-as-you-go philosophy, there could be a component set that doesn’t
support 9-slice if the net result is smaller downloads or better
performance because the FXG is pre-compiled in SVG and not re-interpreted
at runtime.

>
>
>>
>> But fundamentally, I think we now have the ability to specify just about
>> every visual aspect of a FlexJS app as MXML plus some CSS, but I think
>>the
>> HTML Button might flicker, and not all MXML will work in all components
>>in
>> the JS side unless I’m wrong about the "closeable tab” scenario.  Maybe
>> that means there should be some other default Button in FlexJS and we
>> should give up on the built-in HTML Button or maybe that’s good enough.
>>
>
>Yes, IMHO, we should give up on the build-in HTML button.  That is good
>for
>simple websites, not as a building block for complex applications.
If it is good enough for simple web sites, then we should probably have a
component set that supports it.  Originally, I had put the current set
under a “staticControls” folder thinking they wouldn’t support any
customization of the sub-components, and called this “basic”, but slowly
we added some customization.  Then I moved them out of staticControls into
just org/apache/flex/html

Maybe it is time to start a different, richer component set under
“skinnable” or in a different swc with different package names
(org/apache/flex/skinnable) where the JS-side does not use the built-in
elements and move some of the current components that don’t use the HTML
elements into that set.

Someday, I or someone will get around to breaking the Jquery components
into their own SWC.  Same for Cordova and CreateJS.  So having more than
one SWC of components needs to work.  We want to offer choices since some
folks are bound to certain UI libraries.  The main benefit of FlexJS is
using MXML and AS to glue the components together more quickly and
reliably.  And if folks can who aren’t bound to a particular toolkit can
get better and faster visual customization via our toolchain and markup,
even better.

-Alex

Re: [FlexJS] Skinning (was Re: [FlexJS] How to make the drawing APIs work from MXML)

[OmPrakash Muppirala <bi...@gmail.com>]

I understand that you want to use the default HTML elements as building
blocks.  I think there are major problems with this approach.

First of all, there are only a small set of default input types UI elements:
button, checkbox, radio and text.

HTML5 adds a few more UI elements:
color, date, datetime, datetime-local, month, week, time, email, number,
range, search, tel, and url.

None of the new HTML5 elements work cross-browser.  Most cases, even Chrome
and Firefox don't support it, leave alone IE and Safari.

In essence, we have a very limited set of default HTML elements to start
with.  If we want to compose our entire application with these, we will
quickly run into cases where we need more complex base components.

Second, if we want to look around for commonly used patterns, we can
quickly find that default HTML elements are not sufficient to build real
applications.  As an example, this is how two of the most popular
JavaScript component libraries build their buttons.  All this for nothing
but a button:

*Default Button in Dojo*  (Not showing all the CSS styles)

<span class="dijitReset dijitInline dijitButtonNode"
data-dojo-attach-event="ondijitclick:__onClick" role="presentation">
    <span style="-moz-user-select: none;" id="progButtonNode" tabindex="0"
class="dijitReset dijitStretch dijitButtonContents"
data-dojo-attach-point="titleNode,focusNode" role="button"
aria-labelledby="progButtonNode_label">
        <span class="dijitReset dijitInline dijitIcon dijitNoIcon"
data-dojo-attach-point="iconNode"></span><span class="dijitReset
dijitToggleButtonIconChar">●</span>
        <span class="dijitReset dijitInline dijitButtonText"
id="progButtonNode_label" data-dojo-attach-point="containerNode">Click
me!</span>
    </span>
</span>
<input value="" class="dijitOffScreen"
data-dojo-attach-event="onclick:_onClick" tabindex="-1" role="presentation"
aria-hidden="true" data-dojo-attach-point="valueNode" type="button">

*Icon Button in jQuery* (Not showing all the CSS styles)

<button class="ui-button ui-widget ui-state-default ui-corner-all
ui-button-text-icon-primary" role="button">
    <span class="ui-button-icon-primary ui-icon ui-icon-locked"></span>
    <span class="ui-button-text">
        Button with icon on the left
    </span>
</button>


Now coming to the approach of using SVG to define the skins.  I have looked
around and not too many examples of this approach.  I believe it is because
of the fact that cross browser SVG support was late to arrive and people
have not experimented with this idea much.

(Continuing inline...)

On Thu, Oct 16, 2014 at 8:59 AM, Alex Harui <ah...@adobe.com> wrote:

> Ah yes, skinning in FlexJS.
>
> The general guidance for doing anything in FlexJS is to first consider
> what is possible/practical/popular on the HTML/JS/CSS side, find the
> patterns, propose encapsulations, then figure out how to implement that in
> AS.
>
> I’ve never promised FlexJS would offer Spark-like skinning because I’m not
> sure it is possible or practical in HTML/JS/CSS.  Spark skinning basically
> adds a child display object to any component.  I am not convinced you can
> do that to the HTML built-in widgets I think most folks will want to use.
> FlexJS certainly allows for a component set of widgets written to emulate
> the built-in HTML widgets that can have an extra display object child, but
> practically speaking, I want to leverage the built-in widgets so we don’t
> have to invest time now in debugging emulations of them.  Also, FlexJS
> hopes to support other component sets that wrap other UI frameworks like
> Jquery and the way to customize the visuals may differ from framework to
> framework.
>
> The “basic” FlexJS framework tries to support MVC in most of the
> components.  The view bead isn’t an extra display object, it adds display
> objects (or sub-components) to the host components that can have
> sub-components.  Fine tuning of the visuals is controlled via CSS.  On the
> HTML/JS/CSS side, the FlexJS Button doesn’t currently have a view bead
> since it just thinly wraps the HTML Button and that’s why fine tuning of
> the visuals is controlled via CSS:  I think that’s the only way to alter
> the way the HTML Button looks.
>

Yes, using CSS is the only way to alter a HTML button's look and feel.
Which is why most component libraries compose a button from scratch using
divs and spans (as shown above)



>
> The one scenario that I keep thinking of, but haven’t fully explored, is
> the “closeable tab”.  FlashBuilder/Eclipse users see it all the time:
> there are tabs representing the open files in the source editor, and you
> can close a file by hovering over the tab and clicking a close button that
> will appear.
>
> I have not researched how this is done in HTML/JS/CSS, but in Flash, folks
> tried to do this by adding a button to the tab skin, and the tab is
> already a button.  I don’t think you can do this to the default HTML
> Button, but I could be wrong, but that’s been a factor in why I don’t
> think we can replicate Spark skinning in every component.
>

Yes, these kind of scenarios are exactly why relying on the simple HTML
button elements won't work for us.

*In jQuery:*

<div class="ui-dialog ui-widget ui-widget-content ui-corner-all ui-front
ui-draggable ui-resizable" style="position: absolute; height: 152px; width:
303px; top: 28px; left: 166px; display: block;" tabindex="-1" role="dialog"
aria-describedby="dialog" aria-labelledby="ui-id-1">
    <div class="ui-dialog-titlebar ui-widget-header ui-corner-all
ui-helper-clearfix ui-draggable-handle">
        <span id="ui-id-1" class="ui-dialog-title"></span>
        <button class="ui-button ui-widget ui-state-default ui-corner-all
ui-button-icon-only ui-dialog-titlebar-close" type="button" role="button"
title="Close"></button>
    </div>
    <div id="dialog" class="ui-dialog-content ui-widget-content"
style="width: 281px; min-height: 107px; max-height: none; height:
115px;"></div>
</div>

*In Dojo:*

<div id="dijit_Dialog_0" class="dijitDialog dijitDialogFocused
dijitFocused" aria-labelledby="dijit_Dialog_0_title" role="dialog"
style="width: 300px; position: absolute; opacity: 1; left: 199px; top:
163px; z-index: 950;" widgetid="dijit_Dialog_0">
    <div class="dijitDialogTitleBar" data-dojo-attach-point="titleBar">
        <span id="dijit_Dialog_0_title" class="dijitDialogTitle" level="1"
role="heading" data-dojo-attach-point="titleNode"></span>
        <span class="dijitDialogCloseIcon" tabindex="-1" role="button"
title="Cancel" data-dojo-attach-event="ondijitclick: onCancel"
data-dojo-attach-point="closeButtonNode"></span>
    </div>
    <div class="dijitDialogPaneContent"
data-dojo-attach-point="containerNode"></div>
</div>




>
> So, starting from the HTML/JS/CSS side, what can we do?  We can specify
> CSS background-image for lots of things, although IIRC, there are some
> flicker issues with SVG background-image in Buttons.  We can specify
> sub-components for components that aren’t based on HTML widgets.  And are
> different things possible for a component set that is HTML5-only?
>

The flicker shows up in a specific setup.  I was able to overcome this by
doing things differently.  Here are a couple of example that I put up a
while ago that shows that it is possible:
http://people.apache.org/~bigosmallm/fxg2svg/buttonskin/flexVhtml5.html
http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/embedButtons.html



>
> If you look at FlexJSJX/src/org/apache/flex/html/beads/TitleBarView.mxml
> we can now specify the sub-component in the view in MXML.  IIRC, you still
> want to convert FXG to SVG so the AS-side could load FXG and the JS-side
> could load SVG.  Or we could just make the AS-side understand SVG and
> convert to Graphics commands on the fly.
>

There are some scenarios where SVG is not good enough for us.  For example,
9-slice scaling.  SVG does not support this flat out.  Whereas, there is a
way to hack 9-slice skinning using SVG and ForeignObjects.  But none of the
drawing tools (Illustrator, Flash Pro or Incscape) support this hack.
I plan to interpret the 9-slice attributes (exported from AI, for example)
and draw the svg/foreignobject combinations on the JS side.  On the flash
side, 9-slice skinning is supported built in.

Also, loading SVG instead of drawing it using JS brings its own set of
challenges.  I feel drawing SVG using JS is a better approach.


>
> But fundamentally, I think we now have the ability to specify just about
> every visual aspect of a FlexJS app as MXML plus some CSS, but I think the
> HTML Button might flicker, and not all MXML will work in all components in
> the JS side unless I’m wrong about the "closeable tab” scenario.  Maybe
> that means there should be some other default Button in FlexJS and we
> should give up on the built-in HTML Button or maybe that’s good enough.
>

Yes, IMHO, we should give up on the build-in HTML button.  That is good for
simple websites, not as a building block for complex applications.  As
evidenced by the design choices of the popular JS UI libraries like jQuery
and Dojo.


> What do other think?
>
>
I would love to hear what others think of this problem.

Thanks,
Om



> -Alex
>
>
>
> On 10/16/14, 2:06 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >I have checked in the required changes to support FXG/MXMLG style drawing
> >in FlexJS.  I have also updated the chart classes to accommodate for these
> >changes so that they continue to work properly.
> >
> >Next up, figure out how to skin a component in FlexJS!
> >
> >Thoughts, suggestions?
> >
> >Thanks,
> >Om
> >
> >On Wed, Oct 15, 2014 at 8:31 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >>
> >>
> >> On 10/15/14, 2:53 PM, "OmPrakash Muppirala" <bi...@gmail.com>
> >>wrote:
> >>
> >> >
> >> >On the JS side, I now have GraphicShape extend UIBase as well.  I added
> >> >the
> >> >same exact code path as in the AS version.
> >> >
> >> >We now have FXG like drawing on both Flash and HTML5/SVG with close to
> >> >100%
> >> >fidelity :-)
> >> Sweet!
> >>
> >> -Alex
> >>
> >>
>
>