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 > > http://about.me/carlosrovira > > -- Carlos Rovira http://about.me/carlosrovira
