Great start! Some comments:
> But for Vivid, I'm still figuring if it should be > something "flat" and very simple, or go with something more elaborated > since the thing I did in the example with orange button. “Flat” is still “in”, but the trend has been moving a bit towards odd blocky relief. I think “vivid” should probably be more-or-less flat, but ideally it should have some subtle animations and there should be some way to support relief buttons. > * I like the look and feel of Google Material, how textfields looks and > behaves, the animations, and visual concepts. But the problem is that all > that visuals are clearly Google Material. Material Design is something you either like or hate. For general purpose, I think Bootstrap is probably more generally useful. https://bootswatch.com/ <https://bootswatch.com/> I do think it would be cool to have a Material Design theme and an iOS theme which could be dynamically swapped depending on the platform. > * In the other hand, someone would want to join me in this effort? I personally have a lot on my plate right now. I hope someone else does help you on this because I think it’s really important to have. What about Trevor and Angelo who started on some work a few months ago? > * About colors… I think that it should be easy for clients to define color sets (similar to how it’s done with MDL). There should be a way to use the compiler to have color variables or possibly a Theme class which globally changes colors at runtime (or compile time). Harbs > On Nov 3, 2017, at 2:15 AM, Carlos Rovira <carlosrov...@apache.org> wrote: > > Hi, > > I want to expose my initial work (very very initial) on two styles for > Royale > > > Wireframe: https://snag.gy/tDFxQT.jpg > > (Wireframe intention is for quick Royale App prototyping, people will use > this to start their applications, and then moving to it's own styling that > could be another royale theme provided by us, or something done by users. > > Vivid (to put some temporal name): https://snag.gy/qKShm0.jpg > > (*Please, Notice that only the first button has some styling here*) > (This theme could be the default theme for royale components like halo was > for mx and spark was for spark) > > I want to put in place all the main components, so I would need some > "component list" (Button, TextInput, CheckBox,...and what more?.), and > we'll be centering all the effort in only that list of components. > We need to "paint" all and the code all. > > The concept of theme involve a concrete set of components (and this bring > us again if we should do this to be pluggable for Basic, or go directly > with Express, I think even Basic should be able to use a theme maybe using > beads to be PAYG) > > So, before continue tomorrow, I want some feedback on this: > > * I think Wireframe is clearly something Black&White, maybe as I did, in > some grey scale colors. But for Vivid, I'm still figuring if it should be > something "flat" and very simple, or go with something more elaborated > since the thing I did in the example with orange button. > > * I like the look and feel of Google Material, how textfields looks and > behaves, the animations, and visual concepts. But the problem is that all > that visuals are clearly Google Material. Should we create something more > new? This has a problem that maybe we could reach something great....or > not, and is more work to iterate something until we reach a good point. > For example, the text input I created has the classic box look, for me > Material Design is better with only a bootom line, but the first is more > generalist, while the second is clearly google, android,... I could try to > think in something new a see what happens > > * In the other hand, someone would want to join me in this effort? If so I > could center in the design part, and other person could work with me on the > example project "RoyaleThemes". The example app is very important, since it > could have a playground for every component so we can tweak at runtime. we > could even generate the code to get that look...this could be like > FlexThemeManager App that we had in the Flex days. > > * About colors for the second again, don't have any preferences right now, > I put the same colors that use on the web in the first button, but as I > said before things (colors and forms) could change dramatically in the > second set. In the first one (Wireframe) I think it's ok to go the path > exposed in the image example. > > Thanks for your comments on this, we'll be defining what we want as we > comment here ok? > I'm done for today, > > > > > > > 2017-11-02 14:22 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>: > >> Thanks Harbs! >> >> very useful, I'll be keeping this info as I make some work >> >> Carlos >> >> 2017-11-02 12:13 GMT+01:00 Harbs <harbs.li...@gmail.com>: >> >>> BTW, the kind of thing we should be striving for in theme-able components >>> is something like this: >>> >>> https://vcalendar.netlify.com/ <https://vcalendar.netlify.com/> >>> >>>> On Nov 2, 2017, at 12:01 PM, Harbs <harbs.li...@gmail.com> wrote: >>>> >>>> FYI, I worked out a theming class for my (Royale) InDesign extensions >>> which allows for setting global CSS at runtime. The approach might be >>> useful in your theming effort: >>>> https://paste.apache.org/cOBC <https://paste.apache.org/cOBC> >>>> >>>> (Some of the code is specific to Adobe Extensions.) >>>> >>>> Some pointers: >>>> I used inject_html because I needed some overrides in a CSS file. I >>> might have been able to rework it so the CSS file was not needed. >>>> >>>> There is a function called createStyleSheet which is commented out. >>> That creates a stylesheet called “royale_theme_styles”. It’s the same as >>> including a blank css file with the same name, but it’s loaded dynamically >>> rather than requiring the file to be included. If that function is used >>> inject_html is not necessary. >>>> >>>> The order of dynamically loaded CSS has the same rules as CSS loaded >>> via declaring it in HTML and the later ones override the earlier ones. We >>> can probably take advantage of that for different levels of defaults. >>>> >>>> HTH, >>>> Harbs >>>> >>>>> On Nov 1, 2017, at 8:05 PM, Carlos Rovira <carlosrov...@apache.org >>> <mailto:carlosrov...@apache.org>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I think I could start to try what Harbs expose, although I think what I >>>>> will need in the end is to control some SVG parts with variables. Maybe >>>>> with the showed SVG/CSS relation could be sufficient. I'll be showing >>> how >>>>> limitations I find. As well as Alex said having inline SVG as HTML >>> would be >>>>> very useful. >>>>> >>>>> 2017-11-01 18:27 GMT+01:00 Harbs <harbs.li...@gmail.com <mailto: >>> harbs.li...@gmail.com>>: >>>>> >>>>>> I’m not sure. I haven’t seen problems. >>>>>> >>>>>> The only issues that come to mind are: >>>>>> 1. There’s no load events on SVG images on Microsoft browsers. >>>>>> 2. Chrome has issues with SVG, transforms and fractional pixels. >>>>>> 3. There’s some blending issues that different browsers handle >>> differently >>>>>> depending on isolation modes. >>>>>> >>>>>> There’s likely other issues, but these are ones that I’ve had to deal >>> with. >>>>>> >>>>>> The major gotcha in terms of mixing HTML and SVG is that HTML can not >>> be >>>>>> nested inside SVG without ForeignObject. ForeignObject does not have >>> full >>>>>> browser support. >>>>>> >>>>>>> On Nov 1, 2017, at 7:08 PM, Alex Harui <aha...@adobe.com.INVALID >>> <mailto:aha...@adobe.com.INVALID>> wrote: >>>>>>> >>>>>>> A couple of years ago, I thought I had learned that some browsers had >>>>>>> issues with SVG background-images. Maybe psuedo-states were >>> involved, >>>>>> but >>>>>>> a Button might "blink" as it changed states and loaded an SVG >>>>>>> background-image. Do we know if that was just a bug in some browser >>> or >>>>>> is >>>>>>> that still a concern? >>>>>>> >>>>>>> I think I would like to see a simple set of HTML/SVG/CSS/JS that >>> shows >>>>>> how >>>>>>> any declarative SVG and JS have to work together to handle resizable >>>>>>> skins/components. Then it might be more obvious what needs to >>> change in >>>>>>> the tooling. We allow inline HTML now in MXML. I think we >>> can/should >>>>>>> allow inline SVG, but for both inline HTML and SVG, id's in the >>> inline >>>>>>> content do not become id's to MXML and AS. >>>>>>> >>>>>>> HTH, >>>>>>> -Alex >>>>>>> >>>>>> >>>>>> >>>> >>> >>> >> >> >> -- >> Carlos Rovira >> http://about.me/carlosrovira >> >> > > > -- > Carlos Rovira > http://about.me/carlosrovira
