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" <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> 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 <aha...@adobe.com.invalid>: > >> 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" <p...@adobe.com.INVALID> 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" <yishayj...@hotmail.com> 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&data=02%7C01%7C% >> 7C1f660ab8e3b74b1c >> >>a >> >>0b108d5145f4fd8%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636437321952 >> >>4 >> >>>>70504&sdata=ueXDGjTEy4hq0kzF9w1P3utRy%2B805PEm54F7P9ZceZ8%3D&reserved=0 >> > >> >> > > >-- > ><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeo >scopic.com&data=02%7C01%7C%7C6a1ec2e043e349c3bd3c08d514b7cd3f%7Cfa7b1b5a7b >34438794aed2c178decee1%7C0%7C0%7C636437702013883585&sdata=riiqXWeyfD%2FwR1 >uM2lMqH%2BAkvOMk%2B5%2B0nASrlRvNLN4%3D&reserved=0> > >Carlos Rovira > >Director General > >M: +34 607 22 60 05 > >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeos >copic.com&data=02%7C01%7C%7C6a1ec2e043e349c3bd3c08d514b7cd3f%7Cfa7b1b5a7b3 >4438794aed2c178decee1%7C0%7C0%7C636437702013883585&sdata=riiqXWeyfD%2FwR1u >M2lMqH%2BAkvOMk%2B5%2B0nASrlRvNLN4%3D&reserved=0 > > >Conocenos Avant2 en 1 minuto! ><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.e >s%2F%23video&data=02%7C01%7C%7C6a1ec2e043e349c3bd3c08d514b7cd3f%7Cfa7b1b5a >7b34438794aed2c178decee1%7C0%7C0%7C636437702013883585&sdata=fx0ooji2xZbinH >F%2FCdY85V1DTc9mApiNiRDVRCbWrrs%3D&reserved=0> > > >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.
