Re: Flex2Royale

[OmPrakash Muppirala]

The biggest problem with FXG is that there are no editors that support it.

I kept using Illustrator CS5 for creating all my assets.  While I don't
have a problem with that or a need to upgrade to the latest version, it
will be hard to ask users to use that version for their FlexJS/Royale
skinning needs.  Adobe makes it very hard for people to find and download
those versions as well.

Going forward, CSS3 and SVG would be a very good alternative for us.  It is
widely supported and easy for our users to incorporate in their workflow.

Thanks,
Om

On Oct 16, 2017 9:05 AM, "Alex Harui"  wrote:

> IIRC, Om was working on this to some degree.  One plan was to convert FXG
> to SVG.
>
> AIUI, a SkinnableContainer wouldn't be that hard.  Container already has
> an inner div to hold the children, so a different view could have the
> outer div display SVG behind the children.  I think there were more
> questions about SkinnableComponent because not every component is already
> implemented to support a skin by default, and SVG as a backgroundImage for
> some HTMLElements don't work well in all browsers.
>
> Flex Skinning was pretty expensive because it added a UIComponent child to
> every component.  Because we are PAYG, we don't want to force that on
> everyone, and as the MDL work showed, CSS Themes may be just as good at
> creating nice visual experiences and more standard/common.  But as Yishay
> said, in theory, a new set of views could add that extra DIV behind each
> component if that's what it takes to implement SVG "skins".  And we also
> know from MDL and Flat that we can also just re-factor components into
> enough pieces that they can have a different look.
>
> Of course, I could be wrong...
> -Alex
>
> On 10/16/17, 6:50 AM, "Peter Ent"  wrote:
>
> >We need to have a "skinning story" - something about alternate views, CSS,
> >that sort of thing. Adding to my list.
> >‹peter
> >
> >On 10/16/17, 2:29 AM, "yishayw"  wrote:
> >
> >>I like it.
> >>
> >>
> >>> There is no direct equivalent of SkinnableContainer in Royale (at this
> >>> time). A reasonable alternative is the Container.
> >>
> >>Maybe we could mention that Royale components typically have views which
> >>can
> >>be used to control appearance without changing behavior. To me, spark
> >>skins
> >>sort of played the same role.
> >>
> >>
> >>
> >>--
> >>Sent from:
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fapache-ro
> >>y
> >>ale-development.20373.n8.nabble.com%2F=02%7C01%7C%
> 7C1f660ab8e3b74b1c
> >>a
> >>0b108d5145f4fd8%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636437321952
> >>4
> >>70504=ueXDGjTEy4hq0kzF9w1P3utRy%2B805PEm54F7P9ZceZ8%3D=0
> >
>
>

Re: Flex2Royale

[Alex Harui]

Hi Carlos,

I agree that themes like in Flex would be very attractive.  I'm not sure
it belongs in Express.  Express is a pre-composition of Basic which is
tuned to use CSS for visual customization.  For example, Express and Basic
Checkbox is an HTMLInputElement.

I think we learned in the MDL and Flat work that a Basic/Express CheckBox
cannot be fully visually customized, and so the Flat/Bootstrap folks
re-composed their CheckBox as a tree of HTMLElements.  Didn't you have to
do that for MDL as well?  I'm not sure the topology of the MDL and
Flat/Bootstrap Checkboxes are the same or need to be the same.
Flat/Bootstrap uses a custom icon font, for example.  But for PAYG
reasons, we don't want the Basic/Express Checkboxes to carry around that
topology.  That's why we want to support a variety of component sets.

A Skinnable Component set would probably choose some topology for its
controls and all themes would have to be implemented as customizations of
those topologies.  I think that might still require an extra wrapping DIV,
which would be pretty much like the extra UIComponent for each component
skin, but that might be the price you pay for generic vector
customization.  All we need is a volunteer to try to make it work.  I know
Om was interested, but not sure how available he is.  Peter will let us
know if he's interested.

IMO, the most efficient way to do this is to first decide on how to
implement this in pure HTML/JS/CSS/SVG.  So maybe start a new thread and
make sure we have general consensus that SVG is going to be the choice for
now (as opposed to bitmaps, or some other graphics API like Canvas, WebGL,
etc).  Then, without Royale, manually build a small set of "components" in
pure HTML/JS/CSS that you can customize by swapping in just what SVG each
component is supposed to use.  You shouldn't need any infrastructure from
others to do that.  The goal is just to prove that you can create visuals
separately from a component's HTMLElement topology, and then we can see
what the "change points" are when swapping and then we can see how that
matches up against our tooling.  IOW, I think we want to see how good two
different themes look and how small the differences between themes can be
before we invest in infrastructure/tooling.  We may learn that SVG sucks
and we need to instead require Canvas to do skinning, and I think you can
find that out just with your current web development tools.

My 2 cents,
-Alex


On 10/16/17, 10:02 AM, "carlos.rov...@gmail.com on behalf of Carlos
Rovira"  wrote:

>Hi Alex,
>
>I think the piece that is still missing is "themeing". We created some
>subset based on external frameworks (MDL, CreateJS,...), but I always said
>this was only as an exercise and to fill a gap we have with our custom UI
>set. For me all efforts should go in the Express set direction to have one
>set and many "themes". external UI sets will always work differently and
>have their own controls (that will not match ours in many cases) and for
>this reason themeing is not standarizable.
>
>In the other hand Flex Skins was something very powerful, and I think we
>should not lose that in Royale, so Royale could end declaring skins in a
>similar way as Flex did, but implementing in a better way that provides
>better performance. the generated code in HTML/JS could be far way simple
>that in Flex that need a complete UIComponent that means a huge object to
>deal with it at runtime.
>
>I'd love to work in the visuals of themeing for Express when finish royale
>website if some theme infrastructure is setup. IMHO, for this to be done,
>we will need at least be two contributors, maybe Peter or you and me with
>the visuals. I could work in two visuals to put the themeing feature on
>the
>plate, one could be wireframe theme and another something more elaborated.
>
>
>
>
>2017-10-16 18:04 GMT+02:00 Alex Harui :
>
>> IIRC, Om was working on this to some degree.  One plan was to convert
>>FXG
>> to SVG.
>>
>> AIUI, a SkinnableContainer wouldn't be that hard.  Container already has
>> an inner div to hold the children, so a different view could have the
>> outer div display SVG behind the children.  I think there were more
>> questions about SkinnableComponent because not every component is
>>already
>> implemented to support a skin by default, and SVG as a backgroundImage
>>for
>> some HTMLElements don't work well in all browsers.
>>
>> Flex Skinning was pretty expensive because it added a UIComponent child
>>to
>> every component.  Because we are PAYG, we don't want to force that on
>> everyone, and as the MDL work showed, CSS Themes may be just as good at
>> creating nice visual experiences and more standard/common.  But as
>>Yishay
>> said, in theory, a new set of views could add that extra DIV behind each
>> component if that's what it takes to implement SVG "skins".  And we also
>> know from MDL and Flat that we can 

Re: Flex2Royale

[Carlos Rovira]

Hi Alex,

I think the piece that is still missing is "themeing". We created some
subset based on external frameworks (MDL, CreateJS,...), but I always said
this was only as an exercise and to fill a gap we have with our custom UI
set. For me all efforts should go in the Express set direction to have one
set and many "themes". external UI sets will always work differently and
have their own controls (that will not match ours in many cases) and for
this reason themeing is not standarizable.

In the other hand Flex Skins was something very powerful, and I think we
should not lose that in Royale, so Royale could end declaring skins in a
similar way as Flex did, but implementing in a better way that provides
better performance. the generated code in HTML/JS could be far way simple
that in Flex that need a complete UIComponent that means a huge object to
deal with it at runtime.

I'd love to work in the visuals of themeing for Express when finish royale
website if some theme infrastructure is setup. IMHO, for this to be done,
we will need at least be two contributors, maybe Peter or you and me with
the visuals. I could work in two visuals to put the themeing feature on the
plate, one could be wireframe theme and another something more elaborated.




2017-10-16 18:04 GMT+02:00 Alex Harui :

> IIRC, Om was working on this to some degree.  One plan was to convert FXG
> to SVG.
>
> AIUI, a SkinnableContainer wouldn't be that hard.  Container already has
> an inner div to hold the children, so a different view could have the
> outer div display SVG behind the children.  I think there were more
> questions about SkinnableComponent because not every component is already
> implemented to support a skin by default, and SVG as a backgroundImage for
> some HTMLElements don't work well in all browsers.
>
> Flex Skinning was pretty expensive because it added a UIComponent child to
> every component.  Because we are PAYG, we don't want to force that on
> everyone, and as the MDL work showed, CSS Themes may be just as good at
> creating nice visual experiences and more standard/common.  But as Yishay
> said, in theory, a new set of views could add that extra DIV behind each
> component if that's what it takes to implement SVG "skins".  And we also
> know from MDL and Flat that we can also just re-factor components into
> enough pieces that they can have a different look.
>
> Of course, I could be wrong...
> -Alex
>
> On 10/16/17, 6:50 AM, "Peter Ent"  wrote:
>
> >We need to have a "skinning story" - something about alternate views, CSS,
> >that sort of thing. Adding to my list.
> >‹peter
> >
> >On 10/16/17, 2:29 AM, "yishayw"  wrote:
> >
> >>I like it.
> >>
> >>
> >>> There is no direct equivalent of SkinnableContainer in Royale (at this
> >>> time). A reasonable alternative is the Container.
> >>
> >>Maybe we could mention that Royale components typically have views which
> >>can
> >>be used to control appearance without changing behavior. To me, spark
> >>skins
> >>sort of played the same role.
> >>
> >>
> >>
> >>--
> >>Sent from:
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fapache-ro
> >>y
> >>ale-development.20373.n8.nabble.com%2F=02%7C01%7C%
> 7C1f660ab8e3b74b1c
> >>a
> >>0b108d5145f4fd8%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636437321952
> >>4
> >>70504=ueXDGjTEy4hq0kzF9w1P3utRy%2B805PEm54F7P9ZceZ8%3D=0
> >
>
>


-- 



Carlos Rovira

Director General

M: +34 607 22 60 05

http://www.codeoscopic.com


Conocenos Avant2 en 1 minuto! 


Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.

Re: [royale-asjs] 05/09: another sweep of flex replaced by royale per Issue #17. This is hard because we use 'flex' in 'flexUnit' and in flex box css properties

[Piotr Zarzycki]

My point is that we should leave those scripts as is for now. Till the
moment when we have rename merged and we will try Royale in Moonshine and
eventually Josh pickup it in VSCode.

If it is already renamed - try to get back to the old, raise an issue for
change it later and let's move forward.

Piotr

On Mon, Oct 16, 2017, 18:18 Alex Harui  wrote:

> IMO, if we are ok having files with the name 'flex' in it, why bother
> duplicating the information in a 'royale' file?  VSCode and Moonshine are
> under active development and could change (and maybe want to).
>
> An alternative would be to have one or two scripts that transform a Royale
> SDK to make it compatible with older Flex IDEs.  I think we're going to
> need one anyway for Flash Builder.  Yes, those script names might have
> 'flex' in the name (ConvertToFlexSDK.xml) but it makes it appear more like
> a backward compatibility thing than a "we currently use flex" thing.
>
> My 2 cents,
> -Alex
>
> On 10/16/17, 4:13 AM, "Piotr Zarzycki"  wrote:
>
> >+1 for having both. The same could be with flex-config.xml - We could have
> >both.
> >
> >Piotr
> >
> >On Mon, Oct 16, 2017, 12:23 Harbs  wrote:
> >
> >> The VS Code extension requires flex-sdk-description too.
> >>
> >> I think we should include both flex-sdk-description and
> >> royale-sdk-description for now. We can deprecate flex-sdk-description at
> >> some point in the future, but I think we should try and make the
> >>migration
> >> as painless as possible for now.
> >>
> >> Harbs
> >>
> >> > On Oct 16, 2017, at 1:29 AM, Alex Harui 
> >> wrote:
> >> >
> >> > Pretty sure that Flash Builder will be looking for
> >> > flex-sdk-description.xml.
> >> >
> >> > It might be that Flash Builder users will have to run an Ant script to
> >> > fully set up their SDKs and we could use that to rename a
> >> > royale-sdk-description file.
> >> >
> >> > Thoughts?
> >> > -Alex
> >> >
> >> > On 10/14/17, 1:58 PM, "Harbs"  wrote:
> >> >
> >> >> There is a mismatch in this file:
> >> >>
> >> >> 
> >> >> Apache Flex ${project.version} FP${flash.version}
> >> >> AIR${air.version} en_US
> >> >> 
> >> >> 
> >> >> 4.8.${project.version}
> >> >> ${timestamp}
> >> >> 
> >> >>
> >> >> I’m not sure which is a mistake, but eh opening tag of
> >> >> flex-sdk-description does not match the closing tag of
> >> >> royale-sdk-description
> >> >>
> >> >> I’m wondering whether Flash Builder will recognize
> >> royale-sdk-description.
> >> >>
> >> >> Harbs
> >> >>
> >> >>> On Oct 7, 2017, at 12:21 AM, aha...@apache.org wrote:
> >> >>>
> >> >>> diff --git
> >>a/distribution/src/main/resources/flex-sdk-description.xml
> >> >>> b/distribution/src/main/resources/flex-sdk-description.xml
> >> >>> index a4bf265..099982c 100644
> >> >>> --- a/distribution/src/main/resources/flex-sdk-description.xml
> >> >>> +++ b/distribution/src/main/resources/flex-sdk-description.xml
> >> >>> @@ -23,4 +23,4 @@
> >> >>> 
> >> >>> 4.8.${project.version}
> >> >>> ${timestamp}
> >> >>> -
> >> >>> +
> >> >>
> >> >
> >>
> >>
>
>

Re: [royale-asjs] 05/09: another sweep of flex replaced by royale per Issue #17. This is hard because we use 'flex' in 'flexUnit' and in flex box css properties

[Alex Harui]

IMO, if we are ok having files with the name 'flex' in it, why bother
duplicating the information in a 'royale' file?  VSCode and Moonshine are
under active development and could change (and maybe want to).

An alternative would be to have one or two scripts that transform a Royale
SDK to make it compatible with older Flex IDEs.  I think we're going to
need one anyway for Flash Builder.  Yes, those script names might have
'flex' in the name (ConvertToFlexSDK.xml) but it makes it appear more like
a backward compatibility thing than a "we currently use flex" thing.

My 2 cents,
-Alex 

On 10/16/17, 4:13 AM, "Piotr Zarzycki"  wrote:

>+1 for having both. The same could be with flex-config.xml - We could have
>both.
>
>Piotr
>
>On Mon, Oct 16, 2017, 12:23 Harbs  wrote:
>
>> The VS Code extension requires flex-sdk-description too.
>>
>> I think we should include both flex-sdk-description and
>> royale-sdk-description for now. We can deprecate flex-sdk-description at
>> some point in the future, but I think we should try and make the
>>migration
>> as painless as possible for now.
>>
>> Harbs
>>
>> > On Oct 16, 2017, at 1:29 AM, Alex Harui 
>> wrote:
>> >
>> > Pretty sure that Flash Builder will be looking for
>> > flex-sdk-description.xml.
>> >
>> > It might be that Flash Builder users will have to run an Ant script to
>> > fully set up their SDKs and we could use that to rename a
>> > royale-sdk-description file.
>> >
>> > Thoughts?
>> > -Alex
>> >
>> > On 10/14/17, 1:58 PM, "Harbs"  wrote:
>> >
>> >> There is a mismatch in this file:
>> >>
>> >> 
>> >> Apache Flex ${project.version} FP${flash.version}
>> >> AIR${air.version} en_US
>> >> 
>> >> 
>> >> 4.8.${project.version}
>> >> ${timestamp}
>> >> 
>> >>
>> >> I’m not sure which is a mistake, but eh opening tag of
>> >> flex-sdk-description does not match the closing tag of
>> >> royale-sdk-description
>> >>
>> >> I’m wondering whether Flash Builder will recognize
>> royale-sdk-description.
>> >>
>> >> Harbs
>> >>
>> >>> On Oct 7, 2017, at 12:21 AM, aha...@apache.org wrote:
>> >>>
>> >>> diff --git 
>>a/distribution/src/main/resources/flex-sdk-description.xml
>> >>> b/distribution/src/main/resources/flex-sdk-description.xml
>> >>> index a4bf265..099982c 100644
>> >>> --- a/distribution/src/main/resources/flex-sdk-description.xml
>> >>> +++ b/distribution/src/main/resources/flex-sdk-description.xml
>> >>> @@ -23,4 +23,4 @@
>> >>> 
>> >>> 4.8.${project.version}
>> >>> ${timestamp}
>> >>> -
>> >>> +
>> >>
>> >
>>
>>

Re: Flex2Royale

[Alex Harui]

IIRC, Om was working on this to some degree.  One plan was to convert FXG
to SVG.

AIUI, a SkinnableContainer wouldn't be that hard.  Container already has
an inner div to hold the children, so a different view could have the
outer div display SVG behind the children.  I think there were more
questions about SkinnableComponent because not every component is already
implemented to support a skin by default, and SVG as a backgroundImage for
some HTMLElements don't work well in all browsers.

Flex Skinning was pretty expensive because it added a UIComponent child to
every component.  Because we are PAYG, we don't want to force that on
everyone, and as the MDL work showed, CSS Themes may be just as good at
creating nice visual experiences and more standard/common.  But as Yishay
said, in theory, a new set of views could add that extra DIV behind each
component if that's what it takes to implement SVG "skins".  And we also
know from MDL and Flat that we can also just re-factor components into
enough pieces that they can have a different look.

Of course, I could be wrong...
-Alex

On 10/16/17, 6:50 AM, "Peter Ent"  wrote:

>We need to have a "skinning story" - something about alternate views, CSS,
>that sort of thing. Adding to my list.
>‹peter
>
>On 10/16/17, 2:29 AM, "yishayw"  wrote:
>
>>I like it.
>>
>>
>>> There is no direct equivalent of SkinnableContainer in Royale (at this
>>> time). A reasonable alternative is the Container.
>>
>>Maybe we could mention that Royale components typically have views which
>>can
>>be used to control appearance without changing behavior. To me, spark
>>skins
>>sort of played the same role.
>>
>>
>>
>>--
>>Sent from: 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-ro
>>y
>>ale-development.20373.n8.nabble.com%2F=02%7C01%7C%7C1f660ab8e3b74b1c
>>a
>>0b108d5145f4fd8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636437321952
>>4
>>70504=ueXDGjTEy4hq0kzF9w1P3utRy%2B805PEm54F7P9ZceZ8%3D=0
>

Re: Flex2Royale

[yishayw]

I like it.


> There is no direct equivalent of SkinnableContainer in Royale (at this
> time). A reasonable alternative is the Container.

Maybe we could mention that Royale components typically have views which can
be used to control appearance without changing behavior. To me, spark skins
sort of played the same role.



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/