Hi Alex, will be trying that approximation and see how far we reach
thanks 2017-11-06 8:20 GMT+01:00 Alex Harui <[email protected]>: > FWIW, Express is really just intended to be a pre-packaging of Basic > beads. If you use Basic you have to add beads to the strand. If you use > Express, the beads are already added to the strand. But the beads will > likely be from the Basic set. > > This Skinning/Theming effort, IMO is independent. It is just another PAYG > feature. Basic's goal in its HTMLElement topologies is to use the least > amount of HTMLElements and code. It will be how we show off how small our > HelloWorld can be. The goal of Skinning/Themeing is to come up with a set > of HTMLElements and code that allow us to alter every pixel in a useful > way. Once we figure out how to do that, we will find out what > pre-packaging of beads users want and figure out whether that is just > small tweaks to Express or something else, like SkinnableExpress. IMO, we > don't know now, and shouldn't spend any time thinking about it until after > we have proven what patterns are going to work. > > My 2 cents, > -Alex > > > On 11/5/17, 6:56 AM, "[email protected] on behalf of Carlos Rovira" > <[email protected] on behalf of [email protected]> wrote: > > >Hi Nicolas, > > > >2017-11-05 16:03 GMT+01:00 Idylog - Nicolas Granon <[email protected]>: > > > >> Hi, Carlos, > >> > >> No doubt theme support for Apache Royale components/containers/controls > >>(I > >> will use "components" from now on) would be very valuable. > >> > >> Obviously, themes could only be applied to components that conform to a > >> specific interface and who can be extensively CSS-styled. > >> I agree that it would not apply to MDL and other "external" (non-Royale) > >> components... > >> > > > >Right, I think that your idea of put in place an interface for stylable > >components are good, I expect Alex, Peter and others take on that specific > >part since is the technical arquitecture point that is needed. They always > >note that UX and design is not their strong point, but they can do the > >best > >implementing the wiring of the solution as soon as we have some pieces in > >place. > > > > > >> > >> Your suggestion of applying a theme at application level sounds logical. > >> > > > >That was the same Flex did, but again, I think is something that > >arquitecture guys should check and think if in the new framework has sense > >or not. > > > > > >> There is also a theme-related compiler argument where the theme file can > >> be a SWC or a CSS file (this implies that a theme could be one or the > >> other). > >> > > > >In flex we had some compiler arguments for compiling a theme swc, but > >maybe > >in royale we don't need that since we are only packing CSS and other > >resources. > >Maybe when we start doing this we could need that some code will be > >generated and that could be done with some compiler argument...don't know. > >We should try to keep things simple as we can > > > > > >> > >> As I said before, the number of "colors" should allow for clear > >> differentiation between disabled/enabled, selected/unselected, hovered > >> parts, dark text/light text. Window title/ window content. It seems to > >>me > >> that 2 or 3 colors are sufficient, but we probably need several shades > >>for > >> each. > >> > > > >Right, only specifiing 2-3 colors would be what we need, and the > >implementation will do the rest using alphas and other techniques to make > >colors more light or dark. > > > > > >> > >> As for which component set to use, and from various contributions on the > >> dev-list, Express appears as a serious candidate. > >> > > > >Right, but in other thread Harbs comments about to make a new one. I would > >want to hear from Peter Ent that was the main Express contributor about > >what he thinks. I think Express is still in development and we are still > >in > >time to change as we need. I don't like as you the idea of having lots of > >sets. For me having many sets is an invitation for people to not consider > >Apache Royale since they will find lots of options and they will want only > >one that work the best. So the question is, we should work over Express or > >do other. But taking the letter seems for me that the team will split and > >Peter will continue with Express, while me go to other set, and in the > >same > >way others would be obligated to choose....that's not seems good to me, > >and > >I think we don't get nothing positive. Why we want Express is is not > >stylizable? why we want other stylizable set if is not as good in > >functions > >as what Express already do? > > > > > >> > >> I do not like very much the idea of multiple component sets, each one > >>with > >> specific capabilities... > >> > >> If I understand correctly, we are not talking about "drawing" components > >> on a "canvas", right ? > >> For a button, it would be an assembly of "inline" block (a div or some > >> container element) with a css "radius" attribute etc. I am right ? > >> > > > >I think not in the first round, but maybe right as we learn more about > >what > >things we find in the road > >We'll starting with simple things, and will be experimenting on how to > >introduce SVG and other things that allow us to change visuals in a > >radical > >way but maybe in next stage of the effort > > > > > >> > >> But, in fact, it should be possible to use theming for any > >> Royale-developed component set ? It would be a matter of attaching a > >> "style-handling" bead ? It would be nice to know when a specific style > >>can > >> or cannot be applied to a component... Meaning all components should > >>expose > >> their own list of styleable properties... > >> > > > >I think that would not be possible unless arquitecture guys give us some > >solution. Maybe implementing interfaces in components will prepare it for > >visuals and so we could apply themes to all sets that implement that > >interfaces...but that seems as well an extra effort that maybe could not > >be > >of real use in the end...that's one of the things we must to discuss here. > > > > > >> > >> I do not really understand why we should choose some components among > >>the > >> components set ? > >> > >> > >I expect to have at least twenty components to prepare for customization > >and that's an huge effort. We can do just one official theme, but maybe > >we'll must to create a second project to test that we are making things in > >a good way since all is really configurable. If we don't have a consensus > >in what components will be stylizable we'll end with components with > >styles > >vs with components with raw visuals. That's not what we want. We want a > >consistent look for all the components. If we end we 2 three themes like > >Flex did, we'll need to customize all in the same way, and means replicate > >each component styling config per theme SWC project we want to support. > > > >In the other hand, making a list of components could be great for the rest > >of the team to know what concrete set of components we support. Users will > >want to have this to know in with set they can trust to make their > >developments. If we are not capable to offer a robust set and only lots of > >unfinished efforts, we'll never be a choice for them to use Royale. So > >this > >is not only for this effort, I think is something we need in the end to > >get > >a set of trusted pieces that will end making our foundation set of > >components like it happen in Flex with mx/halo and then with spark > > > > > > > >> Or maybe I still (!) do not have a very good understanding of how > >>styles, > >> themes and beads are related... > >> > > > >Thanks Nicolas! :) > > > > > > > >> > >> Nicolas Granon > >> > >> > >> > >> > >> > -----Message d'origine----- > >> > De : [email protected] [mailto:[email protected]] De la > >> > part de Carlos Rovira > >> > Envoyé : dimanche 5 novembre 2017 11:58 > >> > À : [email protected] > >> > Objet : [DISCUSS] Apache Royale Theme feature > >> > > >> > Hi all, > >> > > >> > in this thread I want to join a plan to work on a theme feature for > >> > Apache Royale. Hope you all could comment here if this starting point > >> > is in the good track or if you think we need things not expressed > >>here. > >> > > >> > 1.- Theme feature will be a pluggable set of styles (colors, drawings, > >> > images, animations,...) to customize the visuals of Apache Royale > >> > controls and components. > >> > > >> > 2.- The affected list of controls and components must to be defined in > >> > a vote thread. We'll be opening a vote thread to designate that > >> > concrete list based on concrete set of components. For example: > >>Express > >> > Set : Button, TextInput, CheckBox,.... and so on. > >> > While some of the components will be clearly included at first sight > >> > (Button, TextInput,...) sets in different frameworks are very > >>different > >> > and for this reason we must to concrete our own set or at least what > >>we > >> > start offering (although that will be evolving over time with more > >> > component > >> > inclusions) > >> > > >> > (in this point is important that if you could propose a concrete list > >> > of components, that would be of great help, of course that list must > >>be > >> > implemented in the set you think would have the theme feature. I > >>assume > >> > that will be Express. If not, should we create a new set?) > >> > > >> > 3.- MDL, CreateJS are sets that has it's own visuals, implementations > >> > and will be excluded of this plan. In fact, the problem with all that > >> > sets is that once the user start developing in one of them, they are > >> > tied the concrete implementation, set of controls, events, properties > >> > and change the final app visuals are impossible without rewriting the > >> > entire application. > >> > > >> > 4.- The themes will be a separate library project that will create a > >> > SWC > >> > > >> > 5.- SWC themes must be easily swappable. We must defined a way to swap > >> > themes. In Flex we add src theme and have a "theme" property. In > >>Royale > >> > it could be a Bead for the main application component. The best > >> > solution on this should be provided by people here more near to the > >> > apache royale arquitecture > >> > > >> > 3.- We'll be creating at least one theme that will be highly > >> > configurable > >> > > >> > 4.- We'll be using 2-3 color scheme (primary, secondary, contrast) for > >> > all components in a theme > >> > > >> > 5.- We'll use solid colors (we could try as well to integrate > >> > gradients, but this would depend on how visuals result looks) > >> > > >> > 6.- We'll try to include some more configuration per component. For > >> > example: round corners on buttons, boxed text inputs vs underlined > >> > ones... > >> > > >> > There's much more that can be done here, but I think we must reach a > >> > point and from there examine our experience and see where to gro from > >> > there. > >> > I'm sure will be learning a lot in the progress and right now we > >>don't > >> > know how to do more advanced things, or most things could take much > >> > more time if we try to do all at the same time. > >> > > >> > For example, some things that will be off in the first stage would be > >> > skins. > >> > > >> > Thanks > >> > > >> > > >> > -- > >> > Carlos Rovira > >> > > >>https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me% > >>2Fcarlosrovira&data=02%7C01%7C%7Cb38c9413dac342ba9af008d52465 > e6e7%7Cfa7b1 > >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636454942457488654& > sdata=BHDxMkyobL > >>92DJmApPXsrAHfeGA71vvPyOAGFkolEAQ%3D&reserved=0 > >> > >> > > > > > >-- > >Carlos Rovira > >https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2 > >Fcarlosrovira&data=02%7C01%7C%7Cb38c9413dac342ba9af008d52465 > e6e7%7Cfa7b1b5 > >a7b34438794aed2c178decee1%7C0%7C0%7C636454942457488654& > sdata=BHDxMkyobL92D > >JmApPXsrAHfeGA71vvPyOAGFkolEAQ%3D&reserved=0 > > -- Carlos Rovira http://about.me/carlosrovira
