You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2017/10/31 18:12:49 UTC
Working on UI Controls styling
Hi,
I'm trying to find a valid workflow to start working in two initial faces
for Royale components.
I'm talking about to generate some kind of UI sheet with all controls and a
basic wireframe style and another one that would be what more people will
be using as default in Royale. From here, will be more easy to other guys
to change styles. We could event create a Royale Theme editor in a near
future.
So, to start working on this I need a design tool, and in this case, I
think that one is Sketch App.
So I can create a design in Sketch with all controls (Button, TextInput,
CheckBox, Panel,...)
From here, I can generate CSS and SVG code
For example the code of this simple button (https://snag.gy/Am2fRX.jpg) that
I did quickly is:
CSS
/* Background: */
background: #D8D8D8;
border: 1px solid #979797;
border-radius: 3px;
/* TextField: */
font-family: HelveticaNeue;
font-size: 12px;
color: #646D7A;
(CSS is almost all usable)
And SVG
<svg width="150px" height="40px" viewBox="0 0 150 40" version="1.1" xmlns="
http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<!-- Generator: Sketch 47.1 (45422) -
http://www.bohemiancoding.com/sketch -->
<desc>Created with Sketch.</desc>
<defs>
<rect id="path-1" x="0" y="0" width="150" height="40" rx="3"></rect>
</defs>
<g id="Page-1" stroke="none" stroke-width="1" fill="none"
fill-rule="evenodd">
<g id="Royale" transform="translate(-58.000000, -49.000000)">
<g id="Button" transform="translate(58.000000, 49.000000)">
<g id="Background">
<use fill="#D8D8D8" fill-rule="evenodd"
xlink:href="#path-1"></use>
<rect stroke="#979797" stroke-width="1" x="0.5" y="0.5"
width="149" height="39" rx="3"></rect>
</g>
<text id="TextField" font-family="HelveticaNeue, Helvetica
Neue" font-size="12" font-weight="normal" fill="#646D7A">
<tspan x="57" y="25">Button</tspan>
</text>
</g>
</g>
</g>
</svg>
(SVG could be a base, but it needs to be removed absolute values and even
some static parts to be usable)
I'd like to create a Button "playground" app with a button and some
controls that allow us to change how the button looks (colors, strokes,
round corners, font face, font weight,....)
In the end this would be the starting point of a playground app for all
Royale controls
Finaly this would be very useful if we can get the generated code for that
particular styles and we could apply easily to any app, so change a "theme"
will be quick and easy. Important: This will only work with our Royale
components (Express mainly, and maybe Basic?, but not MDL, CreateJS, or
others)
I'm as well interested in how we could integrate that "view" in some
component in order to easy replace visuals for a concrete component. For
example, in the button above will be
* we'll be making a skin part with SVG code, so we could pass values to the
skin (for example colors, text button, width,...)
* if not using skins, how can we pass data from the component to the svg
part? (for example colors, text button, width,...)
To progress with this effort, I think I could start doing only two
controls, and then as we have all considerations in place progress through
the rest.
Thoughts?
--
Carlos Rovira
http://about.me/carlosrovira
Re: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
You can also use a GraphicShape class and set the element to any random SVG. This would work as long as you don’t need access to the SVG structure using normal Royale methods.
Harbs
> On Nov 1, 2017, at 3:12 PM, Harbs <ha...@gmail.com> wrote:
>
> We also have an SVG package. Look in Basic org/apache/royale/svg.
>
> It might make sense to pull the SVG classes out into its own project.
>
> The current implementation of SVG wraps each element in a separate svh element, so you get lots of nested SVG elements. We considered adding raw non-wrapped SVG elements, but that has not happened yet.
>
> There are drawing commands similar to the Flash Graphics APIs. The drawing APIs work a bit different though. There is a PathBuilder class which abstracts a lot of things, but some classes have similar APIs like drawRect, drawRoundedRect, etc.
>
> Check out CompoundGraphic and PathBuilder. PathBuilder has APIs that mimic Flash Graphic very closely and can be used with SVG and theoretically Canvas.
>
> HTH,
> Harbs
>
>> On Nov 1, 2017, at 3:00 PM, Harbs <ha...@gmail.com> wrote:
>>
>> <js:ImageButton click="flipHorizontally()" src="assets/images/icons/0896-flip-horizontal2.svg"/>
>> <js:ImageButton click="flipVertically()" src="assets/images/icons/0897-flip-vertical2.svg"/>
>>
>>
>>> On Nov 1, 2017, at 2:45 PM, Carlos Rovira <ca...@codeoscopic.com> wrote:
>>>
>>> Hi Harbs,
>>>
>>> could you post some basic snippet for this to look at your approach?
>>>
>>> Thanks!
>>>
>>> 2017-11-01 13:42 GMT+01:00 Harbs <ha...@gmail.com>:
>>>
>>>> You can use SVG files instead of PNG files. I’m doing that extensively in
>>>> my app, but that will only work for components which have src or
>>>> background-image.
>>>>
>>>>> On Nov 1, 2017, at 2:14 PM, Carlos Rovira <ca...@apache.org>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I started a new project as Piotr suggested. After setup I only put one
>>>>> single button to start figuring how to do this.
>>>>>
>>>>> I'm starting for now with Basic, but as we discussed, don't know if this
>>>>> should go directly to express or not...it seems like something we could
>>>>> plug into Basic at any time as we can plug beads, and Express will come
>>>>> with some theme bundled. That seem the most natural for me right now
>>>>>
>>>>> Setting up a CSS-only theme seems pretty straight forward for me, and I
>>>>> could go with it for now.
>>>>>
>>>>> Regarding SVG, right now I don't see the way to add SVG in Royale. As
>>>> Alex
>>>>> suggested, I think we need to be able to add SVG in MXML.
>>>>> I was looking at this topic and seems very powerful since it can be
>>>>> integrated with CSS as well and in HTML
>>>>>
>>>>> For Example we have: https://css-tricks.com/using-svg/
>>>>>
>>>>> Maybe I could start with only CSS and see how far I can go, making
>>>>> wireframe and royale themes, as well trying with PNG images to
>>>> complement,
>>>>> but I suppose I'll get stuck soon, so maybe we should talk about SVG
>>>>> support as well and how hard it would be to make it happen in Royale. As
>>>>> well if you know other ways to integrate SVG right now please let me know
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2017-10-31 21:31 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
>>>>>
>>>>>> I can say at this point that I really like idea with swappable view. In
>>>>>> most cases view is an ActionScript class where we may have more
>>>> possibility
>>>>>> to do things. When I was looking last time into the checkbox it for sure
>>>>>> need to more love, some part of the logic should be moved to the View.
>>>>>>
>>>>>> Piotr
>>>>>>
>>>>>> 2017-10-31 20:50 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>>>
>>>>>>> Ugh, Something has gone bad in the Basic components. Things like
>>>>>>> CheckBox and RadioButton should be creating simple <input
>>>> type="check"/>
>>>>>>> and <input type='radio' /> elements.
>>>>>>>
>>>>>>> The ability to style everything belongs in a different set of
>>>> components.
>>>>>>> Basic is supposed to generate the simplest tree of HTMLElements even if
>>>>>>> they can't be fully styles. That's so someone can do the equivalent of
>>>>>>> just using bare bones <input> elements.
>>>>>>>
>>>>>>> What is currently in Basic CheckBox and RadioButton might be right for
>>>>>>> creating fully styleable components, or some other composition of
>>>>>>> HTMLElements might be better. Carlos, I think that's up to you to
>>>>>> decide.
>>>>>>>
>>>>>>> An alternative approach is to have the JS implementations of CheckBox
>>>> and
>>>>>>> RadioButton have views and the views could create the HTMLElements.
>>>> That
>>>>>>> seems a bit heavy for the simple case of someone who just wants to use
>>>>>>> <input type="check" in an app, but that is a possibility.
>>>>>>>
>>>>>>> It sounds like you are looking for a way to manipulate SVG at runtime.
>>>>>> It
>>>>>>> is fine to have "static SVG" which is a block of SVG with that cannot
>>>> be
>>>>>>> modified and thus uses percentages and absolute values as best it can.
>>>>>>> Then we probably want to have a way to create "dynamic" skins with run
>>>>>>> code to generate or manipulate SVG. Those will be heavier, but that's
>>>>>>> PAYG. Should we try to allow SVG tags in MXML files? Then you could
>>>>>>> write code in an fx:Script block around your SVG tags and manipulate
>>>> the
>>>>>>> SVG?
>>>>>>>
>>>>>>> So IMO first, we should look into reverting Basic back to single simple
>>>>>>> HTMLElements where possible, then decide whether we want to have
>>>>>> swappable
>>>>>>> views or a new skinnable component set, then build out that component
>>>> set
>>>>>>> and see what code it takes to get it to look the way we want it. And
>>>>>> then
>>>>>>> we'll know what code is needed and can plan out how to encapsulate and
>>>>>>> re-use that code.
>>>>>>>
>>>>>>> My 2 cents,
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 10/31/17, 11:23 AM, "Piotr Zarzycki" <pi...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Carlos,
>>>>>>>>
>>>>>>>> I think you should start looking into the Basic module and later make
>>>> an
>>>>>>>> upgrades to Express once you have all components visually created. I
>>>>>> would
>>>>>>>> not think on that stage about how we implement them rather look how
>>>> they
>>>>>>>> look like currently.
>>>>>>>>
>>>>>>>> 1) Create small app or run example with that component from our
>>>>>>>> repository.
>>>>>>>> 2) Make it visually with theme
>>>>>>>> 3) Show on the dev list - once we agree on all of them we can decide
>>>> how
>>>>>>>> to
>>>>>>>> apply those styles.
>>>>>>>>
>>>>>>>> My 2 cents. :) Piotr
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017-10-31 19:12 GMT+01:00 Carlos Rovira <ca...@apache.org>:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm trying to find a valid workflow to start working in two initial
>>>>>>>>> faces
>>>>>>>>> for Royale components.
>>>>>>>>>
>>>>>>>>> I'm talking about to generate some kind of UI sheet with all controls
>>>>>>>>> and a
>>>>>>>>> basic wireframe style and another one that would be what more people
>>>>>>>>> will
>>>>>>>>> be using as default in Royale. From here, will be more easy to other
>>>>>>>>> guys
>>>>>>>>> to change styles. We could event create a Royale Theme editor in a
>>>>>> near
>>>>>>>>> future.
>>>>>>>>>
>>>>>>>>> So, to start working on this I need a design tool, and in this case,
>>>> I
>>>>>>>>> think that one is Sketch App.
>>>>>>>>>
>>>>>>>>> So I can create a design in Sketch with all controls (Button,
>>>>>> TextInput,
>>>>>>>>> CheckBox, Panel,...)
>>>>>>>>>
>>>>>>>>> From here, I can generate CSS and SVG code
>>>>>>>>>
>>>>>>>>> For example the code of this simple button
>>>>>>>>> (https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> https%3A%2F%2Fsnag.gy
>>>>>>>>> %2FAm2fRX.jpg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>> 8494%7Cfa7b1b
>>>>>>>>> 5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>>> sdata=Z4b6dMq%2Br
>>>>>>>>> UmSSxpGYNjgKl0nkRkIlV%2FbQIDLVUIvo6E%3D&reserved=0)
>>>>>>>>> that
>>>>>>>>> I did quickly is:
>>>>>>>>>
>>>>>>>>> CSS
>>>>>>>>>
>>>>>>>>> /* Background: */
>>>>>>>>> background: #D8D8D8;
>>>>>>>>> border: 1px solid #979797;
>>>>>>>>> border-radius: 3px;
>>>>>>>>>
>>>>>>>>> /* TextField: */
>>>>>>>>> font-family: HelveticaNeue;
>>>>>>>>> font-size: 12px;
>>>>>>>>> color: #646D7A;
>>>>>>>>>
>>>>>>>>> (CSS is almost all usable)
>>>>>>>>>
>>>>>>>>> And SVG
>>>>>>>>>
>>>>>>>>> <svg width="150px" height="40px" viewBox="0 0 150 40" version="1.1"
>>>>>>>>> xmlns="
>>>>>>>>>
>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> http%3A%2F%2Fwww.w3.or
>>>>>>>>> g%2F2000%2Fsvg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>> 8494%7Cfa7b1
>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>>> sdata=cWLJ2jj9Ih
>>>>>>>>> cGnjAB8GEtEIdc3ZZO2OSAsgzPNEVrUzE%3D&reserved=0"
>>>>>>>>> xmlns:xlink="https://na01.safelinks.protection.outlook.
>>>>>>> com/?url=http%3A%2
>>>>>>>>> F%2Fwww.w3.org%2F1999%2Fxlink&data=02%7C01%7C%
>>>>>>> 7Cc23665e118fc4a7fed4c08d52
>>>>>>>>> 08c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>>> 7C636450710247213906&s
>>>>>>>>> data=sgNtytSumzad%2BraDA6NoITbm6XqJJx6yHQudjzhpm6Y%3D&reserved=0">
>>>>>>>>> <!-- Generator: Sketch 47.1 (45422) -
>>>>>>>>>
>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> http%3A%2F%2Fwww.bohem
>>>>>>>>> iancoding.com%2Fsketch&data=02%7C01%7C%
>>>> 7Cc23665e118fc4a7fed4c08d5208c
>>>>>>> 8494
>>>>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>>> 7C636450710247213906&sdata=dE
>>>>>>>>> oGVBONBD6Z1XMTjYcpEc7gq5UqtS8BziB0I3f9qSs%3D&reserved=0 -->
>>>>>>>>> <desc>Created with Sketch.</desc>
>>>>>>>>> <defs>
>>>>>>>>> <rect id="path-1" x="0" y="0" width="150" height="40"
>>>>>>>>> rx="3"></rect>
>>>>>>>>> </defs>
>>>>>>>>> <g id="Page-1" stroke="none" stroke-width="1" fill="none"
>>>>>>>>> fill-rule="evenodd">
>>>>>>>>> <g id="Royale" transform="translate(-58.000000, -49.000000)">
>>>>>>>>> <g id="Button" transform="translate(58.000000,
>>>>>> 49.000000)">
>>>>>>>>> <g id="Background">
>>>>>>>>> <use fill="#D8D8D8" fill-rule="evenodd"
>>>>>>>>> xlink:href="#path-1"></use>
>>>>>>>>> <rect stroke="#979797" stroke-width="1" x="0.5"
>>>>>>>>> y="0.5"
>>>>>>>>> width="149" height="39" rx="3"></rect>
>>>>>>>>> </g>
>>>>>>>>> <text id="TextField" font-family="HelveticaNeue,
>>>>>>>>> Helvetica
>>>>>>>>> Neue" font-size="12" font-weight="normal" fill="#646D7A">
>>>>>>>>> <tspan x="57" y="25">Button</tspan>
>>>>>>>>> </text>
>>>>>>>>> </g>
>>>>>>>>> </g>
>>>>>>>>> </g>
>>>>>>>>> </svg>
>>>>>>>>>
>>>>>>>>> (SVG could be a base, but it needs to be removed absolute values and
>>>>>>>>> even
>>>>>>>>> some static parts to be usable)
>>>>>>>>>
>>>>>>>>> I'd like to create a Button "playground" app with a button and some
>>>>>>>>> controls that allow us to change how the button looks (colors,
>>>>>> strokes,
>>>>>>>>> round corners, font face, font weight,....)
>>>>>>>>>
>>>>>>>>> In the end this would be the starting point of a playground app for
>>>>>> all
>>>>>>>>> Royale controls
>>>>>>>>>
>>>>>>>>> Finaly this would be very useful if we can get the generated code for
>>>>>>>>> that
>>>>>>>>> particular styles and we could apply easily to any app, so change a
>>>>>>>>> "theme"
>>>>>>>>> will be quick and easy. Important: This will only work with our
>>>> Royale
>>>>>>>>> components (Express mainly, and maybe Basic?, but not MDL, CreateJS,
>>>>>> or
>>>>>>>>> others)
>>>>>>>>>
>>>>>>>>> I'm as well interested in how we could integrate that "view" in some
>>>>>>>>> component in order to easy replace visuals for a concrete component.
>>>>>> For
>>>>>>>>> example, in the button above will be
>>>>>>>>>
>>>>>>>>> * we'll be making a skin part with SVG code, so we could pass values
>>>>>> to
>>>>>>>>> the
>>>>>>>>> skin (for example colors, text button, width,...)
>>>>>>>>> * if not using skins, how can we pass data from the component to the
>>>>>> svg
>>>>>>>>> part? (for example colors, text button, width,...)
>>>>>>>>>
>>>>>>>>> To progress with this effort, I think I could start doing only two
>>>>>>>>> controls, and then as we have all considerations in place progress
>>>>>>>>> through
>>>>>>>>> the rest.
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Carlos Rovira
>>>>>>>>>
>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> http%3A%2F%2Fabout.me%
>>>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>> 8494%7Cfa7b1
>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>>> sdata=auPeQ0ub4B
>>>>>>>>> Iq%2FTscLQWJ0Xxb9XdM2eegav2v1LXcuYY%3D&reserved=0
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Piotr Zarzycki
>>>>>>>>
>>>>>>>> mobile: +48 880 859 557
>>>>>>>> skype: zarzycki10
>>>>>>>>
>>>>>>>> LinkedIn:
>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> http%3A%2F%2Fwww.linked
>>>>>>>> in.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>> 8494%
>>>>>>>> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>> 7C636450710247213906&sdata=
>>>>>>> xZ56
>>>>>>>> se7Z6gcWKcC7PuWDPW0E6F9wQjEZkuYZO4zvwnY%3D&reserved=0
>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> https%3A%2F%2Fpl.linke
>>>>>>>> din.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%
>>>>>>> 7C01%7C%7Cc23665e118fc4a7fe
>>>>>>>> d4c08d5208c8494%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>> cee1%7C0%7C0%7C6364507102472
>>>>>>>> 13906&sdata=1pwc5Fz1vKM2YCp6yUSe6x1Zdh9Au2
>>>> xqb28Duy2Tqac%3D&reserved=0>
>>>>>>>>
>>>>>>>> GitHub:
>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> https%3A%2F%2Fgithub.co
>>>>>>>> m%2Fpiotrzarzycki21&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>> 8494%7Cf
>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=
>>>>>>> Lr7JdnU
>>>>>>>> fF%2F4xHJbXVZlZN%2Fw7t4Tz5R5KbZFwdVnZFww%3D&reserved=0
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Piotr Zarzycki
>>>>>>
>>>>>> mobile: +48 880 859 557
>>>>>> skype: zarzycki10
>>>>>>
>>>>>> LinkedIn: http://www.linkedin.com/piotrzarzycki
>>>>>> <https://pl.linkedin.com/in/piotr-zarzycki-92a53552>
>>>>>>
>>>>>> GitHub: https://github.com/piotrzarzycki21
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>> http://about.me/carlosrovira
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> <http://www.codeoscopic.com>
>>>
>>> Carlos Rovira
>>>
>>> Director General
>>>
>>> M: +34 607 22 60 05
>>>
>>> http://www.codeoscopic.com
>>>
>>>
>>> Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
>>>
>>>
>>> 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: Working on UI Controls styling
Posted by Idylog - Nicolas Granon <ng...@idylog.com>.
Seems like we are in the same kind of business !
Like you say, a "corporate theme" fits our needs.
I understand that this is not very appealing for "branded" web interfaces, but from a practical point of view, it is what is needed when data is more important than the container !
Remember that our users do not use our apps because they are "attracted" but mainly because they are "interested" !!! (design is less important than functionalities)
Nicolas Granon
> -----Message d'origine-----
> De : gkk gb [mailto:modjklist@comcast.net]
> Envoyé : vendredi 3 novembre 2017 20:58
> À : ngranon@idylog.com; dev@royale.apache.org
> Objet : RE: Working on UI Controls styling
>
> I largely agree with your comments here.
>
>
> My enterprise/corporate web app actually used the default styling --
> neutral (gray) buttons/etc. with corporate blue highlights for
> selection etc. found in default Spark. I didn't want the components to
> stand out and be distracting. They're necessary, and should look nice,
> but should not grab attention and be distracting. So font choice is
> critical for readability (I use Roboto google font) and appearance
> should be stylish, but otherwise should remain in the background. The
> star of the show are the charts, text, data associated with the app. My
> interest wouldn't be fancy themes; I'd rather see a full component set.
>
>
> Just my 2 cents...
>
> > On November 3, 2017 at 10:29 AM Idylog - Nicolas Granon wrote:
> >
> >
> > Quote :
> > " Maybe a good question for our users is: How many of you used
> the default Flex skins vs a whole new set of skins? If most folks
> completely re-skinned to match their corporate branding, it matters
> less what our default is, and more that we can allow folks to customize
> every pixel."
> >
> > For enterprise (business) RIAs, we have *always* sticked to the
> "standard" theme (Halo, then Spark).
> > It was very neutral, which is good for enterprise apps.
> > Yet a bit more elaborate than usual (local installed) business
> apps...(rounded corners, gradients).
> > The default font was excellent.
> > For business apps, a fancy theme (skins) is not very desirable...
> > One key point is excellent readability, and excellent
> differentiation between unselected, hovered and selected items (in a
> list, in a form...).
> > All in all, something close to default adobe themes fits us
> perfectly !
> >
> > OF course, our usage might not be typical...
> >
> > Nicolas Granon
> >
> >
> >
> > ---Message d'origine-----
> De : Alex Harui [mailto:aharui@adobe.com mailto:aharui@adobe.com
> .INVALID] Envoyé : vendredi 3 novembre 2017 17:53 À : dev@royale.apache
> mailto:dev@royale.apache .org Objet : Re: Working on UI Controls
> styling
>
> Hi Carlos,
>
> I skimmed through https://material.io/guidelines/# last night.
>
> My impression is that there were two parts to it. First was the
> environment/principles section which talked about physical objects and
> light (and motion), and then there were choices of widgets. For
> example, I didn't see anything in the first part that said that a text
> input had to be a single line and couldn't be a box.
>
> That made me think that we could use our widget set and apply Material
> environment and principles to it. If we decide not to, I would think
> you would want to have some sort of similar environment/principles
> document which seems like a fair amount of work. I think we'd end up
> looking different because we have different widgets and maybe some
> different colors. I'm pretty sure that we don't want to be different so
> much that we don't create things that folks want to use. The priority
> to me is just to prove that you can alter every pixel in every widget
> we have so that others can provide custom skins as well. So starting
> with Material principles seems like it would save us time, we can get
> something released, and can innovate more later.
>
> Maybe a good question for our users is: How many of you used the
> default Flex skins vs a whole new set of skins? If most folks
> completely re-skinned to match their corporate branding, it matters
> less what our default is, and more that we can allow folks to customize
> every pixel.
>
> The wireframe can be black and white, IMO. I was thinking that "vivid"
> would have parameterized colors.
>
> Since Bootstrap was mentioned, I want to point out that the Flat.swc is
> a rough approximation of the Flat theme which is a Bootstrap theme. It
> is a rough approximation because I could not use the Flat CSS file
> directly since it contains much more advanced CSS than we currently
> support on the SWF side. But it presumed that the Checkbox was a Label
> with a Span that hides in front of or behind the in order to allow
> customizing every pixel. Looks like MDL uses the same Span trick but
> maybe without a symbol font.
>
> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
> should not have that extra Span. But it looks to me that a
> SkinnableCheckbox can add that extra Span and you either give it the
> same class name that BootStrap or MDL uses or create our own set of
> classnames and the CSS that goes with it.
>
> Of course, I could be wrong. This is not my area of expertise at all.
> -Alex
>
>
> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com
> mailto:carlos.rovira@gmail.com on behalf of Carlos Rovira"
>
> wrote:
>
> >Hi Alex,
> >
> >2017-11-03 7:39 GMT+01:00 Alex Harui :
> >
> >> Hi Carlos,
> >>
> >> Looks good to me. Thanks for doing this.
> >>
> >
> >Thanks :)
> >
> >>
> >> I'm not sure I understand all of the aspects of this effort. My
> >>current understanding is that Google Material is under the Apache
> >>License and thus we can use it if we want to. Am I correct that
> >>MaterialDesignLite is one implementation of Google Material and we
> >>could create our own implementation and it could be visually
> >>different?
> >>
> >
> >We can implement our own material in Royale, but I'm afraid that doing
> >that will not make us highlight our solution against the rest of
> >competitors. Another point is something I said various times:
> >When I did MDL, I notice a huge problem: MDL has its own set of
> >components, some are in all sets (Button) but others not (Card), and
> >they has it's own implementation, what make it almost impossible
> >generalize a theme. For this reason I always point that we need our
> own
> >set and there we can implement themes. But other
> >*externa* sets will never get this since they have its own
> >implementation and most important once you start to develop with MDL
> >you can't go back and change for other. So MDL is for me something we
> >have until our own set are robust and highly configurable in both the
> >things we can do and how can it could be represented, and switch
> >between style should be really easy to change the global look of an
> App
> >without much hassle.
> >
> >
> >>
> >> Also, IIRC, Material has different components than Flex did so we'd
> >> have to invent some new looks anyway. So having a TextInput with
> >> borders all around would just be our flavor of Material.
> >>
> >
> >That's what I point above. We must to *freeze* the list of components
> >at some time work over a concrete set We can then plan in the future
> >include a new component in the official set, and that will need to
> work
> >on the themes we already have to include the new one.
> >
> >
> >>
> >> Regarding colors, it looks like Material is parameterized around a
> >>couple of colors. So if we did our skins to work against
> parameterized
> >>colors then would it really matter what color we choose?
> >>
> >
> >That's completly right. I could make wireframe based on two or three
> >colors and as you change it in CSS all controls should tint
> >consistently.
> >
> >
> >>
> >> Regarding Basic components, right now Checkbox is a <input
> >>type="check"/>caption. AIUI, you cannot style the on many browsers,
> so
> >>I think we have to have a different set of
> elements
> >>in a checkbox. It looks like Bootstrap uses:
> >>
> >> Caption
> >>
> >> Where the span uses a special symbol font with checked and unchecked
> >>boxes.
> >>
> >
> >That's what we need to figure. Should we make themes available in
> Basic?
> >if
> >so, has basic the right implementation?
> >If not, and if we don't want to change the actual very basic
> >implementation, we need to put some "skin" implementation that at
> least
> >in JS implementation I figure that will change one face (the actual
> >basic) with the theme face.
> >
> >I'm thinking loud, since this is something we should explorer all
> >together mixing the best ideas of people involved
> >
> >Thanks
> >
> >
> >
> >>
> >> Thanks,
> >> Alex
> >>
> >> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com
> >>mailto:carlos.rovira@gmail.com on behalf of Carlos Rovira"
> >>
> wrote:
> >>
> >> >Hi,
> >> >
> >> >I want to expose my initial work (very very initial) on two styles
> >> >for Royale
> >> >
> >> >
> >> >Wireframe:
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fsnag.gy%2
> >> >FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa7b1b5a7
> >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=%2Fk8YQxC5bDOaC
> >> >D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
> >> >
> >> >(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://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fsnag.gy%2
> >> >FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa7b1b5a7
> >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=kxYE7ylOsXPUEeE
> >> >r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
> >> >
> >> >(*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 :
> >> >
> >> >> 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 :
> >> >>
> >> >>> BTW, the kind of thing we should be striving for in theme-able
> >> >>>components is something like this:
> >> >>>
> >> >>>
> >> >>>https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fvcalend
> >> >>>ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cf
> >>
> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata
> >> >>>=
> >> b3VtV
> >> >>>VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
> >> >>><https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fvcalen
> >> >>>dar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7C
> >>
> >>>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdat
> >> >>>a=
> >> b3Vt
> >> >>>VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
> >> >>>
> >> >>> > On Nov 2, 2017, at 12:01 PM, Harbs
> 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://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fpaste.a
> >> >>>pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa
> >> >>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=bRWKxm
> >> >>>LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
> >>
> >>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> p
> >>>>>ast
> >>>>>e
> >> .
> >> >>>apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cf
> >>
> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata
> >> >>>=
> >> bRWKx
> >> >>>mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
> >> >>> >
> >> >>> > (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
> >><carlosrovira@apache.org mailto:carlosrovira@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.lists@gmail.com
> >> >>> >> mailto:harbs.lists@gmail.com
> <mailto:
> >> >>> harbs.lists@gmail.com mailto:harbs.lists@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
> >><aharui@adobe.com mailto:aharui@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
> >> >>
> >> >>https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%
> >> >>2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa7b1
> >> >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=C7a72gwfH2
> >> >>64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >Carlos Rovira
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%2
> >> >Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa7b1b5
> >> >a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=C7a72gwfH264w
> >> >Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >>
> >>
> >
> >
> >--
> >
> ><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.c
> o
> >deo
> >scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b1b
> 5
> >a7b
> >34438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=Hm%2B6WIcqQT
> O
> >Hs0 UppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0>
> >
> >Carlos Rovira
> >
> >Director General
> >
> >M: +34 607 22 60 05
> >
> >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.co
> d
> >eos
> >copic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b1b5
> a
> >7b3
> >4438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=Hm%2B6WIcqQTO
> H
> >s0U
> >ppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0
> >
> >
> >Conocenos Avant2 en 1 minuto!
> ><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favan
> t
> >2.e
> >s%2F%23video&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b
> 1
> >b5a
> >7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=b%2FFMr1Aj
> i
> >t94 TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
>
RE: Working on UI Controls styling
Posted by gkk gb <mo...@comcast.net>.
I largely agree with your comments here.
My enterprise/corporate web app actually used the default styling -- neutral (gray) buttons/etc. with corporate blue highlights for selection etc. found in default Spark. I didn't want the components to stand out and be distracting. They're necessary, and should look nice, but should not grab attention and be distracting. So font choice is critical for readability (I use Roboto google font) and appearance should be stylish, but otherwise should remain in the background. The star of the show are the charts, text, data associated with the app. My interest wouldn't be fancy themes; I'd rather see a full component set.
Just my 2 cents...
> On November 3, 2017 at 10:29 AM Idylog - Nicolas Granon wrote:
>
>
> Quote :
> " Maybe a good question for our users is: How many of you used the default Flex skins vs a whole new set of skins? If most folks completely re-skinned to match their corporate branding, it matters less what our default is, and more that we can allow folks to customize every pixel."
>
> For enterprise (business) RIAs, we have *always* sticked to the "standard" theme (Halo, then Spark).
> It was very neutral, which is good for enterprise apps.
> Yet a bit more elaborate than usual (local installed) business apps...(rounded corners, gradients).
> The default font was excellent.
> For business apps, a fancy theme (skins) is not very desirable...
> One key point is excellent readability, and excellent differentiation between unselected, hovered and selected items (in a list, in a form...).
> All in all, something close to default adobe themes fits us perfectly !
>
> OF course, our usage might not be typical...
>
> Nicolas Granon
>
>
>
> ---Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com mailto:aharui@adobe.com .INVALID]
Envoyé : vendredi 3 novembre 2017 17:53
À : dev@royale.apache mailto:dev@royale.apache .org
Objet : Re: Working on UI Controls styling
Hi Carlos,
I skimmed through https://material.io/guidelines/# last night.
My impression is that there were two parts to it. First was the
environment/principles section which talked about physical objects and
light (and motion), and then there were choices of widgets. For
example, I didn't see anything in the first part that said that a text
input had to be a single line and couldn't be a box.
That made me think that we could use our widget set and apply Material
environment and principles to it. If we decide not to, I would think
you would want to have some sort of similar environment/principles
document which seems like a fair amount of work. I think we'd end up
looking different because we have different widgets and maybe some
different colors. I'm pretty sure that we don't want to be different
so much that we don't create things that folks want to use. The
priority to me is just to prove that you can alter every pixel in every
widget we have so that others can provide custom skins as well. So
starting with Material principles seems like it would save us time, we
can get something released, and can innovate more later.
Maybe a good question for our users is: How many of you used the
default Flex skins vs a whole new set of skins? If most folks
completely re-skinned to match their corporate branding, it matters
less what our default is, and more that we can allow folks to customize
every pixel.
The wireframe can be black and white, IMO. I was thinking that "vivid"
would have parameterized colors.
Since Bootstrap was mentioned, I want to point out that the Flat.swc is
a rough approximation of the Flat theme which is a Bootstrap theme. It
is a rough approximation because I could not use the Flat CSS file
directly since it contains much more advanced CSS than we currently
support on the SWF side. But it presumed that the Checkbox was a Label
with a Span that hides in front of or behind the
in order to allow customizing every pixel. Looks like MDL uses the
same Span trick but maybe without a symbol font.
Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
should not have that extra Span. But it looks to me that a
SkinnableCheckbox can add that extra Span and you either give it the
same class name that BootStrap or MDL uses or create our own set of
classnames and the CSS that goes with it.
Of course, I could be wrong. This is not my area of expertise at all.
-Alex
On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com mailto:carlos.rovira@gmail.com on behalf of Carlos
Rovira"
wrote:
>Hi Alex,
>
>2017-11-03 7:39 GMT+01:00 Alex Harui :
>
>> Hi Carlos,
>>
>> Looks good to me. Thanks for doing this.
>>
>
>Thanks :)
>
>>
>> I'm not sure I understand all of the aspects of this effort. My
>>current understanding is that Google Material is under the Apache
>>License and thus we can use it if we want to. Am I correct that
>>MaterialDesignLite is one implementation of Google Material and we
>>could create our own implementation and it could be visually
>>different?
>>
>
>We can implement our own material in Royale, but I'm afraid that doing
>that will not make us highlight our solution against the rest of
>competitors. Another point is something I said various times:
>When I did MDL, I notice a huge problem: MDL has its own set of
>components, some are in all sets (Button) but others not (Card), and
>they has it's own implementation, what make it almost impossible
>generalize a theme. For this reason I always point that we need our
own
>set and there we can implement themes. But other
>*externa* sets will never get this since they have its own
>implementation and most important once you start to develop with MDL
>you can't go back and change for other. So MDL is for me something we
>have until our own set are robust and highly configurable in both the
>things we can do and how can it could be represented, and switch
>between style should be really easy to change the global look of an
App
>without much hassle.
>
>
>>
>> Also, IIRC, Material has different components than Flex did so we'd
>> have to invent some new looks anyway. So having a TextInput with
>> borders all around would just be our flavor of Material.
>>
>
>That's what I point above. We must to *freeze* the list of components
>at some time work over a concrete set We can then plan in the future
>include a new component in the official set, and that will need to
work
>on the themes we already have to include the new one.
>
>
>>
>> Regarding colors, it looks like Material is parameterized around a
>>couple of colors. So if we did our skins to work against
>>parameterized colors then would it really matter what color we
>>choose?
>>
>
>That's completly right. I could make wireframe based on two or three
>colors and as you change it in CSS all controls should tint
>consistently.
>
>
>>
>> Regarding Basic components, right now Checkbox is a <input
>>type="check"/>caption. AIUI, you cannot style the on
>>many browsers, so I think we have to have a different set of
elements
>>in a checkbox. It looks like Bootstrap uses:
>>
>> Caption
>>
>> Where the span uses a special symbol font with checked and unchecked
>>boxes.
>>
>
>That's what we need to figure. Should we make themes available in
Basic?
>if
>so, has basic the right implementation?
>If not, and if we don't want to change the actual very basic
>implementation, we need to put some "skin" implementation that at
least
>in JS implementation I figure that will change one face (the actual
>basic) with the theme face.
>
>I'm thinking loud, since this is something we should explorer all
>together mixing the best ideas of people involved
>
>Thanks
>
>
>
>>
>> Thanks,
>> Alex
>>
>> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com mailto:carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>>
wrote:
>>
>> >Hi,
>> >
>> >I want to expose my initial work (very very initial) on two styles
>> >for Royale
>> >
>> >
>> >Wireframe:
>> >https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fsnag.gy%2
>> >FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cfa7b1b5a7
>> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> sdata=%2Fk8YQxC5bDOaC
>> >D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
>> >
>> >(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://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fsnag.gy%2
>> >FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cfa7b1b5a7
>> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> sdata=kxYE7ylOsXPUEeE
>> >r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
>> >
>> >(*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 :
>> >
>> >> 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 :
>> >>
>> >>> BTW, the kind of thing we should be striving for in theme-able
>> >>>components is something like this:
>> >>>
>> >>>
>> >>>https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fvcalend
>> >>>ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cf
>>
>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata
>> >>>=
>> b3VtV
>> >>>VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
>> >>><https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fvcalen
>> >>>dar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7C
>>
>>>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdat
>> >>>a=
>> b3Vt
>> >>>VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
>> >>>
>> >>> > On Nov 2, 2017, at 12:01 PM, Harbs
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://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fpaste.a
>> >>>pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cfa
>> >>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> sdata=bRWKxm
>> >>>LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
>>
>>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
p
>>>>>ast
>>>>>e
>> .
>> >>>apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cf
>>
>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata
>> >>>=
>> bRWKx
>> >>>mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
>> >>> >
>> >>> > (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
>><carlosrovira@apache.org mailto:carlosrovira@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.lists@gmail.com mailto:harbs.lists@gmail.com
<mailto:
>> >>> harbs.lists@gmail.com mailto:harbs.lists@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
>><aharui@adobe.com mailto:aharui@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
>> >>
>> >>https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%
>> >>2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cfa7b1
>> >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> sdata=C7a72gwfH2
>> >>64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>> >>
>> >>
>> >
>> >
>> >--
>> >Carlos Rovira
>> >https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>> >Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cfa7b1b5
>> >a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> sdata=C7a72gwfH264w
>> >Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>>
>>
>
>
>--
>
><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.c
o
>deo
>scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b1b
5
>a7b
>34438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=Hm%2B6WIcqQT
O
>Hs0 UppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0>
>
>Carlos Rovira
>
>Director General
>
>M: +34 607 22 60 05
>
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.co
d
>eos
>copic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b1b5
a
>7b3
>4438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=Hm%2B6WIcqQTO
H
>s0U
>ppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0
>
>
>Conocenos Avant2 en 1 minuto!
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favan
t
>2.e
>s%2F%23video&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b
1
>b5a
>7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=b%2FFMr1Aj
i
>t94 TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
RE: Working on UI Controls styling
Posted by Idylog - Nicolas Granon <ng...@idylog.com>.
Quote :
" Maybe a good question for our users is: How many of you used the default Flex skins vs a whole new set of skins? If most folks completely re-skinned to match their corporate branding, it matters less what our default is, and more that we can allow folks to customize every pixel."
For enterprise (business) RIAs, we have *always* sticked to the "standard" theme (Halo, then Spark).
It was very neutral, which is good for enterprise apps.
Yet a bit more elaborate than usual (local installed) business apps...(rounded corners, gradients).
The default font was excellent.
For business apps, a fancy theme (skins) is not very desirable...
One key point is excellent readability, and excellent differentiation between unselected, hovered and selected items (in a list, in a form...).
All in all, something close to default adobe themes fits us perfectly !
OF course, our usage might not be typical...
Nicolas Granon
> -----Message d'origine-----
> De : Alex Harui [mailto:aharui@adobe.com.INVALID]
> Envoyé : vendredi 3 novembre 2017 17:53
> À : dev@royale.apache.org
> Objet : Re: Working on UI Controls styling
>
> Hi Carlos,
>
> I skimmed through https://material.io/guidelines/# last night.
>
> My impression is that there were two parts to it. First was the
> environment/principles section which talked about physical objects and
> light (and motion), and then there were choices of widgets. For
> example, I didn't see anything in the first part that said that a text
> input had to be a single line and couldn't be a box.
>
> That made me think that we could use our widget set and apply Material
> environment and principles to it. If we decide not to, I would think
> you would want to have some sort of similar environment/principles
> document which seems like a fair amount of work. I think we'd end up
> looking different because we have different widgets and maybe some
> different colors. I'm pretty sure that we don't want to be different
> so much that we don't create things that folks want to use. The
> priority to me is just to prove that you can alter every pixel in every
> widget we have so that others can provide custom skins as well. So
> starting with Material principles seems like it would save us time, we
> can get something released, and can innovate more later.
>
> Maybe a good question for our users is: How many of you used the
> default Flex skins vs a whole new set of skins? If most folks
> completely re-skinned to match their corporate branding, it matters
> less what our default is, and more that we can allow folks to customize
> every pixel.
>
> The wireframe can be black and white, IMO. I was thinking that "vivid"
> would have parameterized colors.
>
> Since Bootstrap was mentioned, I want to point out that the Flat.swc is
> a rough approximation of the Flat theme which is a Bootstrap theme. It
> is a rough approximation because I could not use the Flat CSS file
> directly since it contains much more advanced CSS than we currently
> support on the SWF side. But it presumed that the Checkbox was a Label
> with a Span that hides in front of or behind the <input type="check" />
> in order to allow customizing every pixel. Looks like MDL uses the
> same Span trick but maybe without a symbol font.
>
> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
> should not have that extra Span. But it looks to me that a
> SkinnableCheckbox can add that extra Span and you either give it the
> same class name that BootStrap or MDL uses or create our own set of
> classnames and the CSS that goes with it.
>
> Of course, I could be wrong. This is not my area of expertise at all.
> -Alex
>
>
> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira"
> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> wrote:
>
> >Hi Alex,
> >
> >2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >
> >> Hi Carlos,
> >>
> >> Looks good to me. Thanks for doing this.
> >>
> >
> >Thanks :)
> >
> >>
> >> I'm not sure I understand all of the aspects of this effort. My
> >>current understanding is that Google Material is under the Apache
> >>License and thus we can use it if we want to. Am I correct that
> >>MaterialDesignLite is one implementation of Google Material and we
> >>could create our own implementation and it could be visually
> >>different?
> >>
> >
> >We can implement our own material in Royale, but I'm afraid that doing
> >that will not make us highlight our solution against the rest of
> >competitors. Another point is something I said various times:
> >When I did MDL, I notice a huge problem: MDL has its own set of
> >components, some are in all sets (Button) but others not (Card), and
> >they has it's own implementation, what make it almost impossible
> >generalize a theme. For this reason I always point that we need our
> own
> >set and there we can implement themes. But other
> >*externa* sets will never get this since they have its own
> >implementation and most important once you start to develop with MDL
> >you can't go back and change for other. So MDL is for me something we
> >have until our own set are robust and highly configurable in both the
> >things we can do and how can it could be represented, and switch
> >between style should be really easy to change the global look of an
> App
> >without much hassle.
> >
> >
> >>
> >> Also, IIRC, Material has different components than Flex did so we'd
> >> have to invent some new looks anyway. So having a TextInput with
> >> borders all around would just be our flavor of Material.
> >>
> >
> >That's what I point above. We must to *freeze* the list of components
> >at some time work over a concrete set We can then plan in the future
> >include a new component in the official set, and that will need to
> work
> >on the themes we already have to include the new one.
> >
> >
> >>
> >> Regarding colors, it looks like Material is parameterized around a
> >>couple of colors. So if we did our skins to work against
> >>parameterized colors then would it really matter what color we
> >>choose?
> >>
> >
> >That's completly right. I could make wireframe based on two or three
> >colors and as you change it in CSS all controls should tint
> >consistently.
> >
> >
> >>
> >> Regarding Basic components, right now Checkbox is a <label><input
> >>type="check"/>caption</label>. AIUI, you cannot style the <input> on
> >>many browsers, so I think we have to have a different set of
> elements
> >>in a checkbox. It looks like Bootstrap uses:
> >>
> >> <label><input type="check"/><span />Caption</label>
> >>
> >> Where the span uses a special symbol font with checked and unchecked
> >>boxes.
> >>
> >
> >That's what we need to figure. Should we make themes available in
> Basic?
> >if
> >so, has basic the right implementation?
> >If not, and if we don't want to change the actual very basic
> >implementation, we need to put some "skin" implementation that at
> least
> >in JS implementation I figure that will change one face (the actual
> >basic) with the theme face.
> >
> >I'm thinking loud, since this is something we should explorer all
> >together mixing the best ideas of people involved
> >
> >Thanks
> >
> >
> >
> >>
> >> Thanks,
> >> Alex
> >>
> >> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos
> >>Rovira"
> >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> wrote:
> >>
> >> >Hi,
> >> >
> >> >I want to expose my initial work (very very initial) on two styles
> >> >for Royale
> >> >
> >> >
> >> >Wireframe:
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fsnag.gy%2
> >> >FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa7b1b5a7
> >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=%2Fk8YQxC5bDOaC
> >> >D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
> >> >
> >> >(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://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fsnag.gy%2
> >> >FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa7b1b5a7
> >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=kxYE7ylOsXPUEeE
> >> >r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
> >> >
> >> >(*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 <ca...@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 <ha...@gmail.com>:
> >> >>
> >> >>> BTW, the kind of thing we should be striving for in theme-able
> >> >>>components is something like this:
> >> >>>
> >> >>>
> >> >>>https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fvcalend
> >> >>>ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cf
> >>
> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata
> >> >>>=
> >> b3VtV
> >> >>>VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
> >> >>><https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fvcalen
> >> >>>dar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7C
> >>
> >>>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdat
> >> >>>a=
> >> b3Vt
> >> >>>VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
> >> >>>
> >> >>> > On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fpaste.a
> >> >>>pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa
> >> >>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=bRWKxm
> >> >>>LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
> >>
> >>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> p
> >>>>>ast
> >>>>>e
> >> .
> >> >>>apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cf
> >>
> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata
> >> >>>=
> >> bRWKx
> >> >>>mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
> >> >>> >
> >> >>> > (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
> >><carlosrovira@apache.org
> >> >>> <ma...@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.lists@gmail.com
> <mailto:
> >> >>> harbs.lists@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
> >><aharui@adobe.com.INVALID
> >> >>> <ma...@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
> >> >>
> >> >>https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%
> >> >>2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa7b1
> >> >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=C7a72gwfH2
> >> >>64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >Carlos Rovira
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%2
> >> >Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa7b1b5
> >> >a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=C7a72gwfH264w
> >> >Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >>
> >>
> >
> >
> >--
> >
> ><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.c
> o
> >deo
> >scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b1b
> 5
> >a7b
> >34438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=Hm%2B6WIcqQT
> O
> >Hs0 UppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0>
> >
> >Carlos Rovira
> >
> >Director General
> >
> >M: +34 607 22 60 05
> >
> >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.co
> d
> >eos
> >copic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b1b5
> a
> >7b3
> >4438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=Hm%2B6WIcqQTO
> H
> >s0U
> >ppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0
> >
> >
> >Conocenos Avant2 en 1 minuto!
> ><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favan
> t
> >2.e
> >s%2F%23video&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b
> 1
> >b5a
> >7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=b%2FFMr1Aj
> i
> >t94 TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
Re: Working on UI Controls styling
Posted by Piotr Zarzycki <pi...@gmail.com>.
Carlos,
I just wanted to point to your last sentences. I think we don't know for
sure what can we do with Basic. Let's go and try if we came up that
something is not achievable let's discuss what need to be done.
Piotr
On Sat, Nov 4, 2017, 16:19 Carlos Rovira <ca...@apache.org> wrote:
> HI Alex,
>
>
> 2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
> > Hi Carlos,
> >
> > I skimmed through https://material.io/guidelines/# last night.
> >
> > My impression is that there were two parts to it. First was the
> > environment/principles section which talked about physical objects and
> > light (and motion), and then there were choices of widgets. For example,
> > I didn't see anything in the first part that said that a text input had
> to
> > be a single line and couldn't be a box.
> >
>
> Material guidelines could be a great way to start, but trying to give
> something different.
> I think that we need to get something that looks great while be clearly
> different to google material,
> bootstrap, and others so people could see us as an alternative. That could
> make people copying us
> or adopting the whole Apache Royale SDK that is what we want in the end
>
>
>
> >
> > That made me think that we could use our widget set and apply Material
> > environment and principles to it. If we decide not to, I would think you
> > would want to have some sort of similar environment/principles document
> > which seems like a fair amount of work. I think we'd end up looking
> > different because we have different widgets and maybe some different
> > colors. I'm pretty sure that we don't want to be different so much that
> > we don't create things that folks want to use. The priority to me is
> just
> > to prove that you can alter every pixel in every widget we have so that
> > others can provide custom skins as well. So starting with Material
> > principles seems like it would save us time, we can get something
> > released, and can innovate more later.
> >
>
> I think as you that we need a way to make the "presentation" of each
> component highly customizable.
> And we need to be different in visualization (art, colors, ...) but not in
> usability that is what people
> needs to be consistently
>
>
>
> >
> > Maybe a good question for our users is: How many of you used the default
> > Flex skins vs a whole new set of skins? If most folks completely
> > re-skinned to match their corporate branding, it matters less what our
> > default is, and more that we can allow folks to customize every pixel.
> >
> >
> We need both: a skin that will be highly customizable and to change skins
> to look very very different.
> People with lees money or time in their Apps will choose the first. People
> that has more resources will go with the second.
> Apache Royale needs to support both
>
>
> > The wireframe can be black and white, IMO. I was thinking that "vivid"
> > would have parameterized colors.
> >
> >
> I started to think that wireframe could end having lots of customization
> controls. For example:
>
> -2-3 main colors as we talked , and the same MDL does
> -possibilitiy to be solid colors, or gradients
> -possibility to have backgrounds more or less opaque
>
> if we see a concrete component like button:
>
> - configurable corners, square to round corners
> - more blocky (relief) or more flat
> ...
>
> So wireframe could be a concrete configuration of the main theme
>
>
>
> > Since Bootstrap was mentioned, I want to point out that the Flat.swc is a
> > rough approximation of the Flat theme which is a Bootstrap theme. It is
> a
> > rough approximation because I could not use the Flat CSS file directly
> > since it contains much more advanced CSS than we currently support on the
> > SWF side. But it presumed that the Checkbox was a Label with a Span that
> > hides in front of or behind the <input type="check" /> in order to allow
> > customizing every pixel. Looks like MDL uses the same Span trick but
> > maybe without a symbol font.
> >
> > Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
> should
> > not have that extra Span. But it looks to me that a SkinnableCheckbox
> can
> > add that extra Span and you either give it the same class name that
> > BootStrap or MDL uses or create our own set of classnames and the CSS
> that
> > goes with it.
> >
> >
> The problem with Basic could be that if is very very basic and looks with a
> very basic look (as it is very poorly stylizable), I think
> People will not use it at all, in this case, I'll don't understand the goal
> with basic. It's intend ended as a base
> but to not use in production? For this reason is what I want to know if you
> think this theme feature could be plugged in basic or not.
>
>
>
>
> > Of course, I could be wrong. This is not my area of expertise at all.
> >
>
> Hi Alex, maybe UX is not your expertise area, but your help here is very
> needed since we can get to great ideas in this field, but
> maybe don't know how to bring it to implementation in Apache Royale. I
> think that you, Peter, Harbs,... are needed in order to
> make this happen in the pure arquitecture side or this feature.
>
> Thanks
>
> -Alex
> >
> >
> > On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira"
> > <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> > wrote:
> >
> > >Hi Alex,
> > >
> > >2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> > >
> > >> Hi Carlos,
> > >>
> > >> Looks good to me. Thanks for doing this.
> > >>
> > >
> > >Thanks :)
> > >
> > >>
> > >> I'm not sure I understand all of the aspects of this effort. My
> current
> > >> understanding is that Google Material is under the Apache License and
> > >>thus
> > >> we can use it if we want to. Am I correct that MaterialDesignLite is
> > >>one
> > >> implementation of Google Material and we could create our own
> > >> implementation and it could be visually different?
> > >>
> > >
> > >We can implement our own material in Royale, but I'm afraid that doing
> > >that
> > >will not make us
> > >highlight our solution against the rest of competitors. Another point is
> > >something I said various times:
> > >When I did MDL, I notice a huge problem: MDL has its own set of
> > >components,
> > >some are in all sets (Button)
> > >but others not (Card), and they has it's own implementation, what make
> it
> > >almost impossible generalize
> > >a theme. For this reason I always point that we need our own set and
> there
> > >we can implement themes. But other
> > >*externa* sets will never get this since they have its own
> implementation
> > >and most important once you start to develop
> > >with MDL you can't go back and change for other. So MDL is for me
> > >something
> > >we have until our own set are robust and
> > >highly configurable in both the things we can do and how can it could be
> > >represented, and switch between style should be
> > >really easy to change the global look of an App without much hassle.
> > >
> > >
> > >>
> > >> Also, IIRC, Material has different components than Flex did so we'd
> have
> > >> to invent some new looks anyway. So having a TextInput with borders
> all
> > >> around would just be our flavor of Material.
> > >>
> > >
> > >That's what I point above. We must to *freeze* the list of components at
> > >some time work over a concrete set
> > >We can then plan in the future include a new component in the official
> > >set,
> > >and that will need to work on the themes we already
> > >have to include the new one.
> > >
> > >
> > >>
> > >> Regarding colors, it looks like Material is parameterized around a
> > >>couple
> > >> of colors. So if we did our skins to work against parameterized
> colors
> > >> then would it really matter what color we choose?
> > >>
> > >
> > >That's completly right. I could make wireframe based on two or three
> > >colors
> > >and as you change it in CSS all controls should tint
> > >consistently.
> > >
> > >
> > >>
> > >> Regarding Basic components, right now Checkbox is a <label><input
> > >> type="check"/>caption</label>. AIUI, you cannot style the <input> on
> > >>many
> > >> browsers, so I think we have to have a different set of elements in a
> > >> checkbox. It looks like Bootstrap uses:
> > >>
> > >> <label><input type="check"/><span />Caption</label>
> > >>
> > >> Where the span uses a special symbol font with checked and unchecked
> > >>boxes.
> > >>
> > >
> > >That's what we need to figure. Should we make themes available in Basic?
> > >if
> > >so, has basic the right implementation?
> > >If not, and if we don't want to change the actual very basic
> > >implementation, we need to put some "skin" implementation
> > >that at least in JS implementation I figure that will change one face
> (the
> > >actual basic) with the theme face.
> > >
> > >I'm thinking loud, since this is something we should explorer all
> together
> > >mixing the best ideas of people involved
> > >
> > >Thanks
> > >
> > >
> > >
> > >>
> > >> Thanks,
> > >> Alex
> > >>
> > >> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos
> > >>Rovira"
> > >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
> > >>
> > >> >Hi,
> > >> >
> > >> >I want to expose my initial work (very very initial) on two styles
> for
> > >> >Royale
> > >> >
> > >> >
> > >> >Wireframe:
> > >> >https://na01.safelinks.protection.outlook.com/?url=
> > >> https%3A%2F%2Fsnag.gy%2
> > >> >FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> > >> 0f48%7Cfa7b1b5a7
> > >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> > >> sdata=%2Fk8YQxC5bDOaC
> > >> >D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
> > >> >
> > >> >(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://na01.safelinks.protection.outlook.com/?url=
> > >> https%3A%2F%2Fsnag.gy%2
> > >> >FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> > >> 0f48%7Cfa7b1b5a7
> > >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> > >> sdata=kxYE7ylOsXPUEeE
> > >> >r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
> > >> >
> > >> >(*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 <ca...@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 <ha...@gmail.com>:
> > >> >>
> > >> >>> BTW, the kind of thing we should be striving for in theme-able
> > >> >>>components
> > >> >>> is something like this:
> > >> >>>
> > >> >>>
> > >> >>>https://na01.safelinks.protection.outlook.com/?url=
> > >> https%3A%2F%2Fvcalend
> > >> >>>ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> > >> 0f48%7Cf
> > >> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
> > >> b3VtV
> > >> >>>VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
> > >> >>><https://na01.safelinks.protection.outlook.com/?url=
> > >> https%3A%2F%2Fvcalen
> > >> >>>dar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> > >> 0f48%7C
> > >>
> >>>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
> > >> b3Vt
> > >> >>>VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
> > >> >>>
> > >> >>> > On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
> > >> https%3A%2F%2Fpaste.a
> > >> >>>pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> > >> 0f48%7Cfa
> > >> >>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> > >> sdata=bRWKxm
> > >> >>>LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
> > >>
> > >>>>><https://na01.safelinks.protection.outlook.com/?url=
> > https%3A%2F%2Fpast
> > >>>>>e
> > >> .
> > >> >>>apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> > >> 0f48%7Cf
> > >> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
> > >> bRWKx
> > >> >>>mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
> > >> >>> >
> > >> >>> > (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
> > >><carlosrovira@apache.org
> > >> >>> <ma...@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.lists@gmail.com
> <mailto:
> > >> >>> harbs.lists@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
> > >><aharui@adobe.com.INVALID
> > >> >>> <ma...@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
> > >> >>
> > >> >>https://na01.safelinks.protection.outlook.com/?url=
> > >> http%3A%2F%2Fabout.me%
> > >> >>2Fcarlosrovira&data=02%7C0
> <https://maps.google.com/?q=osrovira%26data%3D02%257C0&entry=gmail&source=g>
> 1%7C%7C203485b5b9c744aed92608d52250
> > >> 0f48%7Cfa7b1
> > >> >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> > >> sdata=C7a72gwfH2
> > >> >>64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> >--
> > >> >Carlos Rovira
> > >> >https://na01.safelinks.protection.outlook.com/?url=
> > >> http%3A%2F%2Fabout.me%2
> > >> >Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> > >> 0f48%7Cfa7b1b5
> > >> >a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> > >> sdata=C7a72gwfH264w
> > >> >Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> > >>
> > >>
> > >
> > >
> > >--
> > >
> > ><https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fwww.codeo
> > >scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
> > d8cf%7Cfa7b1b5a7b
> > >34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> > sdata=Hm%2B6WIcqQTOHs0
> > >UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> > d8cf%7Cfa7b1b5a7b3
> > >4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> > sdata=Hm%2B6WIcqQTOHs0U
> > >ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> > d8cf%7Cfa7b1b5a
> > >7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> > sdata=b%2FFMr1Ajit94
> > >TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
+1.
> On Nov 6, 2017, at 8:22 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Harbs,
>
> If we go with Basic as seems everybody suggest, I think we should not mix
> with Express. We can "copy" some Express knowledge, but not make it
> dependent, to avoid having a Frankenstein
> Basic is the core, and from there we have Express and the new stylizable set
>
> 2017-11-05 22:01 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
>
>> I was thinking about that and new component set is the approach which we
>> should try, but we need to base on something. My first thoughts was that it
>> should be Basic, cause I bet that once we start create style for each
>> component we will end up with some issue or we would like to create some
>> additional features to those controls in order to make that theme happen.
>> It leads my thought then farther let's say that we will start work in
>> following way:
>> 1) Basic is our base
>> 2) Carlos will prepare some appearance for component
>> 3) We are starting to work on that, but it's end up that our component need
>> some additional feature, which is do not suits for Basic
>> 4) We are adds that feature to Express and use in that place Express
>> component.
>>
>> It ends up that our component theme will be mix of Express and Basic
>>
>> Second approach is - Forget about Express, use Basic only and add to Theme
>> set features if needed. Express will be always separate set, FAT and it
>> will be responsibility for user if he would like to style it. - If our
>> implementation will be in Theme enough robust, user should be able to use
>> in his application Express with some styles from Theme set.
>>
>> Thoughts ?
>> Piotr
>>
>>
>> 2017-11-05 11:21 GMT+01:00 Harbs <ha...@gmail.com>:
>>
>>> I would suggest starting a new component set with a fresh slate called
>>> Themed (or something like that).
>>>
>>> The Themed component set should give priority to style-ablitity and ease
>>> of use over just about every other consideration. I think of Express as
>>> more of a middle-of the road approach to make things easier. A Themed set
>>> would be more of a replacement for mx and spark.
>>>
>>> Yes. Definitely make a clear list of supported components. It’s probably
>>> more important to have quality of components rather than quantity. A few
>>> well constructed components is better than a lot of half-baked ones. More
>>> components could always be added.
>>>
>>> I’m very glad to hear that Angelo is working with you. That’s great news!
>>>
>>> Harbs
>>>
>>>> On Nov 5, 2017, at 12:12 PM, Carlos Rovira <
>>> carlos.rovira@codeoscopic.com> wrote:
>>>>
>>>> ok Alex,
>>>>
>>>> so if I understand correctly, you mean that we create our own set, with
>>>> Basic as base right?
>>>> but we should go with Express? It's great that we could create many
>> sets
>>> in
>>>> Royale, and I think the Basic use
>>>> you commented is very licit and didn't think about that. But we must
>>> think
>>>> in some *main* set, maybe is Express
>>>> and that I want to focus this effort for that concrete set.
>>>>
>>>> I mean, one important thing here is that we all agree in support a
>>> concrete
>>>> list of UI controls and components
>>>> I plan to make a discuss thread for this, since the theme feature will
>>>> affect only to that controls, and if we want to include a new one
>>>> we should vote to include it, since it implies to include in design,
>>>> implementation and all themes that we want to support.
>>>>
>>>> I think I'll create a discuss thread with this an other things we
>> talked
>>>> about since this is a huge effort and is important for all the
>>>> people that will be involved to work around things discussed, voted and
>>>> approved by all.
>>>> We need to be synced here or we'll end working too much for somehitng
>>> that
>>>> does not get to be useful in the end. I want to ensure this before
>>>> to start investing a huge amount of time.
>>>>
>>>> As well I was contacted by Angelo and talk about all this. He's very
>>>> passionate as well on this and we'll seeing how we can combine our
>>> efforts
>>>> and if someone
>>>> more wants to join us.
>>>>
>>>> I'll be writing the discussion thread in order to plan the effort in
>>> short.
>>>> Stay tuned :)
>>>>
>>>> 2017-11-05 8:29 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>
>>>>> Hi Carlos,
>>>>>
>>>>> I think we're pretty much in agreement. Regarding Basic, for me, I
>> have
>>>>> created plenty of web pages with non-styleable checkboxes. I don't
>> care
>>>>> that the checkbox looks different on different browsers. I just want
>>> the
>>>>> smallest simplest output. Just like taking an HTML editor and
>> slapping
>>> in
>>>>> a few tags and calling it done. Would that be production? Sure, if
>> I'm
>>>>> just want someone to check a box before enabling a download button.
>>> IOW,
>>>>> it would be for internal customers only.
>>>>>
>>>>> So, IMO, a Skinnable/Themeable component set would be something
>> else. I
>>>>> think you will need that extra Span for a Checkbox. IMO, we should
>> just
>>>>> go and build these new components. And when we get it mostly working,
>>> we
>>>>> can compare against Basic and see if we want to parameterize the views
>>> in
>>>>> the low-level Basic components or not.
>>>>>
>>>>> My 2 cents,
>>>>> -Alex
>>>>>
>>>>> On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>> Rovira"
>>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>>>>
>>>>>> HI Alex,
>>>>>>
>>>>>>
>>>>>> 2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>>>
>>>>>>> Hi Carlos,
>>>>>>>
>>>>>>> I skimmed through
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>> https%3A%2F%2Fmaterial
>>>>>>> .io%2Fguidelines%2F%23&data=02%7C01%7C%
>> 7Cbb03216ec0b84fcb6ab108d52397
>>>>> 82e0
>>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>> 7C636454056000808812&sdata=g5
>>>>>>> M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last
>>> night.
>>>>>>>
>>>>>>> My impression is that there were two parts to it. First was the
>>>>>>> environment/principles section which talked about physical objects
>> and
>>>>>>> light (and motion), and then there were choices of widgets. For
>>>>>>> example,
>>>>>>> I didn't see anything in the first part that said that a text input
>>> had
>>>>>>> to
>>>>>>> be a single line and couldn't be a box.
>>>>>>>
>>>>>>
>>>>>> Material guidelines could be a great way to start, but trying to give
>>>>>> something different.
>>>>>> I think that we need to get something that looks great while be
>> clearly
>>>>>> different to google material,
>>>>>> bootstrap, and others so people could see us as an alternative. That
>>> could
>>>>>> make people copying us
>>>>>> or adopting the whole Apache Royale SDK that is what we want in the
>> end
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> That made me think that we could use our widget set and apply
>> Material
>>>>>>> environment and principles to it. If we decide not to, I would
>> think
>>>>>>> you
>>>>>>> would want to have some sort of similar environment/principles
>>> document
>>>>>>> which seems like a fair amount of work. I think we'd end up looking
>>>>>>> different because we have different widgets and maybe some different
>>>>>>> colors. I'm pretty sure that we don't want to be different so much
>>> that
>>>>>>> we don't create things that folks want to use. The priority to me
>> is
>>>>>>> just
>>>>>>> to prove that you can alter every pixel in every widget we have so
>>> that
>>>>>>> others can provide custom skins as well. So starting with Material
>>>>>>> principles seems like it would save us time, we can get something
>>>>>>> released, and can innovate more later.
>>>>>>>
>>>>>>
>>>>>> I think as you that we need a way to make the "presentation" of each
>>>>>> component highly customizable.
>>>>>> And we need to be different in visualization (art, colors, ...) but
>>> not in
>>>>>> usability that is what people
>>>>>> needs to be consistently
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Maybe a good question for our users is: How many of you used the
>>>>>>> default
>>>>>>> Flex skins vs a whole new set of skins? If most folks completely
>>>>>>> re-skinned to match their corporate branding, it matters less what
>> our
>>>>>>> default is, and more that we can allow folks to customize every
>> pixel.
>>>>>>>
>>>>>>>
>>>>>> We need both: a skin that will be highly customizable and to change
>>> skins
>>>>>> to look very very different.
>>>>>> People with lees money or time in their Apps will choose the first.
>>> People
>>>>>> that has more resources will go with the second.
>>>>>> Apache Royale needs to support both
>>>>>>
>>>>>>
>>>>>>> The wireframe can be black and white, IMO. I was thinking that
>>> "vivid"
>>>>>>> would have parameterized colors.
>>>>>>>
>>>>>>>
>>>>>> I started to think that wireframe could end having lots of
>>> customization
>>>>>> controls. For example:
>>>>>>
>>>>>> -2-3 main colors as we talked , and the same MDL does
>>>>>> -possibilitiy to be solid colors, or gradients
>>>>>> -possibility to have backgrounds more or less opaque
>>>>>>
>>>>>> if we see a concrete component like button:
>>>>>>
>>>>>> - configurable corners, square to round corners
>>>>>> - more blocky (relief) or more flat
>>>>>> ...
>>>>>>
>>>>>> So wireframe could be a concrete configuration of the main theme
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Since Bootstrap was mentioned, I want to point out that the Flat.swc
>>> is
>>>>>>> a
>>>>>>> rough approximation of the Flat theme which is a Bootstrap theme.
>> It
>>>>>>> is a
>>>>>>> rough approximation because I could not use the Flat CSS file
>> directly
>>>>>>> since it contains much more advanced CSS than we currently support
>> on
>>>>>>> the
>>>>>>> SWF side. But it presumed that the Checkbox was a Label with a Span
>>>>>>> that
>>>>>>> hides in front of or behind the <input type="check" /> in order to
>>> allow
>>>>>>> customizing every pixel. Looks like MDL uses the same Span trick
>> but
>>>>>>> maybe without a symbol font.
>>>>>>>
>>>>>>> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
>>>>>>> should
>>>>>>> not have that extra Span. But it looks to me that a
>> SkinnableCheckbox
>>>>>>> can
>>>>>>> add that extra Span and you either give it the same class name that
>>>>>>> BootStrap or MDL uses or create our own set of classnames and the
>> CSS
>>>>>>> that
>>>>>>> goes with it.
>>>>>>>
>>>>>>>
>>>>>> The problem with Basic could be that if is very very basic and looks
>>> with
>>>>>> a
>>>>>> very basic look (as it is very poorly stylizable), I think
>>>>>> People will not use it at all, in this case, I'll don't understand
>> the
>>>>>> goal
>>>>>> with basic. It's intend ended as a base
>>>>>> but to not use in production? For this reason is what I want to know
>> if
>>>>>> you
>>>>>> think this theme feature could be plugged in basic or not.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Of course, I could be wrong. This is not my area of expertise at
>> all.
>>>>>>>
>>>>>>
>>>>>> Hi Alex, maybe UX is not your expertise area, but your help here is
>>> very
>>>>>> needed since we can get to great ideas in this field, but
>>>>>> maybe don't know how to bring it to implementation in Apache Royale.
>> I
>>>>>> think that you, Peter, Harbs,... are needed in order to
>>>>>> make this happen in the pure arquitecture side or this feature.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -Alex
>>>>>>>
>>>>>>>
>>>>>>> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>>>>>> Rovira"
>>>>>>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com
>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Alex,
>>>>>>>>
>>>>>>>> 2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>>>>>
>>>>>>>>> Hi Carlos,
>>>>>>>>>
>>>>>>>>> Looks good to me. Thanks for doing this.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks :)
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm not sure I understand all of the aspects of this effort. My
>>>>>>> current
>>>>>>>>> understanding is that Google Material is under the Apache License
>>> and
>>>>>>>>> thus
>>>>>>>>> we can use it if we want to. Am I correct that MaterialDesignLite
>>> is
>>>>>>>>> one
>>>>>>>>> implementation of Google Material and we could create our own
>>>>>>>>> implementation and it could be visually different?
>>>>>>>>>
>>>>>>>>
>>>>>>>> We can implement our own material in Royale, but I'm afraid that
>>> doing
>>>>>>>> that
>>>>>>>> will not make us
>>>>>>>> highlight our solution against the rest of competitors. Another
>> point
>>>>>>> is
>>>>>>>> something I said various times:
>>>>>>>> When I did MDL, I notice a huge problem: MDL has its own set of
>>>>>>>> components,
>>>>>>>> some are in all sets (Button)
>>>>>>>> but others not (Card), and they has it's own implementation, what
>>> make
>>>>>>> it
>>>>>>>> almost impossible generalize
>>>>>>>> a theme. For this reason I always point that we need our own set
>> and
>>>>>>> there
>>>>>>>> we can implement themes. But other
>>>>>>>> *externa* sets will never get this since they have its own
>>>>>>> implementation
>>>>>>>> and most important once you start to develop
>>>>>>>> with MDL you can't go back and change for other. So MDL is for me
>>>>>>>> something
>>>>>>>> we have until our own set are robust and
>>>>>>>> highly configurable in both the things we can do and how can it
>> could
>>>>>>> be
>>>>>>>> represented, and switch between style should be
>>>>>>>> really easy to change the global look of an App without much
>> hassle.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also, IIRC, Material has different components than Flex did so
>> we'd
>>>>>>> have
>>>>>>>>> to invent some new looks anyway. So having a TextInput with
>> borders
>>>>>>> all
>>>>>>>>> around would just be our flavor of Material.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's what I point above. We must to *freeze* the list of
>> components
>>>>>>> at
>>>>>>>> some time work over a concrete set
>>>>>>>> We can then plan in the future include a new component in the
>>> official
>>>>>>>> set,
>>>>>>>> and that will need to work on the themes we already
>>>>>>>> have to include the new one.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regarding colors, it looks like Material is parameterized around a
>>>>>>>>> couple
>>>>>>>>> of colors. So if we did our skins to work against parameterized
>>>>>>> colors
>>>>>>>>> then would it really matter what color we choose?
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's completly right. I could make wireframe based on two or
>> three
>>>>>>>> colors
>>>>>>>> and as you change it in CSS all controls should tint
>>>>>>>> consistently.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regarding Basic components, right now Checkbox is a <label><input
>>>>>>>>> type="check"/>caption</label>. AIUI, you cannot style the <input>
>>> on
>>>>>>>>> many
>>>>>>>>> browsers, so I think we have to have a different set of elements
>> in
>>> a
>>>>>>>>> checkbox. It looks like Bootstrap uses:
>>>>>>>>>
>>>>>>>>> <label><input type="check"/><span />Caption</label>
>>>>>>>>>
>>>>>>>>> Where the span uses a special symbol font with checked and
>> unchecked
>>>>>>>>> boxes.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's what we need to figure. Should we make themes available in
>>>>>>> Basic?
>>>>>>>> if
>>>>>>>> so, has basic the right implementation?
>>>>>>>> If not, and if we don't want to change the actual very basic
>>>>>>>> implementation, we need to put some "skin" implementation
>>>>>>>> that at least in JS implementation I figure that will change one
>> face
>>>>>>> (the
>>>>>>>> actual basic) with the theme face.
>>>>>>>>
>>>>>>>> I'm thinking loud, since this is something we should explorer all
>>>>>>> together
>>>>>>>> mixing the best ideas of people involved
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos
>>>>>>>>> Rovira"
>>>>>>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I want to expose my initial work (very very initial) on two
>> styles
>>>>>>> for
>>>>>>>>>> Royale
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Wireframe:
>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fsnag.gy%2
>>>>>>>>>> FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa7b1b5a7
>>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=%2Fk8YQxC5bDOaC
>>>>>>>>>> D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
>>>>>>>>>>
>>>>>>>>>> (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://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fsnag.gy%2
>>>>>>>>>> FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa7b1b5a7
>>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=kxYE7ylOsXPUEeE
>>>>>>>>>> r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
>>>>>>>>>>
>>>>>>>>>> (*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 <
>> carlosrovira@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 <ha...@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> BTW, the kind of thing we should be striving for in theme-able
>>>>>>>>>>>> components
>>>>>>>>>>>> is something like this:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fvcalend
>>>>>>>>>>>> ar.netlify.com%2F&data=02%7C01%7C%
>> 7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cf
>>>>>>>>>
>>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636452649612378558&sdata=
>>>>>>>>> b3VtV
>>>>>>>>>>>> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
>>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fvcalen
>>>>>>>>>>>> dar.netlify.com%2F&data=02%7C01%7C%
>>> 7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7C
>>>>>>>>>
>>>>>>>>>> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636452649612378558&sdata=
>>>>>>>>> b3Vt
>>>>>>>>>>>> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fpaste.a
>>>>>>>>>>>> pache.org%2FcOBC&data=02%7C01%7C%
>> 7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa
>>>>>>>>>>>> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=bRWKxm
>>>>>>>>>>>> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
>>>>>>>>>
>>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> https%3A%2F%2Fpast
>>>>>>>>>>>> e
>>>>>>>>> .
>>>>>>>>>>>> apache.org%2FcOBC&data=02%7C01%7C%
>> 7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cf
>>>>>>>>>
>>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636452649612378558&sdata=
>>>>>>>>> bRWKx
>>>>>>>>>>>> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
>>>>>>>>>>>>>
>>>>>>>>>>>>> (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
>>>>>>>>> <carlosrovira@apache.org
>>>>>>>>>>>> <ma...@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.lists@gmail.com
>>>>>>> <mailto:
>>>>>>>>>>>> harbs.lists@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
>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>
>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> http%3A%2F%2Fabout.me%
>>>>>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa7b1
>>>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=C7a72gwfH2
>>>>>>>>>>> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Carlos Rovira
>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> http%3A%2F%2Fabout.me%2
>>>>>>>>>> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa7b1b5
>>>>>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=C7a72gwfH264w
>>>>>>>>>> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> http%3A%2F%2Fwww.codeo
>>>>>>>> scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
>>>>>>> d8cf%7Cfa7b1b5a7b
>>>>>>>> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>>>>> sdata=Hm%2B6WIcqQTOHs0
>>>>>>>> UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>>>>>>> d8cf%7Cfa7b1b5a7b3
>>>>>>>> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>>>>> sdata=Hm%2B6WIcqQTOHs0U
>>>>>>>> ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>>>>>>> d8cf%7Cfa7b1b5a
>>>>>>>> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>>>>> sdata=b%2FFMr1Ajit94
>>>>>>>> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>> http%3A%2F%2Fabout.me%2
>>>>>> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
>>>>> 82e0%7Cfa7b1b5
>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
>>>>> sdata=wYPMWW1wpTbtm
>>>>>> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> <http://www.codeoscopic.com>
>>>>
>>>> Carlos Rovira
>>>>
>>>> Director General
>>>>
>>>> M: +34 607 22 60 05
>>>>
>>>> http://www.codeoscopic.com
>>>>
>>>>
>>>> Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
>>>>
>>>>
>>>> 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.
>>>
>>>
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>> Patreon: *https://www.patreon.com/piotrzarzycki
>> <https://www.patreon.com/piotrzarzycki>*
>>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: Working on UI Controls styling
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Harbs,
That looks like good starting point, but this last approach where we for
example generate UIDs for every component. This UID at the end will have to
end up as an id in HTML or compiler will have to bind together css with
that uid.
The first approach where you have created couple of css classes, what will
happen if we in our code do something like that:
element.classList.add("bug");
element.classList.add("bug:hover");
I didn't check above approach, but if you have this code ready could you
try. Maybe that will be the solution.
Thanks, Piotr
2017-11-07 12:24 GMT+01:00 Harbs <ha...@gmail.com>:
> Some food for thought:
>
> I created a custom component for “buttons” which allow simple skinning
> using image files. It works like this:
> https://paste.apache.org/tc8f <https://paste.apache.org/tc8f>
>
> Specifying different states can be done using the following css:
> .bug
> {
> background-image: url ('assets/up/report-bug.png');
> }
> .bug:hover{
> background-image: url ('assets/over/report-bug.png');
> }
> .bug:active{
> background-image: url ('assets/down/report-bug.png');
> }
> .bug:disabled{
> background-image: url ('assets/disabled/report-bug.png');
> }
>
> It works well, but the problem with this approach is that it requires
> multiple css entries for every button.
>
> Using it is done like this:
> <comp:PanelButton id="bugButton"
> enabled="{bugReportEnabled}" width="72"
> height="82"
> x="19" y="283"
> click="reportBug()" className="bug"/>
>
> I wanted to allow the following:
>
> <comp:PanelButton id="bugButton"
> enabled="{bugReportEnabled}" width="72"
> height="82"
> x="19" y="283"
> click="reportBug()" className="bug"
> image="assets/up/report-bug.png"
> hoverImage="assets/over/report-bug.png"
> activeImage="assets/down/report-bug.png"
> disabledImage="assets/
> disabled/report-bug.png"/>
>
> However, this is harder than you’d expect in HTML. Apparently there’s no
> way to set pseudo-styles using inline css.[1][2].
>
> There are a couple of interesting work-arounds. One is using mouse
> events.[3]
> Another is by creating CSS on the fly.[4] The answer assumes that the css
> is created on the server, but using the ideas I proposed in the
> ThemeManager class, that can be done on the client dynamically.
>
> The challenge with the last approach would be in guaranteeing the css is
> unique to the images (or individual component). One option on that front
> would be to generate UIDs when the component is instantiated. A
> consideration is garbage-collecting CSS selectors when components might be
> removed.
>
> I hope these ideas are helpful.
>
> Harbs
>
> [1]https://stackoverflow.com/questions/5293280/css-pseudo-
> classes-with-inline-styles <https://stackoverflow.com/
> questions/5293280/css-pseudo-classes-with-inline-styles>
> [2]https://stackoverflow.com/questions/986618/is-it-
> possible-to-create-inline-pseudo-styles <https://stackoverflow.com/
> questions/986618/is-it-possible-to-create-inline-pseudo-styles>
> [3]https://stackoverflow.com/a/5293426/5475183 <
> https://stackoverflow.com/a/5293426/5475183>
> [4]https://stackoverflow.com/a/39712777/5475183 <
> https://stackoverflow.com/a/39712777/5475183>
>
> > On Nov 6, 2017, at 8:22 PM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Hi Harbs,
> >
> > If we go with Basic as seems everybody suggest, I think we should not
> mix
> > with Express. We can "copy" some Express knowledge, but not make it
> > dependent, to avoid having a Frankenstein
> > Basic is the core, and from there we have Express and the new stylizable
> set
> >
> > 2017-11-05 22:01 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
> >
> >> I was thinking about that and new component set is the approach which we
> >> should try, but we need to base on something. My first thoughts was
> that it
> >> should be Basic, cause I bet that once we start create style for each
> >> component we will end up with some issue or we would like to create some
> >> additional features to those controls in order to make that theme
> happen.
> >> It leads my thought then farther let's say that we will start work in
> >> following way:
> >> 1) Basic is our base
> >> 2) Carlos will prepare some appearance for component
> >> 3) We are starting to work on that, but it's end up that our component
> need
> >> some additional feature, which is do not suits for Basic
> >> 4) We are adds that feature to Express and use in that place Express
> >> component.
> >>
> >> It ends up that our component theme will be mix of Express and Basic
> >>
> >> Second approach is - Forget about Express, use Basic only and add to
> Theme
> >> set features if needed. Express will be always separate set, FAT and it
> >> will be responsibility for user if he would like to style it. - If our
> >> implementation will be in Theme enough robust, user should be able to
> use
> >> in his application Express with some styles from Theme set.
> >>
> >> Thoughts ?
> >> Piotr
> >>
> >>
> >> 2017-11-05 11:21 GMT+01:00 Harbs <ha...@gmail.com>:
> >>
> >>> I would suggest starting a new component set with a fresh slate called
> >>> Themed (or something like that).
> >>>
> >>> The Themed component set should give priority to style-ablitity and
> ease
> >>> of use over just about every other consideration. I think of Express as
> >>> more of a middle-of the road approach to make things easier. A Themed
> set
> >>> would be more of a replacement for mx and spark.
> >>>
> >>> Yes. Definitely make a clear list of supported components. It’s
> probably
> >>> more important to have quality of components rather than quantity. A
> few
> >>> well constructed components is better than a lot of half-baked ones.
> More
> >>> components could always be added.
> >>>
> >>> I’m very glad to hear that Angelo is working with you. That’s great
> news!
> >>>
> >>> Harbs
> >>>
> >>>> On Nov 5, 2017, at 12:12 PM, Carlos Rovira <
> >>> carlos.rovira@codeoscopic.com> wrote:
> >>>>
> >>>> ok Alex,
> >>>>
> >>>> so if I understand correctly, you mean that we create our own set,
> with
> >>>> Basic as base right?
> >>>> but we should go with Express? It's great that we could create many
> >> sets
> >>> in
> >>>> Royale, and I think the Basic use
> >>>> you commented is very licit and didn't think about that. But we must
> >>> think
> >>>> in some *main* set, maybe is Express
> >>>> and that I want to focus this effort for that concrete set.
> >>>>
> >>>> I mean, one important thing here is that we all agree in support a
> >>> concrete
> >>>> list of UI controls and components
> >>>> I plan to make a discuss thread for this, since the theme feature will
> >>>> affect only to that controls, and if we want to include a new one
> >>>> we should vote to include it, since it implies to include in design,
> >>>> implementation and all themes that we want to support.
> >>>>
> >>>> I think I'll create a discuss thread with this an other things we
> >> talked
> >>>> about since this is a huge effort and is important for all the
> >>>> people that will be involved to work around things discussed, voted
> and
> >>>> approved by all.
> >>>> We need to be synced here or we'll end working too much for somehitng
> >>> that
> >>>> does not get to be useful in the end. I want to ensure this before
> >>>> to start investing a huge amount of time.
> >>>>
> >>>> As well I was contacted by Angelo and talk about all this. He's very
> >>>> passionate as well on this and we'll seeing how we can combine our
> >>> efforts
> >>>> and if someone
> >>>> more wants to join us.
> >>>>
> >>>> I'll be writing the discussion thread in order to plan the effort in
> >>> short.
> >>>> Stay tuned :)
> >>>>
> >>>> 2017-11-05 8:29 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >>>>
> >>>>> Hi Carlos,
> >>>>>
> >>>>> I think we're pretty much in agreement. Regarding Basic, for me, I
> >> have
> >>>>> created plenty of web pages with non-styleable checkboxes. I don't
> >> care
> >>>>> that the checkbox looks different on different browsers. I just want
> >>> the
> >>>>> smallest simplest output. Just like taking an HTML editor and
> >> slapping
> >>> in
> >>>>> a few tags and calling it done. Would that be production? Sure, if
> >> I'm
> >>>>> just want someone to check a box before enabling a download button.
> >>> IOW,
> >>>>> it would be for internal customers only.
> >>>>>
> >>>>> So, IMO, a Skinnable/Themeable component set would be something
> >> else. I
> >>>>> think you will need that extra Span for a Checkbox. IMO, we should
> >> just
> >>>>> go and build these new components. And when we get it mostly
> working,
> >>> we
> >>>>> can compare against Basic and see if we want to parameterize the
> views
> >>> in
> >>>>> the low-level Basic components or not.
> >>>>>
> >>>>> My 2 cents,
> >>>>> -Alex
> >>>>>
> >>>>> On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com on behalf of Carlos
> >>> Rovira"
> >>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> wrote:
> >>>>>
> >>>>>> HI Alex,
> >>>>>>
> >>>>>>
> >>>>>> 2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >>>>>>
> >>>>>>> Hi Carlos,
> >>>>>>>
> >>>>>>> I skimmed through
> >>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>> https%3A%2F%2Fmaterial
> >>>>>>> .io%2Fguidelines%2F%23&data=02%7C01%7C%
> >> 7Cbb03216ec0b84fcb6ab108d52397
> >>>>> 82e0
> >>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>>>> 7C636454056000808812&sdata=g5
> >>>>>>> M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last
> >>> night.
> >>>>>>>
> >>>>>>> My impression is that there were two parts to it. First was the
> >>>>>>> environment/principles section which talked about physical objects
> >> and
> >>>>>>> light (and motion), and then there were choices of widgets. For
> >>>>>>> example,
> >>>>>>> I didn't see anything in the first part that said that a text input
> >>> had
> >>>>>>> to
> >>>>>>> be a single line and couldn't be a box.
> >>>>>>>
> >>>>>>
> >>>>>> Material guidelines could be a great way to start, but trying to
> give
> >>>>>> something different.
> >>>>>> I think that we need to get something that looks great while be
> >> clearly
> >>>>>> different to google material,
> >>>>>> bootstrap, and others so people could see us as an alternative. That
> >>> could
> >>>>>> make people copying us
> >>>>>> or adopting the whole Apache Royale SDK that is what we want in the
> >> end
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> That made me think that we could use our widget set and apply
> >> Material
> >>>>>>> environment and principles to it. If we decide not to, I would
> >> think
> >>>>>>> you
> >>>>>>> would want to have some sort of similar environment/principles
> >>> document
> >>>>>>> which seems like a fair amount of work. I think we'd end up
> looking
> >>>>>>> different because we have different widgets and maybe some
> different
> >>>>>>> colors. I'm pretty sure that we don't want to be different so much
> >>> that
> >>>>>>> we don't create things that folks want to use. The priority to me
> >> is
> >>>>>>> just
> >>>>>>> to prove that you can alter every pixel in every widget we have so
> >>> that
> >>>>>>> others can provide custom skins as well. So starting with Material
> >>>>>>> principles seems like it would save us time, we can get something
> >>>>>>> released, and can innovate more later.
> >>>>>>>
> >>>>>>
> >>>>>> I think as you that we need a way to make the "presentation" of each
> >>>>>> component highly customizable.
> >>>>>> And we need to be different in visualization (art, colors, ...) but
> >>> not in
> >>>>>> usability that is what people
> >>>>>> needs to be consistently
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Maybe a good question for our users is: How many of you used the
> >>>>>>> default
> >>>>>>> Flex skins vs a whole new set of skins? If most folks completely
> >>>>>>> re-skinned to match their corporate branding, it matters less what
> >> our
> >>>>>>> default is, and more that we can allow folks to customize every
> >> pixel.
> >>>>>>>
> >>>>>>>
> >>>>>> We need both: a skin that will be highly customizable and to change
> >>> skins
> >>>>>> to look very very different.
> >>>>>> People with lees money or time in their Apps will choose the first.
> >>> People
> >>>>>> that has more resources will go with the second.
> >>>>>> Apache Royale needs to support both
> >>>>>>
> >>>>>>
> >>>>>>> The wireframe can be black and white, IMO. I was thinking that
> >>> "vivid"
> >>>>>>> would have parameterized colors.
> >>>>>>>
> >>>>>>>
> >>>>>> I started to think that wireframe could end having lots of
> >>> customization
> >>>>>> controls. For example:
> >>>>>>
> >>>>>> -2-3 main colors as we talked , and the same MDL does
> >>>>>> -possibilitiy to be solid colors, or gradients
> >>>>>> -possibility to have backgrounds more or less opaque
> >>>>>>
> >>>>>> if we see a concrete component like button:
> >>>>>>
> >>>>>> - configurable corners, square to round corners
> >>>>>> - more blocky (relief) or more flat
> >>>>>> ...
> >>>>>>
> >>>>>> So wireframe could be a concrete configuration of the main theme
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Since Bootstrap was mentioned, I want to point out that the
> Flat.swc
> >>> is
> >>>>>>> a
> >>>>>>> rough approximation of the Flat theme which is a Bootstrap theme.
> >> It
> >>>>>>> is a
> >>>>>>> rough approximation because I could not use the Flat CSS file
> >> directly
> >>>>>>> since it contains much more advanced CSS than we currently support
> >> on
> >>>>>>> the
> >>>>>>> SWF side. But it presumed that the Checkbox was a Label with a
> Span
> >>>>>>> that
> >>>>>>> hides in front of or behind the <input type="check" /> in order to
> >>> allow
> >>>>>>> customizing every pixel. Looks like MDL uses the same Span trick
> >> but
> >>>>>>> maybe without a symbol font.
> >>>>>>>
> >>>>>>> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
> >>>>>>> should
> >>>>>>> not have that extra Span. But it looks to me that a
> >> SkinnableCheckbox
> >>>>>>> can
> >>>>>>> add that extra Span and you either give it the same class name that
> >>>>>>> BootStrap or MDL uses or create our own set of classnames and the
> >> CSS
> >>>>>>> that
> >>>>>>> goes with it.
> >>>>>>>
> >>>>>>>
> >>>>>> The problem with Basic could be that if is very very basic and looks
> >>> with
> >>>>>> a
> >>>>>> very basic look (as it is very poorly stylizable), I think
> >>>>>> People will not use it at all, in this case, I'll don't understand
> >> the
> >>>>>> goal
> >>>>>> with basic. It's intend ended as a base
> >>>>>> but to not use in production? For this reason is what I want to know
> >> if
> >>>>>> you
> >>>>>> think this theme feature could be plugged in basic or not.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Of course, I could be wrong. This is not my area of expertise at
> >> all.
> >>>>>>>
> >>>>>>
> >>>>>> Hi Alex, maybe UX is not your expertise area, but your help here is
> >>> very
> >>>>>> needed since we can get to great ideas in this field, but
> >>>>>> maybe don't know how to bring it to implementation in Apache Royale.
> >> I
> >>>>>> think that you, Peter, Harbs,... are needed in order to
> >>>>>> make this happen in the pure arquitecture side or this feature.
> >>>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>>> -Alex
> >>>>>>>
> >>>>>>>
> >>>>>>> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
> >>>>>>> Rovira"
> >>>>>>> <carlos.rovira@gmail.com on behalf of
> carlos.rovira@codeoscopic.com
> >>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi Alex,
> >>>>>>>>
> >>>>>>>> 2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >>>>>>>>
> >>>>>>>>> Hi Carlos,
> >>>>>>>>>
> >>>>>>>>> Looks good to me. Thanks for doing this.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks :)
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I'm not sure I understand all of the aspects of this effort. My
> >>>>>>> current
> >>>>>>>>> understanding is that Google Material is under the Apache License
> >>> and
> >>>>>>>>> thus
> >>>>>>>>> we can use it if we want to. Am I correct that
> MaterialDesignLite
> >>> is
> >>>>>>>>> one
> >>>>>>>>> implementation of Google Material and we could create our own
> >>>>>>>>> implementation and it could be visually different?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> We can implement our own material in Royale, but I'm afraid that
> >>> doing
> >>>>>>>> that
> >>>>>>>> will not make us
> >>>>>>>> highlight our solution against the rest of competitors. Another
> >> point
> >>>>>>> is
> >>>>>>>> something I said various times:
> >>>>>>>> When I did MDL, I notice a huge problem: MDL has its own set of
> >>>>>>>> components,
> >>>>>>>> some are in all sets (Button)
> >>>>>>>> but others not (Card), and they has it's own implementation, what
> >>> make
> >>>>>>> it
> >>>>>>>> almost impossible generalize
> >>>>>>>> a theme. For this reason I always point that we need our own set
> >> and
> >>>>>>> there
> >>>>>>>> we can implement themes. But other
> >>>>>>>> *externa* sets will never get this since they have its own
> >>>>>>> implementation
> >>>>>>>> and most important once you start to develop
> >>>>>>>> with MDL you can't go back and change for other. So MDL is for me
> >>>>>>>> something
> >>>>>>>> we have until our own set are robust and
> >>>>>>>> highly configurable in both the things we can do and how can it
> >> could
> >>>>>>> be
> >>>>>>>> represented, and switch between style should be
> >>>>>>>> really easy to change the global look of an App without much
> >> hassle.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Also, IIRC, Material has different components than Flex did so
> >> we'd
> >>>>>>> have
> >>>>>>>>> to invent some new looks anyway. So having a TextInput with
> >> borders
> >>>>>>> all
> >>>>>>>>> around would just be our flavor of Material.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> That's what I point above. We must to *freeze* the list of
> >> components
> >>>>>>> at
> >>>>>>>> some time work over a concrete set
> >>>>>>>> We can then plan in the future include a new component in the
> >>> official
> >>>>>>>> set,
> >>>>>>>> and that will need to work on the themes we already
> >>>>>>>> have to include the new one.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Regarding colors, it looks like Material is parameterized around
> a
> >>>>>>>>> couple
> >>>>>>>>> of colors. So if we did our skins to work against parameterized
> >>>>>>> colors
> >>>>>>>>> then would it really matter what color we choose?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> That's completly right. I could make wireframe based on two or
> >> three
> >>>>>>>> colors
> >>>>>>>> and as you change it in CSS all controls should tint
> >>>>>>>> consistently.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Regarding Basic components, right now Checkbox is a <label><input
> >>>>>>>>> type="check"/>caption</label>. AIUI, you cannot style the
> <input>
> >>> on
> >>>>>>>>> many
> >>>>>>>>> browsers, so I think we have to have a different set of elements
> >> in
> >>> a
> >>>>>>>>> checkbox. It looks like Bootstrap uses:
> >>>>>>>>>
> >>>>>>>>> <label><input type="check"/><span />Caption</label>
> >>>>>>>>>
> >>>>>>>>> Where the span uses a special symbol font with checked and
> >> unchecked
> >>>>>>>>> boxes.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> That's what we need to figure. Should we make themes available in
> >>>>>>> Basic?
> >>>>>>>> if
> >>>>>>>> so, has basic the right implementation?
> >>>>>>>> If not, and if we don't want to change the actual very basic
> >>>>>>>> implementation, we need to put some "skin" implementation
> >>>>>>>> that at least in JS implementation I figure that will change one
> >> face
> >>>>>>> (the
> >>>>>>>> actual basic) with the theme face.
> >>>>>>>>
> >>>>>>>> I'm thinking loud, since this is something we should explorer all
> >>>>>>> together
> >>>>>>>> mixing the best ideas of people involved
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Alex
> >>>>>>>>>
> >>>>>>>>> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of
> Carlos
> >>>>>>>>> Rovira"
> >>>>>>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> I want to expose my initial work (very very initial) on two
> >> styles
> >>>>>>> for
> >>>>>>>>>> Royale
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Wireframe:
> >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> https%3A%2F%2Fsnag.gy%2
> >>>>>>>>>> FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7Cfa7b1b5a7
> >>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>>>>> sdata=%2Fk8YQxC5bDOaC
> >>>>>>>>>> D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>> (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://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> https%3A%2F%2Fsnag.gy%2
> >>>>>>>>>> FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7Cfa7b1b5a7
> >>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>>>>> sdata=kxYE7ylOsXPUEeE
> >>>>>>>>>> r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>> (*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 <
> >> carlosrovira@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 <ha...@gmail.com>:
> >>>>>>>>>>>
> >>>>>>>>>>>> BTW, the kind of thing we should be striving for in theme-able
> >>>>>>>>>>>> components
> >>>>>>>>>>>> is something like this:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> https%3A%2F%2Fvcalend
> >>>>>>>>>>>> ar.netlify.com%2F&data=02%7C01%7C%
> >> 7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7Cf
> >>>>>>>>>
> >>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>> 7C636452649612378558&sdata=
> >>>>>>>>> b3VtV
> >>>>>>>>>>>> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
> >>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> https%3A%2F%2Fvcalen
> >>>>>>>>>>>> dar.netlify.com%2F&data=02%7C01%7C%
> >>> 7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7C
> >>>>>>>>>
> >>>>>>>>>> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>> 7C636452649612378558&sdata=
> >>>>>>>>> b3Vt
> >>>>>>>>>>>> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> https%3A%2F%2Fpaste.a
> >>>>>>>>>>>> pache.org%2FcOBC&data=02%7C01%7C%
> >> 7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7Cfa
> >>>>>>>>>>>> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>>>>> sdata=bRWKxm
> >>>>>>>>>>>> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
> >>>>>>>>>
> >>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>> https%3A%2F%2Fpast
> >>>>>>>>>>>> e
> >>>>>>>>> .
> >>>>>>>>>>>> apache.org%2FcOBC&data=02%7C01%7C%
> >> 7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7Cf
> >>>>>>>>>
> >>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>> 7C636452649612378558&sdata=
> >>>>>>>>> bRWKx
> >>>>>>>>>>>> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> (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
> >>>>>>>>> <carlosrovira@apache.org
> >>>>>>>>>>>> <ma...@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.lists@gmail.com
> >>>>>>> <mailto:
> >>>>>>>>>>>> harbs.lists@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
> >>>>>>>>> <aharui@adobe.com.INVALID
> >>>>>>>>>>>> <ma...@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
> >>>>>>>>>>>
> >>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> http%3A%2F%2Fabout.me%
> >>>>>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7Cfa7b1
> >>>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>>>>> sdata=C7a72gwfH2
> >>>>>>>>>>> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Carlos Rovira
> >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> http%3A%2F%2Fabout.me%2
> >>>>>>>>>> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7Cfa7b1b5
> >>>>>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>>>>> sdata=C7a72gwfH264w
> >>>>>>>>>> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>>
> >>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>> http%3A%2F%2Fwww.codeo
> >>>>>>>> scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
> >>>>>>> d8cf%7Cfa7b1b5a7b
> >>>>>>>> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> >>>>>>> sdata=Hm%2B6WIcqQTOHs0
> >>>>>>>> UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> >>>>>>> d8cf%7Cfa7b1b5a7b3
> >>>>>>>> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> >>>>>>> sdata=Hm%2B6WIcqQTOHs0U
> >>>>>>>> ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> >>>>>>> d8cf%7Cfa7b1b5a
> >>>>>>>> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> >>>>>>> sdata=b%2FFMr1Ajit94
> >>>>>>>> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Carlos Rovira
> >>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>> http%3A%2F%2Fabout.me%2
> >>>>>> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
> >>>>> 82e0%7Cfa7b1b5
> >>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
> >>>>> sdata=wYPMWW1wpTbtm
> >>>>>> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> <http://www.codeoscopic.com>
> >>>>
> >>>> Carlos Rovira
> >>>>
> >>>> Director General
> >>>>
> >>>> M: +34 607 22 60 05
> >>>>
> >>>> http://www.codeoscopic.com
> >>>>
> >>>>
> >>>> Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
> >>>>
> >>>>
> >>>> 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.
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon: *https://www.patreon.com/piotrzarzycki
> >> <https://www.patreon.com/piotrzarzycki>*
> >>
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
RE: Working on UI Controls styling
Posted by Idylog - Nicolas Granon <ng...@idylog.com>.
Are we talking about styling, theming or skinning ?
As application developers, we are mainly interested in "styling", based on an available theme.
Usually, it is a minor task. Most of the apps follow the chosen theme and styles affect mostly font size/weight, borders width/color, alphas ...
We never "create" a full skin, unless we create a very specific component (complete with all visual aspects). That is not our usual business.
Our customers expect "visual elements" (components, controls...) to have a very standardized look.
It could happen that we need to change a theme, for example if the customer is a big company and want the general color scheme/font to be close to the company standards.
But usually, we stick to a basic, neutral theme.
Nicolas Granon
> -----Message d'origine-----
> De : Peter Ent [mailto:pent@adobe.com.INVALID]
> Envoyé : mardi 7 novembre 2017 12:40
> À : dev@royale.apache.org
> Objet : Re: Working on UI Controls styling
>
> A couple of questions:
>
> How expensive is generating and applying CSS on the client?
>
> How do developers that use CSS regularly feel about having to declare
> that many styles for all the buttons? Maybe tools like Dreamweaver make
> it simpler and we just need IDEs that could provide assistance.
>
> Peter
>
>
> On Nov 7, 2017, at 6:24 AM, Harbs
> <ha...@gmail.com>> wrote:
>
> Some food for thought:
>
> I created a custom component for “buttons” which allow simple skinning
> using image files. It works like this:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.
> apache.org%2Ftc8f&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7C
> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=tko
> afaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%3D&reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste
> .apache.org%2Ftc8f&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7
> Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=tk
> oafaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%3D&reserved=0>
>
> Specifying different states can be done using the following css:
> .bug
> {
> background-image: url ('assets/up/report-bug.png'); } .bug:hover{
> background-image: url ('assets/over/report-bug.png'); } .bug:active{
> background-image: url ('assets/down/report-bug.png'); }
> .bug:disabled{
> background-image: url ('assets/disabled/report-bug.png');
> }
>
> It works well, but the problem with this approach is that it requires
> multiple css entries for every button.
>
> Using it is done like this:
> <comp:PanelButton id="bugButton"
> enabled="{bugReportEnabled}" width="72" height="82"
> x="19" y="283"
> click="reportBug()" className="bug"/>
>
> I wanted to allow the following:
>
> <comp:PanelButton id="bugButton"
> enabled="{bugReportEnabled}" width="72" height="82"
> x="19" y="283"
> click="reportBug()" className="bug"
> image="assets/up/report-bug.png"
> hoverImage="assets/over/report-bug.png"
> activeImage="assets/down/report-bug.png"
> disabledImage="assets/disabled/report-bug.png"/>
>
> However, this is harder than you’d expect in HTML. Apparently there’s
> no way to set pseudo-styles using inline css.[1][2].
>
> There are a couple of interesting work-arounds. One is using mouse
> events.[3] Another is by creating CSS on the fly.[4] The answer assumes
> that the css is created on the server, but using the ideas I proposed
> in the ThemeManager class, that can be done on the client dynamically.
>
> The challenge with the last approach would be in guaranteeing the css
> is unique to the images (or individual component). One option on that
> front would be to generate UIDs when the component is instantiated. A
> consideration is garbage-collecting CSS selectors when components might
> be removed.
>
> I hope these ideas are helpful.
>
> Harbs
>
> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsta
> ckoverflow.com%2Fquestions%2F5293280%2Fcss-pseudo-classes-with-inline-
> styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3
> 4438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=krVr8HQkvOU3nq
> ALzR4Hs5mzQbbB9m3v5uWgBzRkPII%3D&reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstack
> overflow.com%2Fquestions%2F5293280%2Fcss-pseudo-classes-with-inline-
> styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3
> 4438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=krVr8HQkvOU3nq
> ALzR4Hs5mzQbbB9m3v5uWgBzRkPII%3D&reserved=0>
> [2]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsta
> ckoverflow.com%2Fquestions%2F986618%2Fis-it-possible-to-create-inline-
> pseudo-
> styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3
> 4438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=k3ItgYlMsw0VaX
> W6VYAlmnV8UFy8ZucwIIH77ji%2FQHQ%3D&reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstack
> overflow.com%2Fquestions%2F986618%2Fis-it-possible-to-create-inline-
> pseudo-
> styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3
> 4438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=k3ItgYlMsw0VaX
> W6VYAlmnV8UFy8ZucwIIH77ji%2FQHQ%3D&reserved=0>
> [3]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsta
> ckoverflow.com%2Fa%2F5293426%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f
> 27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364565
> 06748081243&sdata=y%2FokgjdUZq87z%2FZYiGD10OMz0xe%2BkcQ9U2EyPn2umEM%3D&
> reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstack
> overflow.com%2Fa%2F5293426%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27
> c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506
> 748081243&sdata=y%2FokgjdUZq87z%2FZYiGD10OMz0xe%2BkcQ9U2EyPn2umEM%3D&re
> served=0>
> [4]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsta
> ckoverflow.com%2Fa%2F39712777%2F5475183&data=02%7C01%7C%7C24fb66825ebf4
> f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456
> 506748081243&sdata=sZUQLlcFJDWwhXZYwCoI68%2BLIxNhJMFg7q0%2FzIEpEBI%3D&r
> eserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstack
> overflow.com%2Fa%2F39712777%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f2
> 7c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63645650
> 6748081243&sdata=sZUQLlcFJDWwhXZYwCoI68%2BLIxNhJMFg7q0%2FzIEpEBI%3D&res
> erved=0>
>
> On Nov 6, 2017, at 8:22 PM, Carlos Rovira
> <ca...@apache.org>> wrote:
>
> Hi Harbs,
>
> If we go with Basic as seems everybody suggest, I think we should not
> mix with Express. We can "copy" some Express knowledge, but not make it
> dependent, to avoid having a Frankenstein Basic is the core, and from
> there we have Express and the new stylizable set
>
> 2017-11-05 22:01 GMT+01:00 Piotr Zarzycki
> <pi...@gmail.com>>:
>
> I was thinking about that and new component set is the approach which
> we should try, but we need to base on something. My first thoughts was
> that it should be Basic, cause I bet that once we start create style
> for each component we will end up with some issue or we would like to
> create some additional features to those controls in order to make that
> theme happen.
> It leads my thought then farther let's say that we will start work in
> following way:
> 1) Basic is our base
> 2) Carlos will prepare some appearance for component
> 3) We are starting to work on that, but it's end up that our component
> need some additional feature, which is do not suits for Basic
> 4) We are adds that feature to Express and use in that place Express
> component.
>
> It ends up that our component theme will be mix of Express and Basic
>
> Second approach is - Forget about Express, use Basic only and add to
> Theme set features if needed. Express will be always separate set, FAT
> and it will be responsibility for user if he would like to style it. -
> If our implementation will be in Theme enough robust, user should be
> able to use in his application Express with some styles from Theme set.
>
> Thoughts ?
> Piotr
>
>
> 2017-11-05 11:21 GMT+01:00 Harbs
> <ha...@gmail.com>>:
>
> I would suggest starting a new component set with a fresh slate called
> Themed (or something like that).
>
> The Themed component set should give priority to style-ablitity and
> ease of use over just about every other consideration. I think of
> Express as more of a middle-of the road approach to make things easier.
> A Themed set would be more of a replacement for mx and spark.
>
> Yes. Definitely make a clear list of supported components. It’s
> probably more important to have quality of components rather than
> quantity. A few well constructed components is better than a lot of
> half-baked ones. More components could always be added.
>
> I’m very glad to hear that Angelo is working with you. That’s great
> news!
>
> Harbs
>
> On Nov 5, 2017, at 12:12 PM, Carlos Rovira <
> carlos.rovira@codeoscopic.com<ma...@codeoscopic.com>>
> wrote:
>
> ok Alex,
>
> so if I understand correctly, you mean that we create our own set, with
> Basic as base right?
> but we should go with Express? It's great that we could create many
> sets in Royale, and I think the Basic use you commented is very licit
> and didn't think about that. But we must think in some *main* set,
> maybe is Express and that I want to focus this effort for that concrete
> set.
>
> I mean, one important thing here is that we all agree in support a
> concrete list of UI controls and components I plan to make a discuss
> thread for this, since the theme feature will affect only to that
> controls, and if we want to include a new one we should vote to include
> it, since it implies to include in design, implementation and all
> themes that we want to support.
>
> I think I'll create a discuss thread with this an other things we
> talked about since this is a huge effort and is important for all the
> people that will be involved to work around things discussed, voted and
> approved by all.
> We need to be synced here or we'll end working too much for somehitng
> that does not get to be useful in the end. I want to ensure this before
> to start investing a huge amount of time.
>
> As well I was contacted by Angelo and talk about all this. He's very
> passionate as well on this and we'll seeing how we can combine our
> efforts and if someone more wants to join us.
>
> I'll be writing the discussion thread in order to plan the effort in
> short.
> Stay tuned :)
>
> 2017-11-05 8:29 GMT+01:00 Alex Harui
> <ah...@adobe.com.invalid>>:
>
> Hi Carlos,
>
> I think we're pretty much in agreement. Regarding Basic, for me, I
> have created plenty of web pages with non-styleable checkboxes. I
> don't care that the checkbox looks different on different browsers. I
> just want the smallest simplest output. Just like taking an HTML
> editor and slapping in a few tags and calling it done. Would that be
> production? Sure, if I'm just want someone to check a box before
> enabling a download button.
> IOW,
> it would be for internal customers only.
>
> So, IMO, a Skinnable/Themeable component set would be something else.
> I think you will need that extra Span for a Checkbox. IMO, we should
> just go and build these new components. And when we get it mostly
> working, we can compare against Basic and see if we want to
> parameterize the views in the low-level Basic components or not.
>
> My 2 cents,
> -Alex
>
> On 11/4/17, 8:19 AM,
> "carlos.rovira@gmail.com<ma...@gmail.com> on behalf of
> Carlos Rovira"
> <ca...@gmail.com> on behalf of
> carlosrovira@apache.org<ma...@apache.org>> wrote:
>
> HI Alex,
>
>
> 2017-11-03 17:52 GMT+01:00 Alex Harui
> <ah...@adobe.com.invalid>>:
>
> Hi Carlos,
>
> I skimmed through
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fmaterial
> .io%2Fguidelines%2F%23&data=02%7C01%7C%
> 7Cbb03216ec0b84fcb6ab108d52397
> 82e0
> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636454056000808812&sdata=g5
> M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last night.
>
> My impression is that there were two parts to it. First was the
> environment/principles section which talked about physical objects and
> light (and motion), and then there were choices of widgets. For
> example, I didn't see anything in the first part that said that a text
> input had to be a single line and couldn't be a box.
>
>
> Material guidelines could be a great way to start, but trying to give
> something different.
> I think that we need to get something that looks great while be clearly
> different to google material, bootstrap, and others so people could see
> us as an alternative. That could make people copying us or adopting the
> whole Apache Royale SDK that is what we want in the end
>
>
>
>
> That made me think that we could use our widget set and apply Material
> environment and principles to it. If we decide not to, I would think
> you would want to have some sort of similar environment/principles
> document which seems like a fair amount of work. I think we'd end up
> looking different because we have different widgets and maybe some
> different colors. I'm pretty sure that we don't want to be different
> so much that we don't create things that folks want to use. The
> priority to me is just to prove that you can alter every pixel in every
> widget we have so that others can provide custom skins as well. So
> starting with Material principles seems like it would save us time, we
> can get something released, and can innovate more later.
>
>
> I think as you that we need a way to make the "presentation" of each
> component highly customizable.
> And we need to be different in visualization (art, colors, ...) but not
> in usability that is what people needs to be consistently
>
>
>
>
> Maybe a good question for our users is: How many of you used the
> default Flex skins vs a whole new set of skins? If most folks
> completely re-skinned to match their corporate branding, it matters
> less what our default is, and more that we can allow folks to customize
> every pixel.
>
>
> We need both: a skin that will be highly customizable and to change
> skins to look very very different.
> People with lees money or time in their Apps will choose the first.
> People
> that has more resources will go with the second.
> Apache Royale needs to support both
>
>
> The wireframe can be black and white, IMO. I was thinking that "vivid"
> would have parameterized colors.
>
>
> I started to think that wireframe could end having lots of
> customization controls. For example:
>
> -2-3 main colors as we talked , and the same MDL does -possibilitiy to
> be solid colors, or gradients -possibility to have backgrounds more or
> less opaque
>
> if we see a concrete component like button:
>
> - configurable corners, square to round corners
> - more blocky (relief) or more flat
> ...
>
> So wireframe could be a concrete configuration of the main theme
>
>
>
> Since Bootstrap was mentioned, I want to point out that the Flat.swc is
> a rough approximation of the Flat theme which is a Bootstrap theme.
> It
> is a
> rough approximation because I could not use the Flat CSS file directly
> since it contains much more advanced CSS than we currently support on
> the SWF side. But it presumed that the Checkbox was a Label with a
> Span that hides in front of or behind the <input type="check" /> in
> order to allow customizing every pixel. Looks like MDL uses the same
> Span trick but maybe without a symbol font.
>
> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
> should not have that extra Span. But it looks to me that a
> SkinnableCheckbox can add that extra Span and you either give it the
> same class name that BootStrap or MDL uses or create our own set of
> classnames and the CSS that goes with it.
>
>
> The problem with Basic could be that if is very very basic and looks
> with a very basic look (as it is very poorly stylizable), I think
> People will not use it at all, in this case, I'll don't understand the
> goal with basic. It's intend ended as a base but to not use in
> production? For this reason is what I want to know if you think this
> theme feature could be plugged in basic or not.
>
>
>
>
> Of course, I could be wrong. This is not my area of expertise at all.
>
>
> Hi Alex, maybe UX is not your expertise area, but your help here is
> very needed since we can get to great ideas in this field, but maybe
> don't know how to bring it to implementation in Apache Royale.
> I
> think that you, Peter, Harbs,... are needed in order to make this
> happen in the pure arquitecture side or this feature.
>
> Thanks
>
> -Alex
>
>
> On 11/3/17, 1:35 AM,
> "carlos.rovira@gmail.com<ma...@gmail.com> on behalf of
> Carlos Rovira"
> <ca...@gmail.com> on behalf of
> carlos.rovira@codeoscopic.com<ma...@codeoscopic.com>
>
> wrote:
>
> Hi Alex,
>
> 2017-11-03 7:39 GMT+01:00 Alex Harui
> <ah...@adobe.com.invalid>>:
>
> Hi Carlos,
>
> Looks good to me. Thanks for doing this.
>
>
> Thanks :)
>
>
> I'm not sure I understand all of the aspects of this effort. My
> current understanding is that Google Material is under the Apache
> License and thus we can use it if we want to. Am I correct that
> MaterialDesignLite is one implementation of Google Material and we
> could create our own implementation and it could be visually different?
>
>
> We can implement our own material in Royale, but I'm afraid that doing
> that will not make us highlight our solution against the rest of
> competitors. Another point is something I said various times:
> When I did MDL, I notice a huge problem: MDL has its own set of
> components, some are in all sets (Button) but others not (Card), and
> they has it's own implementation, what make it almost impossible
> generalize a theme. For this reason I always point that we need our own
> set and there we can implement themes. But other
> *externa* sets will never get this since they have its own
> implementation and most important once you start to develop with MDL
> you can't go back and change for other. So MDL is for me something we
> have until our own set are robust and highly configurable in both the
> things we can do and how can it could be represented, and switch
> between style should be really easy to change the global look of an App
> without much hassle.
>
>
>
> Also, IIRC, Material has different components than Flex did so we'd
> have to invent some new looks anyway. So having a TextInput with
> borders all around would just be our flavor of Material.
>
>
> That's what I point above. We must to *freeze* the list of components
> at some time work over a concrete set We can then plan in the future
> include a new component in the official set, and that will need to work
> on the themes we already have to include the new one.
>
>
>
> Regarding colors, it looks like Material is parameterized around a
> couple of colors. So if we did our skins to work against parameterized
> colors then would it really matter what color we choose?
>
>
> That's completly right. I could make wireframe based on two or three
> colors and as you change it in CSS all controls should tint
> consistently.
>
>
>
> Regarding Basic components, right now Checkbox is a <label><input
> type="check"/>caption</label>. AIUI, you cannot style the <input> on
> many browsers, so I think we have to have a different set of elements
> in a checkbox. It looks like Bootstrap uses:
>
> <label><input type="check"/><span />Caption</label>
>
> Where the span uses a special symbol font with checked and unchecked
> boxes.
>
>
> That's what we need to figure. Should we make themes available in
> Basic?
> if
> so, has basic the right implementation?
> If not, and if we don't want to change the actual very basic
> implementation, we need to put some "skin" implementation that at least
> in JS implementation I figure that will change one face (the actual
> basic) with the theme face.
>
> I'm thinking loud, since this is something we should explorer all
> together mixing the best ideas of people involved
>
> Thanks
>
>
>
>
> Thanks,
> Alex
>
> On 11/2/17, 5:15 PM,
> "carlos.rovira@gmail.com<ma...@gmail.com> on behalf of
> Carlos Rovira"
> <ca...@gmail.com> on behalf of
> carlosrovira@apache.org<ma...@apache.org>>
> wrote:
>
> Hi,
>
> I want to expose my initial work (very very initial) on two styles for
> Royale
>
>
> Wireframe:
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fsnag.gy%2
> FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1b5a7
> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=%2Fk8YQxC5bDOaC
> D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
>
> (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://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fsnag.gy%2
> FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1b5a7
> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=kxYE7ylOsXPUEeE
> r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
>
> (*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 <
> carlosrovira@apache.org<ma...@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
> <ha...@gmail.com>>:
>
> BTW, the kind of thing we should be striving for in theme-able
> components is something like this:
>
>
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fvcalend
> ar.netlify.com<http://ar.netlify.com>%2F&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> 0f48%7Cf
>
> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636452649612378558&sdata=
> b3VtV
> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fvcalen
> dar.netlify.com<http://dar.netlify.com>%2F&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> 0f48%7C
>
> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636452649612378558&sdata=
> b3Vt
> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
>
> On Nov 2, 2017, at 12:01 PM, Harbs
> <ha...@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://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.a
> pache.org<http://pache.org>%2FcOBC&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> 0f48%7Cfa
> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=bRWKxm
> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
>
> <https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpast
> e
> .
> apache.org<http://apache.org>%2FcOBC&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> 0f48%7Cf
>
> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636452649612378558&sdata=
> bRWKx
> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
>
> (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
> <ca...@apache.org>
> <ma...@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
> <ha...@gmail.com>
> <mailto:
> harbs.lists@gmail.com<ma...@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
> <ah...@adobe.com.INVALID>
> <ma...@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
>
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me<http://2Fabout.me>%
> 2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1
> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=C7a72gwfH2
> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>
>
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me<http://2Fabout.me>%2
> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1b5
> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=C7a72gwfH264w
> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>
>
>
>
> --
>
> <https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.codeo
> scopic.com<http://scopic.com>&data=02%7C01%7C%7C6422929d95d1406eaa1c08d
> 52295
> d8cf%7Cfa7b1b5a7b
> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> sdata=Hm%2B6WIcqQTOHs0
> UppUdckW%2FhhyzErprotQUOZNtUtXU%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<http://copic.com>&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52
> 295
> d8cf%7Cfa7b1b5a7b3
> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> sdata=Hm%2B6WIcqQTOHs0U
> ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> d8cf%7Cfa7b1b5a
> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> sdata=b%2FFMr1Ajit94
> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
>
>
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me<http://2Fabout.me>%2
> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
> 82e0%7Cfa7b1b5
> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
> sdata=wYPMWW1wpTbtm
> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
>
>
>
>
> --
>
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.co
> deoscopic.com&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b
> 1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=7oFpGJ9
> 5n%2FJh07KhDfmRnzFO7hyFwdlFZkz49OGjFq8%3D&reserved=0>
>
> Carlos Rovira
>
> Director General
>
> M: +34 607 22 60 05
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cod
> eoscopic.com&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1
> b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=7oFpGJ95
> n%2FJh07KhDfmRnzFO7hyFwdlFZkz49OGjFq8%3D&reserved=0
>
>
> Conocenos Avant2 en 1 minuto!
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant
> 2.es%2F%23video&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa
> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=Df4JB
> WaWmTrEZYwvr1NTQBLOInEPtyF92ACWbYi4%2FL4%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.
>
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon:
> *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.p
> atreon.com%2Fpiotrzarzycki&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525
> d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&
> sdata=sUBa9rnF1xMg4Pr1R6bGxzUl7m7qiGIaDrL%2FQKkeOtY%3D&reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.p
> atreon.com%2Fpiotrzarzycki&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525
> d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&
> sdata=sUBa9rnF1xMg4Pr1R6bGxzUl7m7qiGIaDrL%2FQKkeOtY%3D&reserved=0>*
>
>
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.m
> e%2Fcarlosrovira&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cf
> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=KwVv
> Fzo8w1oV00kHzCxI3Wyn0UlqIfyFWnazDdPpwrk%3D&reserved=0
Re: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
AFAIK, generating should not be any slower than any other DOM node. Here’s some data on applying CSS (although I’m not sure how useful the info actually is):
https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/ <https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/>
How developers in general feel about it? No idea. But I find CSS files difficult to deal with.
> On Nov 7, 2017, at 1:39 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
>
> A couple of questions:
>
> How expensive is generating and applying CSS on the client?
>
> How do developers that use CSS regularly feel about having to declare that many styles for all the buttons? Maybe tools like Dreamweaver make it simpler and we just need IDEs that could provide assistance.
>
> Peter
>
>
> On Nov 7, 2017, at 6:24 AM, Harbs <ha...@gmail.com>> wrote:
>
> Some food for thought:
>
> I created a custom component for “buttons” which allow simple skinning using image files. It works like this:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Ftc8f&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=tkoafaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Ftc8f&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=tkoafaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%3D&reserved=0>
>
> Specifying different states can be done using the following css:
> .bug
> {
> background-image: url ('assets/up/report-bug.png');
> }
> .bug:hover{
> background-image: url ('assets/over/report-bug.png');
> }
> .bug:active{
> background-image: url ('assets/down/report-bug.png');
> }
> .bug:disabled{
> background-image: url ('assets/disabled/report-bug.png');
> }
>
> It works well, but the problem with this approach is that it requires multiple css entries for every button.
>
> Using it is done like this:
> <comp:PanelButton id="bugButton"
> enabled="{bugReportEnabled}" width="72" height="82"
> x="19" y="283"
> click="reportBug()" className="bug"/>
>
> I wanted to allow the following:
>
> <comp:PanelButton id="bugButton"
> enabled="{bugReportEnabled}" width="72" height="82"
> x="19" y="283"
> click="reportBug()" className="bug"
> image="assets/up/report-bug.png"
> hoverImage="assets/over/report-bug.png"
> activeImage="assets/down/report-bug.png"
> disabledImage="assets/disabled/report-bug.png"/>
>
> However, this is harder than you’d expect in HTML. Apparently there’s no way to set pseudo-styles using inline css.[1][2].
>
> There are a couple of interesting work-arounds. One is using mouse events.[3]
> Another is by creating CSS on the fly.[4] The answer assumes that the css is created on the server, but using the ideas I proposed in the ThemeManager class, that can be done on the client dynamically.
>
> The challenge with the last approach would be in guaranteeing the css is unique to the images (or individual component). One option on that front would be to generate UIDs when the component is instantiated. A consideration is garbage-collecting CSS selectors when components might be removed.
>
> I hope these ideas are helpful.
>
> Harbs
>
> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F5293280%2Fcss-pseudo-classes-with-inline-styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=krVr8HQkvOU3nqALzR4Hs5mzQbbB9m3v5uWgBzRkPII%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F5293280%2Fcss-pseudo-classes-with-inline-styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=krVr8HQkvOU3nqALzR4Hs5mzQbbB9m3v5uWgBzRkPII%3D&reserved=0>
> [2]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F986618%2Fis-it-possible-to-create-inline-pseudo-styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=k3ItgYlMsw0VaXW6VYAlmnV8UFy8ZucwIIH77ji%2FQHQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F986618%2Fis-it-possible-to-create-inline-pseudo-styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=k3ItgYlMsw0VaXW6VYAlmnV8UFy8ZucwIIH77ji%2FQHQ%3D&reserved=0>
> [3]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F5293426%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=y%2FokgjdUZq87z%2FZYiGD10OMz0xe%2BkcQ9U2EyPn2umEM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F5293426%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=y%2FokgjdUZq87z%2FZYiGD10OMz0xe%2BkcQ9U2EyPn2umEM%3D&reserved=0>
> [4]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F39712777%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=sZUQLlcFJDWwhXZYwCoI68%2BLIxNhJMFg7q0%2FzIEpEBI%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F39712777%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=sZUQLlcFJDWwhXZYwCoI68%2BLIxNhJMFg7q0%2FzIEpEBI%3D&reserved=0>
>
> On Nov 6, 2017, at 8:22 PM, Carlos Rovira <ca...@apache.org>> wrote:
>
> Hi Harbs,
>
> If we go with Basic as seems everybody suggest, I think we should not mix
> with Express. We can "copy" some Express knowledge, but not make it
> dependent, to avoid having a Frankenstein
> Basic is the core, and from there we have Express and the new stylizable set
>
> 2017-11-05 22:01 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>>:
>
> I was thinking about that and new component set is the approach which we
> should try, but we need to base on something. My first thoughts was that it
> should be Basic, cause I bet that once we start create style for each
> component we will end up with some issue or we would like to create some
> additional features to those controls in order to make that theme happen.
> It leads my thought then farther let's say that we will start work in
> following way:
> 1) Basic is our base
> 2) Carlos will prepare some appearance for component
> 3) We are starting to work on that, but it's end up that our component need
> some additional feature, which is do not suits for Basic
> 4) We are adds that feature to Express and use in that place Express
> component.
>
> It ends up that our component theme will be mix of Express and Basic
>
> Second approach is - Forget about Express, use Basic only and add to Theme
> set features if needed. Express will be always separate set, FAT and it
> will be responsibility for user if he would like to style it. - If our
> implementation will be in Theme enough robust, user should be able to use
> in his application Express with some styles from Theme set.
>
> Thoughts ?
> Piotr
>
>
> 2017-11-05 11:21 GMT+01:00 Harbs <ha...@gmail.com>>:
>
> I would suggest starting a new component set with a fresh slate called
> Themed (or something like that).
>
> The Themed component set should give priority to style-ablitity and ease
> of use over just about every other consideration. I think of Express as
> more of a middle-of the road approach to make things easier. A Themed set
> would be more of a replacement for mx and spark.
>
> Yes. Definitely make a clear list of supported components. It’s probably
> more important to have quality of components rather than quantity. A few
> well constructed components is better than a lot of half-baked ones. More
> components could always be added.
>
> I’m very glad to hear that Angelo is working with you. That’s great news!
>
> Harbs
>
> On Nov 5, 2017, at 12:12 PM, Carlos Rovira <
> carlos.rovira@codeoscopic.com<ma...@codeoscopic.com>> wrote:
>
> ok Alex,
>
> so if I understand correctly, you mean that we create our own set, with
> Basic as base right?
> but we should go with Express? It's great that we could create many
> sets
> in
> Royale, and I think the Basic use
> you commented is very licit and didn't think about that. But we must
> think
> in some *main* set, maybe is Express
> and that I want to focus this effort for that concrete set.
>
> I mean, one important thing here is that we all agree in support a
> concrete
> list of UI controls and components
> I plan to make a discuss thread for this, since the theme feature will
> affect only to that controls, and if we want to include a new one
> we should vote to include it, since it implies to include in design,
> implementation and all themes that we want to support.
>
> I think I'll create a discuss thread with this an other things we
> talked
> about since this is a huge effort and is important for all the
> people that will be involved to work around things discussed, voted and
> approved by all.
> We need to be synced here or we'll end working too much for somehitng
> that
> does not get to be useful in the end. I want to ensure this before
> to start investing a huge amount of time.
>
> As well I was contacted by Angelo and talk about all this. He's very
> passionate as well on this and we'll seeing how we can combine our
> efforts
> and if someone
> more wants to join us.
>
> I'll be writing the discussion thread in order to plan the effort in
> short.
> Stay tuned :)
>
> 2017-11-05 8:29 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>>:
>
> Hi Carlos,
>
> I think we're pretty much in agreement. Regarding Basic, for me, I
> have
> created plenty of web pages with non-styleable checkboxes. I don't
> care
> that the checkbox looks different on different browsers. I just want
> the
> smallest simplest output. Just like taking an HTML editor and
> slapping
> in
> a few tags and calling it done. Would that be production? Sure, if
> I'm
> just want someone to check a box before enabling a download button.
> IOW,
> it would be for internal customers only.
>
> So, IMO, a Skinnable/Themeable component set would be something
> else. I
> think you will need that extra Span for a Checkbox. IMO, we should
> just
> go and build these new components. And when we get it mostly working,
> we
> can compare against Basic and see if we want to parameterize the views
> in
> the low-level Basic components or not.
>
> My 2 cents,
> -Alex
>
> On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com<ma...@gmail.com> on behalf of Carlos
> Rovira"
> <ca...@gmail.com> on behalf of carlosrovira@apache.org<ma...@apache.org>> wrote:
>
> HI Alex,
>
>
> 2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>>:
>
> Hi Carlos,
>
> I skimmed through
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fmaterial
> .io%2Fguidelines%2F%23&data=02%7C01%7C%
> 7Cbb03216ec0b84fcb6ab108d52397
> 82e0
> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636454056000808812&sdata=g5
> M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last
> night.
>
> My impression is that there were two parts to it. First was the
> environment/principles section which talked about physical objects
> and
> light (and motion), and then there were choices of widgets. For
> example,
> I didn't see anything in the first part that said that a text input
> had
> to
> be a single line and couldn't be a box.
>
>
> Material guidelines could be a great way to start, but trying to give
> something different.
> I think that we need to get something that looks great while be
> clearly
> different to google material,
> bootstrap, and others so people could see us as an alternative. That
> could
> make people copying us
> or adopting the whole Apache Royale SDK that is what we want in the
> end
>
>
>
>
> That made me think that we could use our widget set and apply
> Material
> environment and principles to it. If we decide not to, I would
> think
> you
> would want to have some sort of similar environment/principles
> document
> which seems like a fair amount of work. I think we'd end up looking
> different because we have different widgets and maybe some different
> colors. I'm pretty sure that we don't want to be different so much
> that
> we don't create things that folks want to use. The priority to me
> is
> just
> to prove that you can alter every pixel in every widget we have so
> that
> others can provide custom skins as well. So starting with Material
> principles seems like it would save us time, we can get something
> released, and can innovate more later.
>
>
> I think as you that we need a way to make the "presentation" of each
> component highly customizable.
> And we need to be different in visualization (art, colors, ...) but
> not in
> usability that is what people
> needs to be consistently
>
>
>
>
> Maybe a good question for our users is: How many of you used the
> default
> Flex skins vs a whole new set of skins? If most folks completely
> re-skinned to match their corporate branding, it matters less what
> our
> default is, and more that we can allow folks to customize every
> pixel.
>
>
> We need both: a skin that will be highly customizable and to change
> skins
> to look very very different.
> People with lees money or time in their Apps will choose the first.
> People
> that has more resources will go with the second.
> Apache Royale needs to support both
>
>
> The wireframe can be black and white, IMO. I was thinking that
> "vivid"
> would have parameterized colors.
>
>
> I started to think that wireframe could end having lots of
> customization
> controls. For example:
>
> -2-3 main colors as we talked , and the same MDL does
> -possibilitiy to be solid colors, or gradients
> -possibility to have backgrounds more or less opaque
>
> if we see a concrete component like button:
>
> - configurable corners, square to round corners
> - more blocky (relief) or more flat
> ...
>
> So wireframe could be a concrete configuration of the main theme
>
>
>
> Since Bootstrap was mentioned, I want to point out that the Flat.swc
> is
> a
> rough approximation of the Flat theme which is a Bootstrap theme.
> It
> is a
> rough approximation because I could not use the Flat CSS file
> directly
> since it contains much more advanced CSS than we currently support
> on
> the
> SWF side. But it presumed that the Checkbox was a Label with a Span
> that
> hides in front of or behind the <input type="check" /> in order to
> allow
> customizing every pixel. Looks like MDL uses the same Span trick
> but
> maybe without a symbol font.
>
> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
> should
> not have that extra Span. But it looks to me that a
> SkinnableCheckbox
> can
> add that extra Span and you either give it the same class name that
> BootStrap or MDL uses or create our own set of classnames and the
> CSS
> that
> goes with it.
>
>
> The problem with Basic could be that if is very very basic and looks
> with
> a
> very basic look (as it is very poorly stylizable), I think
> People will not use it at all, in this case, I'll don't understand
> the
> goal
> with basic. It's intend ended as a base
> but to not use in production? For this reason is what I want to know
> if
> you
> think this theme feature could be plugged in basic or not.
>
>
>
>
> Of course, I could be wrong. This is not my area of expertise at
> all.
>
>
> Hi Alex, maybe UX is not your expertise area, but your help here is
> very
> needed since we can get to great ideas in this field, but
> maybe don't know how to bring it to implementation in Apache Royale.
> I
> think that you, Peter, Harbs,... are needed in order to
> make this happen in the pure arquitecture side or this feature.
>
> Thanks
>
> -Alex
>
>
> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com<ma...@gmail.com> on behalf of Carlos
> Rovira"
> <ca...@gmail.com> on behalf of carlos.rovira@codeoscopic.com<ma...@codeoscopic.com>
>
> wrote:
>
> Hi Alex,
>
> 2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>>:
>
> Hi Carlos,
>
> Looks good to me. Thanks for doing this.
>
>
> Thanks :)
>
>
> I'm not sure I understand all of the aspects of this effort. My
> current
> understanding is that Google Material is under the Apache License
> and
> thus
> we can use it if we want to. Am I correct that MaterialDesignLite
> is
> one
> implementation of Google Material and we could create our own
> implementation and it could be visually different?
>
>
> We can implement our own material in Royale, but I'm afraid that
> doing
> that
> will not make us
> highlight our solution against the rest of competitors. Another
> point
> is
> something I said various times:
> When I did MDL, I notice a huge problem: MDL has its own set of
> components,
> some are in all sets (Button)
> but others not (Card), and they has it's own implementation, what
> make
> it
> almost impossible generalize
> a theme. For this reason I always point that we need our own set
> and
> there
> we can implement themes. But other
> *externa* sets will never get this since they have its own
> implementation
> and most important once you start to develop
> with MDL you can't go back and change for other. So MDL is for me
> something
> we have until our own set are robust and
> highly configurable in both the things we can do and how can it
> could
> be
> represented, and switch between style should be
> really easy to change the global look of an App without much
> hassle.
>
>
>
> Also, IIRC, Material has different components than Flex did so
> we'd
> have
> to invent some new looks anyway. So having a TextInput with
> borders
> all
> around would just be our flavor of Material.
>
>
> That's what I point above. We must to *freeze* the list of
> components
> at
> some time work over a concrete set
> We can then plan in the future include a new component in the
> official
> set,
> and that will need to work on the themes we already
> have to include the new one.
>
>
>
> Regarding colors, it looks like Material is parameterized around a
> couple
> of colors. So if we did our skins to work against parameterized
> colors
> then would it really matter what color we choose?
>
>
> That's completly right. I could make wireframe based on two or
> three
> colors
> and as you change it in CSS all controls should tint
> consistently.
>
>
>
> Regarding Basic components, right now Checkbox is a <label><input
> type="check"/>caption</label>. AIUI, you cannot style the <input>
> on
> many
> browsers, so I think we have to have a different set of elements
> in
> a
> checkbox. It looks like Bootstrap uses:
>
> <label><input type="check"/><span />Caption</label>
>
> Where the span uses a special symbol font with checked and
> unchecked
> boxes.
>
>
> That's what we need to figure. Should we make themes available in
> Basic?
> if
> so, has basic the right implementation?
> If not, and if we don't want to change the actual very basic
> implementation, we need to put some "skin" implementation
> that at least in JS implementation I figure that will change one
> face
> (the
> actual basic) with the theme face.
>
> I'm thinking loud, since this is something we should explorer all
> together
> mixing the best ideas of people involved
>
> Thanks
>
>
>
>
> Thanks,
> Alex
>
> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com<ma...@gmail.com> on behalf of Carlos
> Rovira"
> <ca...@gmail.com> on behalf of carlosrovira@apache.org<ma...@apache.org>>
> wrote:
>
> Hi,
>
> I want to expose my initial work (very very initial) on two
> styles
> for
> Royale
>
>
> Wireframe:
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fsnag.gy%2
> FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1b5a7
> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=%2Fk8YQxC5bDOaC
> D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
>
> (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://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fsnag.gy%2
> FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1b5a7
> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=kxYE7ylOsXPUEeE
> r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
>
> (*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 <
> carlosrovira@apache.org<ma...@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 <ha...@gmail.com>>:
>
> BTW, the kind of thing we should be striving for in theme-able
> components
> is something like this:
>
>
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fvcalend
> ar.netlify.com<http://ar.netlify.com>%2F&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> 0f48%7Cf
>
> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636452649612378558&sdata=
> b3VtV
> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fvcalen
> dar.netlify.com<http://dar.netlify.com>%2F&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> 0f48%7C
>
> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636452649612378558&sdata=
> b3Vt
> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
>
> On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.a
> pache.org<http://pache.org>%2FcOBC&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> 0f48%7Cfa
> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=bRWKxm
> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
>
> <https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpast
> e
> .
> apache.org<http://apache.org>%2FcOBC&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> 0f48%7Cf
>
> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636452649612378558&sdata=
> bRWKx
> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
>
> (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
> <ca...@apache.org>
> <ma...@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 <ha...@gmail.com>
> <mailto:
> harbs.lists@gmail.com<ma...@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
> <ah...@adobe.com.INVALID>
> <ma...@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
>
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me<http://2Fabout.me>%
> 2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1
> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=C7a72gwfH2
> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>
>
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me<http://2Fabout.me>%2
> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1b5
> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=C7a72gwfH264w
> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>
>
>
>
> --
>
> <https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.codeo
> scopic.com<http://scopic.com>&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
> d8cf%7Cfa7b1b5a7b
> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> sdata=Hm%2B6WIcqQTOHs0
> UppUdckW%2FhhyzErprotQUOZNtUtXU%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<http://copic.com>&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
> d8cf%7Cfa7b1b5a7b3
> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> sdata=Hm%2B6WIcqQTOHs0U
> ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> d8cf%7Cfa7b1b5a
> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> sdata=b%2FFMr1Ajit94
> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
>
>
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me<http://2Fabout.me>%2
> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
> 82e0%7Cfa7b1b5
> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
> sdata=wYPMWW1wpTbtm
> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
>
>
>
>
> --
>
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=7oFpGJ95n%2FJh07KhDfmRnzFO7hyFwdlFZkz49OGjFq8%3D&reserved=0>
>
> Carlos Rovira
>
> Director General
>
> M: +34 607 22 60 05
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=7oFpGJ95n%2FJh07KhDfmRnzFO7hyFwdlFZkz49OGjFq8%3D&reserved=0
>
>
> Conocenos Avant2 en 1 minuto! <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=Df4JBWaWmTrEZYwvr1NTQBLOInEPtyF92ACWbYi4%2FL4%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.
>
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=sUBa9rnF1xMg4Pr1R6bGxzUl7m7qiGIaDrL%2FQKkeOtY%3D&reserved=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=sUBa9rnF1xMg4Pr1R6bGxzUl7m7qiGIaDrL%2FQKkeOtY%3D&reserved=0>*
>
>
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=KwVvFzo8w1oV00kHzCxI3Wyn0UlqIfyFWnazDdPpwrk%3D&reserved=0
>
Re: Working on UI Controls styling
Posted by Peter Ent <pe...@adobe.com.INVALID>.
A couple of questions:
How expensive is generating and applying CSS on the client?
How do developers that use CSS regularly feel about having to declare that many styles for all the buttons? Maybe tools like Dreamweaver make it simpler and we just need IDEs that could provide assistance.
Peter
On Nov 7, 2017, at 6:24 AM, Harbs <ha...@gmail.com>> wrote:
Some food for thought:
I created a custom component for “buttons” which allow simple skinning using image files. It works like this:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Ftc8f&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=tkoafaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2Ftc8f&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=tkoafaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%3D&reserved=0>
Specifying different states can be done using the following css:
.bug
{
background-image: url ('assets/up/report-bug.png');
}
.bug:hover{
background-image: url ('assets/over/report-bug.png');
}
.bug:active{
background-image: url ('assets/down/report-bug.png');
}
.bug:disabled{
background-image: url ('assets/disabled/report-bug.png');
}
It works well, but the problem with this approach is that it requires multiple css entries for every button.
Using it is done like this:
<comp:PanelButton id="bugButton"
enabled="{bugReportEnabled}" width="72" height="82"
x="19" y="283"
click="reportBug()" className="bug"/>
I wanted to allow the following:
<comp:PanelButton id="bugButton"
enabled="{bugReportEnabled}" width="72" height="82"
x="19" y="283"
click="reportBug()" className="bug"
image="assets/up/report-bug.png"
hoverImage="assets/over/report-bug.png"
activeImage="assets/down/report-bug.png"
disabledImage="assets/disabled/report-bug.png"/>
However, this is harder than you’d expect in HTML. Apparently there’s no way to set pseudo-styles using inline css.[1][2].
There are a couple of interesting work-arounds. One is using mouse events.[3]
Another is by creating CSS on the fly.[4] The answer assumes that the css is created on the server, but using the ideas I proposed in the ThemeManager class, that can be done on the client dynamically.
The challenge with the last approach would be in guaranteeing the css is unique to the images (or individual component). One option on that front would be to generate UIDs when the component is instantiated. A consideration is garbage-collecting CSS selectors when components might be removed.
I hope these ideas are helpful.
Harbs
[1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F5293280%2Fcss-pseudo-classes-with-inline-styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=krVr8HQkvOU3nqALzR4Hs5mzQbbB9m3v5uWgBzRkPII%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F5293280%2Fcss-pseudo-classes-with-inline-styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=krVr8HQkvOU3nqALzR4Hs5mzQbbB9m3v5uWgBzRkPII%3D&reserved=0>
[2]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F986618%2Fis-it-possible-to-create-inline-pseudo-styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=k3ItgYlMsw0VaXW6VYAlmnV8UFy8ZucwIIH77ji%2FQHQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F986618%2Fis-it-possible-to-create-inline-pseudo-styles&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=k3ItgYlMsw0VaXW6VYAlmnV8UFy8ZucwIIH77ji%2FQHQ%3D&reserved=0>
[3]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F5293426%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=y%2FokgjdUZq87z%2FZYiGD10OMz0xe%2BkcQ9U2EyPn2umEM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F5293426%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=y%2FokgjdUZq87z%2FZYiGD10OMz0xe%2BkcQ9U2EyPn2umEM%3D&reserved=0>
[4]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F39712777%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=sZUQLlcFJDWwhXZYwCoI68%2BLIxNhJMFg7q0%2FzIEpEBI%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fa%2F39712777%2F5475183&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=sZUQLlcFJDWwhXZYwCoI68%2BLIxNhJMFg7q0%2FzIEpEBI%3D&reserved=0>
On Nov 6, 2017, at 8:22 PM, Carlos Rovira <ca...@apache.org>> wrote:
Hi Harbs,
If we go with Basic as seems everybody suggest, I think we should not mix
with Express. We can "copy" some Express knowledge, but not make it
dependent, to avoid having a Frankenstein
Basic is the core, and from there we have Express and the new stylizable set
2017-11-05 22:01 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>>:
I was thinking about that and new component set is the approach which we
should try, but we need to base on something. My first thoughts was that it
should be Basic, cause I bet that once we start create style for each
component we will end up with some issue or we would like to create some
additional features to those controls in order to make that theme happen.
It leads my thought then farther let's say that we will start work in
following way:
1) Basic is our base
2) Carlos will prepare some appearance for component
3) We are starting to work on that, but it's end up that our component need
some additional feature, which is do not suits for Basic
4) We are adds that feature to Express and use in that place Express
component.
It ends up that our component theme will be mix of Express and Basic
Second approach is - Forget about Express, use Basic only and add to Theme
set features if needed. Express will be always separate set, FAT and it
will be responsibility for user if he would like to style it. - If our
implementation will be in Theme enough robust, user should be able to use
in his application Express with some styles from Theme set.
Thoughts ?
Piotr
2017-11-05 11:21 GMT+01:00 Harbs <ha...@gmail.com>>:
I would suggest starting a new component set with a fresh slate called
Themed (or something like that).
The Themed component set should give priority to style-ablitity and ease
of use over just about every other consideration. I think of Express as
more of a middle-of the road approach to make things easier. A Themed set
would be more of a replacement for mx and spark.
Yes. Definitely make a clear list of supported components. It’s probably
more important to have quality of components rather than quantity. A few
well constructed components is better than a lot of half-baked ones. More
components could always be added.
I’m very glad to hear that Angelo is working with you. That’s great news!
Harbs
On Nov 5, 2017, at 12:12 PM, Carlos Rovira <
carlos.rovira@codeoscopic.com<ma...@codeoscopic.com>> wrote:
ok Alex,
so if I understand correctly, you mean that we create our own set, with
Basic as base right?
but we should go with Express? It's great that we could create many
sets
in
Royale, and I think the Basic use
you commented is very licit and didn't think about that. But we must
think
in some *main* set, maybe is Express
and that I want to focus this effort for that concrete set.
I mean, one important thing here is that we all agree in support a
concrete
list of UI controls and components
I plan to make a discuss thread for this, since the theme feature will
affect only to that controls, and if we want to include a new one
we should vote to include it, since it implies to include in design,
implementation and all themes that we want to support.
I think I'll create a discuss thread with this an other things we
talked
about since this is a huge effort and is important for all the
people that will be involved to work around things discussed, voted and
approved by all.
We need to be synced here or we'll end working too much for somehitng
that
does not get to be useful in the end. I want to ensure this before
to start investing a huge amount of time.
As well I was contacted by Angelo and talk about all this. He's very
passionate as well on this and we'll seeing how we can combine our
efforts
and if someone
more wants to join us.
I'll be writing the discussion thread in order to plan the effort in
short.
Stay tuned :)
2017-11-05 8:29 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>>:
Hi Carlos,
I think we're pretty much in agreement. Regarding Basic, for me, I
have
created plenty of web pages with non-styleable checkboxes. I don't
care
that the checkbox looks different on different browsers. I just want
the
smallest simplest output. Just like taking an HTML editor and
slapping
in
a few tags and calling it done. Would that be production? Sure, if
I'm
just want someone to check a box before enabling a download button.
IOW,
it would be for internal customers only.
So, IMO, a Skinnable/Themeable component set would be something
else. I
think you will need that extra Span for a Checkbox. IMO, we should
just
go and build these new components. And when we get it mostly working,
we
can compare against Basic and see if we want to parameterize the views
in
the low-level Basic components or not.
My 2 cents,
-Alex
On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com<ma...@gmail.com> on behalf of Carlos
Rovira"
<ca...@gmail.com> on behalf of carlosrovira@apache.org<ma...@apache.org>> wrote:
HI Alex,
2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>>:
Hi Carlos,
I skimmed through
https://na01.safelinks.protection.outlook.com/?url=
https%3A%2F%2Fmaterial
.io%2Fguidelines%2F%23&data=02%7C01%7C%
7Cbb03216ec0b84fcb6ab108d52397
82e0
%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
7C636454056000808812&sdata=g5
M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last
night.
My impression is that there were two parts to it. First was the
environment/principles section which talked about physical objects
and
light (and motion), and then there were choices of widgets. For
example,
I didn't see anything in the first part that said that a text input
had
to
be a single line and couldn't be a box.
Material guidelines could be a great way to start, but trying to give
something different.
I think that we need to get something that looks great while be
clearly
different to google material,
bootstrap, and others so people could see us as an alternative. That
could
make people copying us
or adopting the whole Apache Royale SDK that is what we want in the
end
That made me think that we could use our widget set and apply
Material
environment and principles to it. If we decide not to, I would
think
you
would want to have some sort of similar environment/principles
document
which seems like a fair amount of work. I think we'd end up looking
different because we have different widgets and maybe some different
colors. I'm pretty sure that we don't want to be different so much
that
we don't create things that folks want to use. The priority to me
is
just
to prove that you can alter every pixel in every widget we have so
that
others can provide custom skins as well. So starting with Material
principles seems like it would save us time, we can get something
released, and can innovate more later.
I think as you that we need a way to make the "presentation" of each
component highly customizable.
And we need to be different in visualization (art, colors, ...) but
not in
usability that is what people
needs to be consistently
Maybe a good question for our users is: How many of you used the
default
Flex skins vs a whole new set of skins? If most folks completely
re-skinned to match their corporate branding, it matters less what
our
default is, and more that we can allow folks to customize every
pixel.
We need both: a skin that will be highly customizable and to change
skins
to look very very different.
People with lees money or time in their Apps will choose the first.
People
that has more resources will go with the second.
Apache Royale needs to support both
The wireframe can be black and white, IMO. I was thinking that
"vivid"
would have parameterized colors.
I started to think that wireframe could end having lots of
customization
controls. For example:
-2-3 main colors as we talked , and the same MDL does
-possibilitiy to be solid colors, or gradients
-possibility to have backgrounds more or less opaque
if we see a concrete component like button:
- configurable corners, square to round corners
- more blocky (relief) or more flat
...
So wireframe could be a concrete configuration of the main theme
Since Bootstrap was mentioned, I want to point out that the Flat.swc
is
a
rough approximation of the Flat theme which is a Bootstrap theme.
It
is a
rough approximation because I could not use the Flat CSS file
directly
since it contains much more advanced CSS than we currently support
on
the
SWF side. But it presumed that the Checkbox was a Label with a Span
that
hides in front of or behind the <input type="check" /> in order to
allow
customizing every pixel. Looks like MDL uses the same Span trick
but
maybe without a symbol font.
Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
should
not have that extra Span. But it looks to me that a
SkinnableCheckbox
can
add that extra Span and you either give it the same class name that
BootStrap or MDL uses or create our own set of classnames and the
CSS
that
goes with it.
The problem with Basic could be that if is very very basic and looks
with
a
very basic look (as it is very poorly stylizable), I think
People will not use it at all, in this case, I'll don't understand
the
goal
with basic. It's intend ended as a base
but to not use in production? For this reason is what I want to know
if
you
think this theme feature could be plugged in basic or not.
Of course, I could be wrong. This is not my area of expertise at
all.
Hi Alex, maybe UX is not your expertise area, but your help here is
very
needed since we can get to great ideas in this field, but
maybe don't know how to bring it to implementation in Apache Royale.
I
think that you, Peter, Harbs,... are needed in order to
make this happen in the pure arquitecture side or this feature.
Thanks
-Alex
On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com<ma...@gmail.com> on behalf of Carlos
Rovira"
<ca...@gmail.com> on behalf of carlos.rovira@codeoscopic.com<ma...@codeoscopic.com>
wrote:
Hi Alex,
2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>>:
Hi Carlos,
Looks good to me. Thanks for doing this.
Thanks :)
I'm not sure I understand all of the aspects of this effort. My
current
understanding is that Google Material is under the Apache License
and
thus
we can use it if we want to. Am I correct that MaterialDesignLite
is
one
implementation of Google Material and we could create our own
implementation and it could be visually different?
We can implement our own material in Royale, but I'm afraid that
doing
that
will not make us
highlight our solution against the rest of competitors. Another
point
is
something I said various times:
When I did MDL, I notice a huge problem: MDL has its own set of
components,
some are in all sets (Button)
but others not (Card), and they has it's own implementation, what
make
it
almost impossible generalize
a theme. For this reason I always point that we need our own set
and
there
we can implement themes. But other
*externa* sets will never get this since they have its own
implementation
and most important once you start to develop
with MDL you can't go back and change for other. So MDL is for me
something
we have until our own set are robust and
highly configurable in both the things we can do and how can it
could
be
represented, and switch between style should be
really easy to change the global look of an App without much
hassle.
Also, IIRC, Material has different components than Flex did so
we'd
have
to invent some new looks anyway. So having a TextInput with
borders
all
around would just be our flavor of Material.
That's what I point above. We must to *freeze* the list of
components
at
some time work over a concrete set
We can then plan in the future include a new component in the
official
set,
and that will need to work on the themes we already
have to include the new one.
Regarding colors, it looks like Material is parameterized around a
couple
of colors. So if we did our skins to work against parameterized
colors
then would it really matter what color we choose?
That's completly right. I could make wireframe based on two or
three
colors
and as you change it in CSS all controls should tint
consistently.
Regarding Basic components, right now Checkbox is a <label><input
type="check"/>caption</label>. AIUI, you cannot style the <input>
on
many
browsers, so I think we have to have a different set of elements
in
a
checkbox. It looks like Bootstrap uses:
<label><input type="check"/><span />Caption</label>
Where the span uses a special symbol font with checked and
unchecked
boxes.
That's what we need to figure. Should we make themes available in
Basic?
if
so, has basic the right implementation?
If not, and if we don't want to change the actual very basic
implementation, we need to put some "skin" implementation
that at least in JS implementation I figure that will change one
face
(the
actual basic) with the theme face.
I'm thinking loud, since this is something we should explorer all
together
mixing the best ideas of people involved
Thanks
Thanks,
Alex
On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com<ma...@gmail.com> on behalf of Carlos
Rovira"
<ca...@gmail.com> on behalf of carlosrovira@apache.org<ma...@apache.org>>
wrote:
Hi,
I want to expose my initial work (very very initial) on two
styles
for
Royale
Wireframe:
https://na01.safelinks.protection.outlook.com/?url=
https%3A%2F%2Fsnag.gy%2
FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
0f48%7Cfa7b1b5a7
b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
sdata=%2Fk8YQxC5bDOaC
D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
(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://na01.safelinks.protection.outlook.com/?url=
https%3A%2F%2Fsnag.gy%2
FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
0f48%7Cfa7b1b5a7
b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
sdata=kxYE7ylOsXPUEeE
r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
(*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 <
carlosrovira@apache.org<ma...@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 <ha...@gmail.com>>:
BTW, the kind of thing we should be striving for in theme-able
components
is something like this:
https://na01.safelinks.protection.outlook.com/?url=
https%3A%2F%2Fvcalend
ar.netlify.com<http://ar.netlify.com>%2F&data=02%7C01%7C%
7C203485b5b9c744aed92608d52250
0f48%7Cf
a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
7C636452649612378558&sdata=
b3VtV
VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=
https%3A%2F%2Fvcalen
dar.netlify.com<http://dar.netlify.com>%2F&data=02%7C01%7C%
7C203485b5b9c744aed92608d52250
0f48%7C
fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
7C636452649612378558&sdata=
b3Vt
VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
https%3A%2F%2Fpaste.a
pache.org<http://pache.org>%2FcOBC&data=02%7C01%7C%
7C203485b5b9c744aed92608d52250
0f48%7Cfa
7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
sdata=bRWKxm
LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=
https%3A%2F%2Fpast
e
.
apache.org<http://apache.org>%2FcOBC&data=02%7C01%7C%
7C203485b5b9c744aed92608d52250
0f48%7Cf
a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
7C636452649612378558&sdata=
bRWKx
mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
(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
<ca...@apache.org>
<ma...@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 <ha...@gmail.com>
<mailto:
harbs.lists@gmail.com<ma...@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
<ah...@adobe.com.INVALID>
<ma...@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
https://na01.safelinks.protection.outlook.com/?url=
http%3A%2F%2Fabout.me<http://2Fabout.me>%
2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
0f48%7Cfa7b1
b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
sdata=C7a72gwfH2
64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=
http%3A%2F%2Fabout.me<http://2Fabout.me>%2
Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
0f48%7Cfa7b1b5
a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
sdata=C7a72gwfH264w
Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
--
<https://na01.safelinks.protection.outlook.com/?url=
http%3A%2F%2Fwww.codeo
scopic.com<http://scopic.com>&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
d8cf%7Cfa7b1b5a7b
34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
sdata=Hm%2B6WIcqQTOHs0
UppUdckW%2FhhyzErprotQUOZNtUtXU%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<http://copic.com>&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
d8cf%7Cfa7b1b5a7b3
4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
sdata=Hm%2B6WIcqQTOHs0U
ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
d8cf%7Cfa7b1b5a
7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
sdata=b%2FFMr1Ajit94
TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=
http%3A%2F%2Fabout.me<http://2Fabout.me>%2
Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
82e0%7Cfa7b1b5
a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
sdata=wYPMWW1wpTbtm
pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
--
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=7oFpGJ95n%2FJh07KhDfmRnzFO7hyFwdlFZkz49OGjFq8%3D&reserved=0>
Carlos Rovira
Director General
M: +34 607 22 60 05
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=7oFpGJ95n%2FJh07KhDfmRnzFO7hyFwdlFZkz49OGjFq8%3D&reserved=0
Conocenos Avant2 en 1 minuto! <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=Df4JBWaWmTrEZYwvr1NTQBLOInEPtyF92ACWbYi4%2FL4%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.
--
Piotr Zarzycki
Patreon: *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=sUBa9rnF1xMg4Pr1R6bGxzUl7m7qiGIaDrL%2FQKkeOtY%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=sUBa9rnF1xMg4Pr1R6bGxzUl7m7qiGIaDrL%2FQKkeOtY%3D&reserved=0>*
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243&sdata=KwVvFzo8w1oV00kHzCxI3Wyn0UlqIfyFWnazDdPpwrk%3D&reserved=0
Re: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
Some food for thought:
I created a custom component for “buttons” which allow simple skinning using image files. It works like this:
https://paste.apache.org/tc8f <https://paste.apache.org/tc8f>
Specifying different states can be done using the following css:
.bug
{
background-image: url ('assets/up/report-bug.png');
}
.bug:hover{
background-image: url ('assets/over/report-bug.png');
}
.bug:active{
background-image: url ('assets/down/report-bug.png');
}
.bug:disabled{
background-image: url ('assets/disabled/report-bug.png');
}
It works well, but the problem with this approach is that it requires multiple css entries for every button.
Using it is done like this:
<comp:PanelButton id="bugButton"
enabled="{bugReportEnabled}" width="72" height="82"
x="19" y="283"
click="reportBug()" className="bug"/>
I wanted to allow the following:
<comp:PanelButton id="bugButton"
enabled="{bugReportEnabled}" width="72" height="82"
x="19" y="283"
click="reportBug()" className="bug"
image="assets/up/report-bug.png"
hoverImage="assets/over/report-bug.png"
activeImage="assets/down/report-bug.png"
disabledImage="assets/disabled/report-bug.png"/>
However, this is harder than you’d expect in HTML. Apparently there’s no way to set pseudo-styles using inline css.[1][2].
There are a couple of interesting work-arounds. One is using mouse events.[3]
Another is by creating CSS on the fly.[4] The answer assumes that the css is created on the server, but using the ideas I proposed in the ThemeManager class, that can be done on the client dynamically.
The challenge with the last approach would be in guaranteeing the css is unique to the images (or individual component). One option on that front would be to generate UIDs when the component is instantiated. A consideration is garbage-collecting CSS selectors when components might be removed.
I hope these ideas are helpful.
Harbs
[1]https://stackoverflow.com/questions/5293280/css-pseudo-classes-with-inline-styles <https://stackoverflow.com/questions/5293280/css-pseudo-classes-with-inline-styles>
[2]https://stackoverflow.com/questions/986618/is-it-possible-to-create-inline-pseudo-styles <https://stackoverflow.com/questions/986618/is-it-possible-to-create-inline-pseudo-styles>
[3]https://stackoverflow.com/a/5293426/5475183 <https://stackoverflow.com/a/5293426/5475183>
[4]https://stackoverflow.com/a/39712777/5475183 <https://stackoverflow.com/a/39712777/5475183>
> On Nov 6, 2017, at 8:22 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Harbs,
>
> If we go with Basic as seems everybody suggest, I think we should not mix
> with Express. We can "copy" some Express knowledge, but not make it
> dependent, to avoid having a Frankenstein
> Basic is the core, and from there we have Express and the new stylizable set
>
> 2017-11-05 22:01 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
>
>> I was thinking about that and new component set is the approach which we
>> should try, but we need to base on something. My first thoughts was that it
>> should be Basic, cause I bet that once we start create style for each
>> component we will end up with some issue or we would like to create some
>> additional features to those controls in order to make that theme happen.
>> It leads my thought then farther let's say that we will start work in
>> following way:
>> 1) Basic is our base
>> 2) Carlos will prepare some appearance for component
>> 3) We are starting to work on that, but it's end up that our component need
>> some additional feature, which is do not suits for Basic
>> 4) We are adds that feature to Express and use in that place Express
>> component.
>>
>> It ends up that our component theme will be mix of Express and Basic
>>
>> Second approach is - Forget about Express, use Basic only and add to Theme
>> set features if needed. Express will be always separate set, FAT and it
>> will be responsibility for user if he would like to style it. - If our
>> implementation will be in Theme enough robust, user should be able to use
>> in his application Express with some styles from Theme set.
>>
>> Thoughts ?
>> Piotr
>>
>>
>> 2017-11-05 11:21 GMT+01:00 Harbs <ha...@gmail.com>:
>>
>>> I would suggest starting a new component set with a fresh slate called
>>> Themed (or something like that).
>>>
>>> The Themed component set should give priority to style-ablitity and ease
>>> of use over just about every other consideration. I think of Express as
>>> more of a middle-of the road approach to make things easier. A Themed set
>>> would be more of a replacement for mx and spark.
>>>
>>> Yes. Definitely make a clear list of supported components. It’s probably
>>> more important to have quality of components rather than quantity. A few
>>> well constructed components is better than a lot of half-baked ones. More
>>> components could always be added.
>>>
>>> I’m very glad to hear that Angelo is working with you. That’s great news!
>>>
>>> Harbs
>>>
>>>> On Nov 5, 2017, at 12:12 PM, Carlos Rovira <
>>> carlos.rovira@codeoscopic.com> wrote:
>>>>
>>>> ok Alex,
>>>>
>>>> so if I understand correctly, you mean that we create our own set, with
>>>> Basic as base right?
>>>> but we should go with Express? It's great that we could create many
>> sets
>>> in
>>>> Royale, and I think the Basic use
>>>> you commented is very licit and didn't think about that. But we must
>>> think
>>>> in some *main* set, maybe is Express
>>>> and that I want to focus this effort for that concrete set.
>>>>
>>>> I mean, one important thing here is that we all agree in support a
>>> concrete
>>>> list of UI controls and components
>>>> I plan to make a discuss thread for this, since the theme feature will
>>>> affect only to that controls, and if we want to include a new one
>>>> we should vote to include it, since it implies to include in design,
>>>> implementation and all themes that we want to support.
>>>>
>>>> I think I'll create a discuss thread with this an other things we
>> talked
>>>> about since this is a huge effort and is important for all the
>>>> people that will be involved to work around things discussed, voted and
>>>> approved by all.
>>>> We need to be synced here or we'll end working too much for somehitng
>>> that
>>>> does not get to be useful in the end. I want to ensure this before
>>>> to start investing a huge amount of time.
>>>>
>>>> As well I was contacted by Angelo and talk about all this. He's very
>>>> passionate as well on this and we'll seeing how we can combine our
>>> efforts
>>>> and if someone
>>>> more wants to join us.
>>>>
>>>> I'll be writing the discussion thread in order to plan the effort in
>>> short.
>>>> Stay tuned :)
>>>>
>>>> 2017-11-05 8:29 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>
>>>>> Hi Carlos,
>>>>>
>>>>> I think we're pretty much in agreement. Regarding Basic, for me, I
>> have
>>>>> created plenty of web pages with non-styleable checkboxes. I don't
>> care
>>>>> that the checkbox looks different on different browsers. I just want
>>> the
>>>>> smallest simplest output. Just like taking an HTML editor and
>> slapping
>>> in
>>>>> a few tags and calling it done. Would that be production? Sure, if
>> I'm
>>>>> just want someone to check a box before enabling a download button.
>>> IOW,
>>>>> it would be for internal customers only.
>>>>>
>>>>> So, IMO, a Skinnable/Themeable component set would be something
>> else. I
>>>>> think you will need that extra Span for a Checkbox. IMO, we should
>> just
>>>>> go and build these new components. And when we get it mostly working,
>>> we
>>>>> can compare against Basic and see if we want to parameterize the views
>>> in
>>>>> the low-level Basic components or not.
>>>>>
>>>>> My 2 cents,
>>>>> -Alex
>>>>>
>>>>> On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>> Rovira"
>>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>>>>
>>>>>> HI Alex,
>>>>>>
>>>>>>
>>>>>> 2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>>>
>>>>>>> Hi Carlos,
>>>>>>>
>>>>>>> I skimmed through
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>> https%3A%2F%2Fmaterial
>>>>>>> .io%2Fguidelines%2F%23&data=02%7C01%7C%
>> 7Cbb03216ec0b84fcb6ab108d52397
>>>>> 82e0
>>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>> 7C636454056000808812&sdata=g5
>>>>>>> M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last
>>> night.
>>>>>>>
>>>>>>> My impression is that there were two parts to it. First was the
>>>>>>> environment/principles section which talked about physical objects
>> and
>>>>>>> light (and motion), and then there were choices of widgets. For
>>>>>>> example,
>>>>>>> I didn't see anything in the first part that said that a text input
>>> had
>>>>>>> to
>>>>>>> be a single line and couldn't be a box.
>>>>>>>
>>>>>>
>>>>>> Material guidelines could be a great way to start, but trying to give
>>>>>> something different.
>>>>>> I think that we need to get something that looks great while be
>> clearly
>>>>>> different to google material,
>>>>>> bootstrap, and others so people could see us as an alternative. That
>>> could
>>>>>> make people copying us
>>>>>> or adopting the whole Apache Royale SDK that is what we want in the
>> end
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> That made me think that we could use our widget set and apply
>> Material
>>>>>>> environment and principles to it. If we decide not to, I would
>> think
>>>>>>> you
>>>>>>> would want to have some sort of similar environment/principles
>>> document
>>>>>>> which seems like a fair amount of work. I think we'd end up looking
>>>>>>> different because we have different widgets and maybe some different
>>>>>>> colors. I'm pretty sure that we don't want to be different so much
>>> that
>>>>>>> we don't create things that folks want to use. The priority to me
>> is
>>>>>>> just
>>>>>>> to prove that you can alter every pixel in every widget we have so
>>> that
>>>>>>> others can provide custom skins as well. So starting with Material
>>>>>>> principles seems like it would save us time, we can get something
>>>>>>> released, and can innovate more later.
>>>>>>>
>>>>>>
>>>>>> I think as you that we need a way to make the "presentation" of each
>>>>>> component highly customizable.
>>>>>> And we need to be different in visualization (art, colors, ...) but
>>> not in
>>>>>> usability that is what people
>>>>>> needs to be consistently
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Maybe a good question for our users is: How many of you used the
>>>>>>> default
>>>>>>> Flex skins vs a whole new set of skins? If most folks completely
>>>>>>> re-skinned to match their corporate branding, it matters less what
>> our
>>>>>>> default is, and more that we can allow folks to customize every
>> pixel.
>>>>>>>
>>>>>>>
>>>>>> We need both: a skin that will be highly customizable and to change
>>> skins
>>>>>> to look very very different.
>>>>>> People with lees money or time in their Apps will choose the first.
>>> People
>>>>>> that has more resources will go with the second.
>>>>>> Apache Royale needs to support both
>>>>>>
>>>>>>
>>>>>>> The wireframe can be black and white, IMO. I was thinking that
>>> "vivid"
>>>>>>> would have parameterized colors.
>>>>>>>
>>>>>>>
>>>>>> I started to think that wireframe could end having lots of
>>> customization
>>>>>> controls. For example:
>>>>>>
>>>>>> -2-3 main colors as we talked , and the same MDL does
>>>>>> -possibilitiy to be solid colors, or gradients
>>>>>> -possibility to have backgrounds more or less opaque
>>>>>>
>>>>>> if we see a concrete component like button:
>>>>>>
>>>>>> - configurable corners, square to round corners
>>>>>> - more blocky (relief) or more flat
>>>>>> ...
>>>>>>
>>>>>> So wireframe could be a concrete configuration of the main theme
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Since Bootstrap was mentioned, I want to point out that the Flat.swc
>>> is
>>>>>>> a
>>>>>>> rough approximation of the Flat theme which is a Bootstrap theme.
>> It
>>>>>>> is a
>>>>>>> rough approximation because I could not use the Flat CSS file
>> directly
>>>>>>> since it contains much more advanced CSS than we currently support
>> on
>>>>>>> the
>>>>>>> SWF side. But it presumed that the Checkbox was a Label with a Span
>>>>>>> that
>>>>>>> hides in front of or behind the <input type="check" /> in order to
>>> allow
>>>>>>> customizing every pixel. Looks like MDL uses the same Span trick
>> but
>>>>>>> maybe without a symbol font.
>>>>>>>
>>>>>>> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
>>>>>>> should
>>>>>>> not have that extra Span. But it looks to me that a
>> SkinnableCheckbox
>>>>>>> can
>>>>>>> add that extra Span and you either give it the same class name that
>>>>>>> BootStrap or MDL uses or create our own set of classnames and the
>> CSS
>>>>>>> that
>>>>>>> goes with it.
>>>>>>>
>>>>>>>
>>>>>> The problem with Basic could be that if is very very basic and looks
>>> with
>>>>>> a
>>>>>> very basic look (as it is very poorly stylizable), I think
>>>>>> People will not use it at all, in this case, I'll don't understand
>> the
>>>>>> goal
>>>>>> with basic. It's intend ended as a base
>>>>>> but to not use in production? For this reason is what I want to know
>> if
>>>>>> you
>>>>>> think this theme feature could be plugged in basic or not.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Of course, I could be wrong. This is not my area of expertise at
>> all.
>>>>>>>
>>>>>>
>>>>>> Hi Alex, maybe UX is not your expertise area, but your help here is
>>> very
>>>>>> needed since we can get to great ideas in this field, but
>>>>>> maybe don't know how to bring it to implementation in Apache Royale.
>> I
>>>>>> think that you, Peter, Harbs,... are needed in order to
>>>>>> make this happen in the pure arquitecture side or this feature.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -Alex
>>>>>>>
>>>>>>>
>>>>>>> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>>>>>> Rovira"
>>>>>>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com
>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Alex,
>>>>>>>>
>>>>>>>> 2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>>>>>
>>>>>>>>> Hi Carlos,
>>>>>>>>>
>>>>>>>>> Looks good to me. Thanks for doing this.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks :)
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm not sure I understand all of the aspects of this effort. My
>>>>>>> current
>>>>>>>>> understanding is that Google Material is under the Apache License
>>> and
>>>>>>>>> thus
>>>>>>>>> we can use it if we want to. Am I correct that MaterialDesignLite
>>> is
>>>>>>>>> one
>>>>>>>>> implementation of Google Material and we could create our own
>>>>>>>>> implementation and it could be visually different?
>>>>>>>>>
>>>>>>>>
>>>>>>>> We can implement our own material in Royale, but I'm afraid that
>>> doing
>>>>>>>> that
>>>>>>>> will not make us
>>>>>>>> highlight our solution against the rest of competitors. Another
>> point
>>>>>>> is
>>>>>>>> something I said various times:
>>>>>>>> When I did MDL, I notice a huge problem: MDL has its own set of
>>>>>>>> components,
>>>>>>>> some are in all sets (Button)
>>>>>>>> but others not (Card), and they has it's own implementation, what
>>> make
>>>>>>> it
>>>>>>>> almost impossible generalize
>>>>>>>> a theme. For this reason I always point that we need our own set
>> and
>>>>>>> there
>>>>>>>> we can implement themes. But other
>>>>>>>> *externa* sets will never get this since they have its own
>>>>>>> implementation
>>>>>>>> and most important once you start to develop
>>>>>>>> with MDL you can't go back and change for other. So MDL is for me
>>>>>>>> something
>>>>>>>> we have until our own set are robust and
>>>>>>>> highly configurable in both the things we can do and how can it
>> could
>>>>>>> be
>>>>>>>> represented, and switch between style should be
>>>>>>>> really easy to change the global look of an App without much
>> hassle.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also, IIRC, Material has different components than Flex did so
>> we'd
>>>>>>> have
>>>>>>>>> to invent some new looks anyway. So having a TextInput with
>> borders
>>>>>>> all
>>>>>>>>> around would just be our flavor of Material.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's what I point above. We must to *freeze* the list of
>> components
>>>>>>> at
>>>>>>>> some time work over a concrete set
>>>>>>>> We can then plan in the future include a new component in the
>>> official
>>>>>>>> set,
>>>>>>>> and that will need to work on the themes we already
>>>>>>>> have to include the new one.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regarding colors, it looks like Material is parameterized around a
>>>>>>>>> couple
>>>>>>>>> of colors. So if we did our skins to work against parameterized
>>>>>>> colors
>>>>>>>>> then would it really matter what color we choose?
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's completly right. I could make wireframe based on two or
>> three
>>>>>>>> colors
>>>>>>>> and as you change it in CSS all controls should tint
>>>>>>>> consistently.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regarding Basic components, right now Checkbox is a <label><input
>>>>>>>>> type="check"/>caption</label>. AIUI, you cannot style the <input>
>>> on
>>>>>>>>> many
>>>>>>>>> browsers, so I think we have to have a different set of elements
>> in
>>> a
>>>>>>>>> checkbox. It looks like Bootstrap uses:
>>>>>>>>>
>>>>>>>>> <label><input type="check"/><span />Caption</label>
>>>>>>>>>
>>>>>>>>> Where the span uses a special symbol font with checked and
>> unchecked
>>>>>>>>> boxes.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's what we need to figure. Should we make themes available in
>>>>>>> Basic?
>>>>>>>> if
>>>>>>>> so, has basic the right implementation?
>>>>>>>> If not, and if we don't want to change the actual very basic
>>>>>>>> implementation, we need to put some "skin" implementation
>>>>>>>> that at least in JS implementation I figure that will change one
>> face
>>>>>>> (the
>>>>>>>> actual basic) with the theme face.
>>>>>>>>
>>>>>>>> I'm thinking loud, since this is something we should explorer all
>>>>>>> together
>>>>>>>> mixing the best ideas of people involved
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos
>>>>>>>>> Rovira"
>>>>>>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I want to expose my initial work (very very initial) on two
>> styles
>>>>>>> for
>>>>>>>>>> Royale
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Wireframe:
>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fsnag.gy%2
>>>>>>>>>> FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa7b1b5a7
>>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=%2Fk8YQxC5bDOaC
>>>>>>>>>> D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
>>>>>>>>>>
>>>>>>>>>> (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://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fsnag.gy%2
>>>>>>>>>> FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa7b1b5a7
>>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=kxYE7ylOsXPUEeE
>>>>>>>>>> r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
>>>>>>>>>>
>>>>>>>>>> (*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 <
>> carlosrovira@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 <ha...@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> BTW, the kind of thing we should be striving for in theme-able
>>>>>>>>>>>> components
>>>>>>>>>>>> is something like this:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fvcalend
>>>>>>>>>>>> ar.netlify.com%2F&data=02%7C01%7C%
>> 7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cf
>>>>>>>>>
>>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636452649612378558&sdata=
>>>>>>>>> b3VtV
>>>>>>>>>>>> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
>>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fvcalen
>>>>>>>>>>>> dar.netlify.com%2F&data=02%7C01%7C%
>>> 7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7C
>>>>>>>>>
>>>>>>>>>> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636452649612378558&sdata=
>>>>>>>>> b3Vt
>>>>>>>>>>>> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fpaste.a
>>>>>>>>>>>> pache.org%2FcOBC&data=02%7C01%7C%
>> 7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa
>>>>>>>>>>>> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=bRWKxm
>>>>>>>>>>>> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
>>>>>>>>>
>>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> https%3A%2F%2Fpast
>>>>>>>>>>>> e
>>>>>>>>> .
>>>>>>>>>>>> apache.org%2FcOBC&data=02%7C01%7C%
>> 7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cf
>>>>>>>>>
>>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636452649612378558&sdata=
>>>>>>>>> bRWKx
>>>>>>>>>>>> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
>>>>>>>>>>>>>
>>>>>>>>>>>>> (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
>>>>>>>>> <carlosrovira@apache.org
>>>>>>>>>>>> <ma...@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.lists@gmail.com
>>>>>>> <mailto:
>>>>>>>>>>>> harbs.lists@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
>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>
>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> http%3A%2F%2Fabout.me%
>>>>>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa7b1
>>>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=C7a72gwfH2
>>>>>>>>>>> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Carlos Rovira
>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> http%3A%2F%2Fabout.me%2
>>>>>>>>>> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa7b1b5
>>>>>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=C7a72gwfH264w
>>>>>>>>>> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> http%3A%2F%2Fwww.codeo
>>>>>>>> scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
>>>>>>> d8cf%7Cfa7b1b5a7b
>>>>>>>> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>>>>> sdata=Hm%2B6WIcqQTOHs0
>>>>>>>> UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>>>>>>> d8cf%7Cfa7b1b5a7b3
>>>>>>>> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>>>>> sdata=Hm%2B6WIcqQTOHs0U
>>>>>>>> ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>>>>>>> d8cf%7Cfa7b1b5a
>>>>>>>> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>>>>> sdata=b%2FFMr1Ajit94
>>>>>>>> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>> http%3A%2F%2Fabout.me%2
>>>>>> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
>>>>> 82e0%7Cfa7b1b5
>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
>>>>> sdata=wYPMWW1wpTbtm
>>>>>> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> <http://www.codeoscopic.com>
>>>>
>>>> Carlos Rovira
>>>>
>>>> Director General
>>>>
>>>> M: +34 607 22 60 05
>>>>
>>>> http://www.codeoscopic.com
>>>>
>>>>
>>>> Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
>>>>
>>>>
>>>> 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.
>>>
>>>
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>> Patreon: *https://www.patreon.com/piotrzarzycki
>> <https://www.patreon.com/piotrzarzycki>*
>>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: Working on UI Controls styling
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
If we go with Basic as seems everybody suggest, I think we should not mix
with Express. We can "copy" some Express knowledge, but not make it
dependent, to avoid having a Frankenstein
Basic is the core, and from there we have Express and the new stylizable set
2017-11-05 22:01 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
> I was thinking about that and new component set is the approach which we
> should try, but we need to base on something. My first thoughts was that it
> should be Basic, cause I bet that once we start create style for each
> component we will end up with some issue or we would like to create some
> additional features to those controls in order to make that theme happen.
> It leads my thought then farther let's say that we will start work in
> following way:
> 1) Basic is our base
> 2) Carlos will prepare some appearance for component
> 3) We are starting to work on that, but it's end up that our component need
> some additional feature, which is do not suits for Basic
> 4) We are adds that feature to Express and use in that place Express
> component.
>
> It ends up that our component theme will be mix of Express and Basic
>
> Second approach is - Forget about Express, use Basic only and add to Theme
> set features if needed. Express will be always separate set, FAT and it
> will be responsibility for user if he would like to style it. - If our
> implementation will be in Theme enough robust, user should be able to use
> in his application Express with some styles from Theme set.
>
> Thoughts ?
> Piotr
>
>
> 2017-11-05 11:21 GMT+01:00 Harbs <ha...@gmail.com>:
>
> > I would suggest starting a new component set with a fresh slate called
> > Themed (or something like that).
> >
> > The Themed component set should give priority to style-ablitity and ease
> > of use over just about every other consideration. I think of Express as
> > more of a middle-of the road approach to make things easier. A Themed set
> > would be more of a replacement for mx and spark.
> >
> > Yes. Definitely make a clear list of supported components. It’s probably
> > more important to have quality of components rather than quantity. A few
> > well constructed components is better than a lot of half-baked ones. More
> > components could always be added.
> >
> > I’m very glad to hear that Angelo is working with you. That’s great news!
> >
> > Harbs
> >
> > > On Nov 5, 2017, at 12:12 PM, Carlos Rovira <
> > carlos.rovira@codeoscopic.com> wrote:
> > >
> > > ok Alex,
> > >
> > > so if I understand correctly, you mean that we create our own set, with
> > > Basic as base right?
> > > but we should go with Express? It's great that we could create many
> sets
> > in
> > > Royale, and I think the Basic use
> > > you commented is very licit and didn't think about that. But we must
> > think
> > > in some *main* set, maybe is Express
> > > and that I want to focus this effort for that concrete set.
> > >
> > > I mean, one important thing here is that we all agree in support a
> > concrete
> > > list of UI controls and components
> > > I plan to make a discuss thread for this, since the theme feature will
> > > affect only to that controls, and if we want to include a new one
> > > we should vote to include it, since it implies to include in design,
> > > implementation and all themes that we want to support.
> > >
> > > I think I'll create a discuss thread with this an other things we
> talked
> > > about since this is a huge effort and is important for all the
> > > people that will be involved to work around things discussed, voted and
> > > approved by all.
> > > We need to be synced here or we'll end working too much for somehitng
> > that
> > > does not get to be useful in the end. I want to ensure this before
> > > to start investing a huge amount of time.
> > >
> > > As well I was contacted by Angelo and talk about all this. He's very
> > > passionate as well on this and we'll seeing how we can combine our
> > efforts
> > > and if someone
> > > more wants to join us.
> > >
> > > I'll be writing the discussion thread in order to plan the effort in
> > short.
> > > Stay tuned :)
> > >
> > > 2017-11-05 8:29 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> > >
> > >> Hi Carlos,
> > >>
> > >> I think we're pretty much in agreement. Regarding Basic, for me, I
> have
> > >> created plenty of web pages with non-styleable checkboxes. I don't
> care
> > >> that the checkbox looks different on different browsers. I just want
> > the
> > >> smallest simplest output. Just like taking an HTML editor and
> slapping
> > in
> > >> a few tags and calling it done. Would that be production? Sure, if
> I'm
> > >> just want someone to check a box before enabling a download button.
> > IOW,
> > >> it would be for internal customers only.
> > >>
> > >> So, IMO, a Skinnable/Themeable component set would be something
> else. I
> > >> think you will need that extra Span for a Checkbox. IMO, we should
> just
> > >> go and build these new components. And when we get it mostly working,
> > we
> > >> can compare against Basic and see if we want to parameterize the views
> > in
> > >> the low-level Basic components or not.
> > >>
> > >> My 2 cents,
> > >> -Alex
> > >>
> > >> On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com on behalf of Carlos
> > Rovira"
> > >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
> > >>
> > >>> HI Alex,
> > >>>
> > >>>
> > >>> 2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> > >>>
> > >>>> Hi Carlos,
> > >>>>
> > >>>> I skimmed through
> > >>>> https://na01.safelinks.protection.outlook.com/?url=
> > >> https%3A%2F%2Fmaterial
> > >>>> .io%2Fguidelines%2F%23&data=02%7C01%7C%
> 7Cbb03216ec0b84fcb6ab108d52397
> > >> 82e0
> > >>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> > >> 7C636454056000808812&sdata=g5
> > >>>> M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last
> > night.
> > >>>>
> > >>>> My impression is that there were two parts to it. First was the
> > >>>> environment/principles section which talked about physical objects
> and
> > >>>> light (and motion), and then there were choices of widgets. For
> > >>>> example,
> > >>>> I didn't see anything in the first part that said that a text input
> > had
> > >>>> to
> > >>>> be a single line and couldn't be a box.
> > >>>>
> > >>>
> > >>> Material guidelines could be a great way to start, but trying to give
> > >>> something different.
> > >>> I think that we need to get something that looks great while be
> clearly
> > >>> different to google material,
> > >>> bootstrap, and others so people could see us as an alternative. That
> > could
> > >>> make people copying us
> > >>> or adopting the whole Apache Royale SDK that is what we want in the
> end
> > >>>
> > >>>
> > >>>
> > >>>>
> > >>>> That made me think that we could use our widget set and apply
> Material
> > >>>> environment and principles to it. If we decide not to, I would
> think
> > >>>> you
> > >>>> would want to have some sort of similar environment/principles
> > document
> > >>>> which seems like a fair amount of work. I think we'd end up looking
> > >>>> different because we have different widgets and maybe some different
> > >>>> colors. I'm pretty sure that we don't want to be different so much
> > that
> > >>>> we don't create things that folks want to use. The priority to me
> is
> > >>>> just
> > >>>> to prove that you can alter every pixel in every widget we have so
> > that
> > >>>> others can provide custom skins as well. So starting with Material
> > >>>> principles seems like it would save us time, we can get something
> > >>>> released, and can innovate more later.
> > >>>>
> > >>>
> > >>> I think as you that we need a way to make the "presentation" of each
> > >>> component highly customizable.
> > >>> And we need to be different in visualization (art, colors, ...) but
> > not in
> > >>> usability that is what people
> > >>> needs to be consistently
> > >>>
> > >>>
> > >>>
> > >>>>
> > >>>> Maybe a good question for our users is: How many of you used the
> > >>>> default
> > >>>> Flex skins vs a whole new set of skins? If most folks completely
> > >>>> re-skinned to match their corporate branding, it matters less what
> our
> > >>>> default is, and more that we can allow folks to customize every
> pixel.
> > >>>>
> > >>>>
> > >>> We need both: a skin that will be highly customizable and to change
> > skins
> > >>> to look very very different.
> > >>> People with lees money or time in their Apps will choose the first.
> > People
> > >>> that has more resources will go with the second.
> > >>> Apache Royale needs to support both
> > >>>
> > >>>
> > >>>> The wireframe can be black and white, IMO. I was thinking that
> > "vivid"
> > >>>> would have parameterized colors.
> > >>>>
> > >>>>
> > >>> I started to think that wireframe could end having lots of
> > customization
> > >>> controls. For example:
> > >>>
> > >>> -2-3 main colors as we talked , and the same MDL does
> > >>> -possibilitiy to be solid colors, or gradients
> > >>> -possibility to have backgrounds more or less opaque
> > >>>
> > >>> if we see a concrete component like button:
> > >>>
> > >>> - configurable corners, square to round corners
> > >>> - more blocky (relief) or more flat
> > >>> ...
> > >>>
> > >>> So wireframe could be a concrete configuration of the main theme
> > >>>
> > >>>
> > >>>
> > >>>> Since Bootstrap was mentioned, I want to point out that the Flat.swc
> > is
> > >>>> a
> > >>>> rough approximation of the Flat theme which is a Bootstrap theme.
> It
> > >>>> is a
> > >>>> rough approximation because I could not use the Flat CSS file
> directly
> > >>>> since it contains much more advanced CSS than we currently support
> on
> > >>>> the
> > >>>> SWF side. But it presumed that the Checkbox was a Label with a Span
> > >>>> that
> > >>>> hides in front of or behind the <input type="check" /> in order to
> > allow
> > >>>> customizing every pixel. Looks like MDL uses the same Span trick
> but
> > >>>> maybe without a symbol font.
> > >>>>
> > >>>> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
> > >>>> should
> > >>>> not have that extra Span. But it looks to me that a
> SkinnableCheckbox
> > >>>> can
> > >>>> add that extra Span and you either give it the same class name that
> > >>>> BootStrap or MDL uses or create our own set of classnames and the
> CSS
> > >>>> that
> > >>>> goes with it.
> > >>>>
> > >>>>
> > >>> The problem with Basic could be that if is very very basic and looks
> > with
> > >>> a
> > >>> very basic look (as it is very poorly stylizable), I think
> > >>> People will not use it at all, in this case, I'll don't understand
> the
> > >>> goal
> > >>> with basic. It's intend ended as a base
> > >>> but to not use in production? For this reason is what I want to know
> if
> > >>> you
> > >>> think this theme feature could be plugged in basic or not.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> Of course, I could be wrong. This is not my area of expertise at
> all.
> > >>>>
> > >>>
> > >>> Hi Alex, maybe UX is not your expertise area, but your help here is
> > very
> > >>> needed since we can get to great ideas in this field, but
> > >>> maybe don't know how to bring it to implementation in Apache Royale.
> I
> > >>> think that you, Peter, Harbs,... are needed in order to
> > >>> make this happen in the pure arquitecture side or this feature.
> > >>>
> > >>> Thanks
> > >>>
> > >>> -Alex
> > >>>>
> > >>>>
> > >>>> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
> > >>>> Rovira"
> > >>>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com
> >
> > >>>> wrote:
> > >>>>
> > >>>>> Hi Alex,
> > >>>>>
> > >>>>> 2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> > >>>>>
> > >>>>>> Hi Carlos,
> > >>>>>>
> > >>>>>> Looks good to me. Thanks for doing this.
> > >>>>>>
> > >>>>>
> > >>>>> Thanks :)
> > >>>>>
> > >>>>>>
> > >>>>>> I'm not sure I understand all of the aspects of this effort. My
> > >>>> current
> > >>>>>> understanding is that Google Material is under the Apache License
> > and
> > >>>>>> thus
> > >>>>>> we can use it if we want to. Am I correct that MaterialDesignLite
> > is
> > >>>>>> one
> > >>>>>> implementation of Google Material and we could create our own
> > >>>>>> implementation and it could be visually different?
> > >>>>>>
> > >>>>>
> > >>>>> We can implement our own material in Royale, but I'm afraid that
> > doing
> > >>>>> that
> > >>>>> will not make us
> > >>>>> highlight our solution against the rest of competitors. Another
> point
> > >>>> is
> > >>>>> something I said various times:
> > >>>>> When I did MDL, I notice a huge problem: MDL has its own set of
> > >>>>> components,
> > >>>>> some are in all sets (Button)
> > >>>>> but others not (Card), and they has it's own implementation, what
> > make
> > >>>> it
> > >>>>> almost impossible generalize
> > >>>>> a theme. For this reason I always point that we need our own set
> and
> > >>>> there
> > >>>>> we can implement themes. But other
> > >>>>> *externa* sets will never get this since they have its own
> > >>>> implementation
> > >>>>> and most important once you start to develop
> > >>>>> with MDL you can't go back and change for other. So MDL is for me
> > >>>>> something
> > >>>>> we have until our own set are robust and
> > >>>>> highly configurable in both the things we can do and how can it
> could
> > >>>> be
> > >>>>> represented, and switch between style should be
> > >>>>> really easy to change the global look of an App without much
> hassle.
> > >>>>>
> > >>>>>
> > >>>>>>
> > >>>>>> Also, IIRC, Material has different components than Flex did so
> we'd
> > >>>> have
> > >>>>>> to invent some new looks anyway. So having a TextInput with
> borders
> > >>>> all
> > >>>>>> around would just be our flavor of Material.
> > >>>>>>
> > >>>>>
> > >>>>> That's what I point above. We must to *freeze* the list of
> components
> > >>>> at
> > >>>>> some time work over a concrete set
> > >>>>> We can then plan in the future include a new component in the
> > official
> > >>>>> set,
> > >>>>> and that will need to work on the themes we already
> > >>>>> have to include the new one.
> > >>>>>
> > >>>>>
> > >>>>>>
> > >>>>>> Regarding colors, it looks like Material is parameterized around a
> > >>>>>> couple
> > >>>>>> of colors. So if we did our skins to work against parameterized
> > >>>> colors
> > >>>>>> then would it really matter what color we choose?
> > >>>>>>
> > >>>>>
> > >>>>> That's completly right. I could make wireframe based on two or
> three
> > >>>>> colors
> > >>>>> and as you change it in CSS all controls should tint
> > >>>>> consistently.
> > >>>>>
> > >>>>>
> > >>>>>>
> > >>>>>> Regarding Basic components, right now Checkbox is a <label><input
> > >>>>>> type="check"/>caption</label>. AIUI, you cannot style the <input>
> > on
> > >>>>>> many
> > >>>>>> browsers, so I think we have to have a different set of elements
> in
> > a
> > >>>>>> checkbox. It looks like Bootstrap uses:
> > >>>>>>
> > >>>>>> <label><input type="check"/><span />Caption</label>
> > >>>>>>
> > >>>>>> Where the span uses a special symbol font with checked and
> unchecked
> > >>>>>> boxes.
> > >>>>>>
> > >>>>>
> > >>>>> That's what we need to figure. Should we make themes available in
> > >>>> Basic?
> > >>>>> if
> > >>>>> so, has basic the right implementation?
> > >>>>> If not, and if we don't want to change the actual very basic
> > >>>>> implementation, we need to put some "skin" implementation
> > >>>>> that at least in JS implementation I figure that will change one
> face
> > >>>> (the
> > >>>>> actual basic) with the theme face.
> > >>>>>
> > >>>>> I'm thinking loud, since this is something we should explorer all
> > >>>> together
> > >>>>> mixing the best ideas of people involved
> > >>>>>
> > >>>>> Thanks
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Alex
> > >>>>>>
> > >>>>>> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos
> > >>>>>> Rovira"
> > >>>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> > >> wrote:
> > >>>>>>
> > >>>>>>> Hi,
> > >>>>>>>
> > >>>>>>> I want to expose my initial work (very very initial) on two
> styles
> > >>>> for
> > >>>>>>> Royale
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Wireframe:
> > >>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> > >>>>>> https%3A%2F%2Fsnag.gy%2
> > >>>>>>> FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> > >>>>>> 0f48%7Cfa7b1b5a7
> > >>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> > >>>>>> sdata=%2Fk8YQxC5bDOaC
> > >>>>>>> D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
> > >>>>>>>
> > >>>>>>> (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://na01.safelinks.protection.outlook.com/?url=
> > >>>>>> https%3A%2F%2Fsnag.gy%2
> > >>>>>>> FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> > >>>>>> 0f48%7Cfa7b1b5a7
> > >>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> > >>>>>> sdata=kxYE7ylOsXPUEeE
> > >>>>>>> r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
> > >>>>>>>
> > >>>>>>> (*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 <
> carlosrovira@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 <ha...@gmail.com>:
> > >>>>>>>>
> > >>>>>>>>> BTW, the kind of thing we should be striving for in theme-able
> > >>>>>>>>> components
> > >>>>>>>>> is something like this:
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> > >>>>>> https%3A%2F%2Fvcalend
> > >>>>>>>>> ar.netlify.com%2F&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> > >>>>>> 0f48%7Cf
> > >>>>>>
> > >>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> > 7C636452649612378558&sdata=
> > >>>>>> b3VtV
> > >>>>>>>>> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
> > >>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> > >>>>>> https%3A%2F%2Fvcalen
> > >>>>>>>>> dar.netlify.com%2F&data=02%7C01%7C%
> > 7C203485b5b9c744aed92608d52250
> > >>>>>> 0f48%7C
> > >>>>>>
> > >>>>>>> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> > 7C636452649612378558&sdata=
> > >>>>>> b3Vt
> > >>>>>>>>> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
> > >>>>>>>>>
> > >>>>>>>>>> On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
> > >>>>>> https%3A%2F%2Fpaste.a
> > >>>>>>>>> pache.org%2FcOBC&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> > >>>>>> 0f48%7Cfa
> > >>>>>>>>> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> > >>>>>> sdata=bRWKxm
> > >>>>>>>>> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
> > >>>>>>
> > >>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> > >>>> https%3A%2F%2Fpast
> > >>>>>>>>> e
> > >>>>>> .
> > >>>>>>>>> apache.org%2FcOBC&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> > >>>>>> 0f48%7Cf
> > >>>>>>
> > >>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> > 7C636452649612378558&sdata=
> > >>>>>> bRWKx
> > >>>>>>>>> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
> > >>>>>>>>>>
> > >>>>>>>>>> (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
> > >>>>>> <carlosrovira@apache.org
> > >>>>>>>>> <ma...@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.lists@gmail.com
> > >>>> <mailto:
> > >>>>>>>>> harbs.lists@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
> > >>>>>> <aharui@adobe.com.INVALID
> > >>>>>>>>> <ma...@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
> > >>>>>>>>
> > >>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> > >>>>>> http%3A%2F%2Fabout.me%
> > >>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> > >>>>>> 0f48%7Cfa7b1
> > >>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> > >>>>>> sdata=C7a72gwfH2
> > >>>>>>>> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Carlos Rovira
> > >>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> > >>>>>> http%3A%2F%2Fabout.me%2
> > >>>>>>> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> > >>>>>> 0f48%7Cfa7b1b5
> > >>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> > >>>>>> sdata=C7a72gwfH264w
> > >>>>>>> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>>
> > >>>>> <https://na01.safelinks.protection.outlook.com/?url=
> > >>>> http%3A%2F%2Fwww.codeo
> > >>>>> scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
> > >>>> d8cf%7Cfa7b1b5a7b
> > >>>>> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> > >>>> sdata=Hm%2B6WIcqQTOHs0
> > >>>>> UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> > >>>> d8cf%7Cfa7b1b5a7b3
> > >>>>> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> > >>>> sdata=Hm%2B6WIcqQTOHs0U
> > >>>>> ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> > >>>> d8cf%7Cfa7b1b5a
> > >>>>> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> > >>>> sdata=b%2FFMr1Ajit94
> > >>>>> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> Carlos Rovira
> > >>> https://na01.safelinks.protection.outlook.com/?url=
> > >> http%3A%2F%2Fabout.me%2
> > >>> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
> > >> 82e0%7Cfa7b1b5
> > >>> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
> > >> sdata=wYPMWW1wpTbtm
> > >>> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
> > >>
> > >>
> > >
> > >
> > > --
> > >
> > > <http://www.codeoscopic.com>
> > >
> > > Carlos Rovira
> > >
> > > Director General
> > >
> > > M: +34 607 22 60 05
> > >
> > > http://www.codeoscopic.com
> > >
> > >
> > > Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
> > >
> > >
> > > 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.
> >
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
I creates the element structure that Topcoat expects and adds APIs to set the correct CSS class names.
From what I recall, the structure for style-able checkboxes is pretty standard across css frameworks, but it probably pays to do some research on the topic before making assumptions.
If someone wants to re-work what I did to be more generalized and/or move it to a theming package, I will update my app to work with that…
Harbs
> On Nov 6, 2017, at 7:36 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I'm not quite sure how CSSCheckbox works. It could be that there is a Div
> where others have used a Span to hide the <input> and display something
> else instead, otherwise I would think you couldn't control the visuals of
> the check via CSS. These are the kinds of things we have to decide on.
Re: Working on UI Controls styling
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Piotr,
Remember that any top-level component is a composition of beads. We
should be able to create most top-level components by take UIBase and
adding beads to the strand.
So, if we find when implementing skinning/themeing that there are
re-usable pieces from Basic great, but what is most important is defining
the HTMLElement topologies. Really, Carlos/Angelo can do most of this
experimenting in pure HTML and CSS. I believe the first test is to define
a set of HTMLElements for each component and two or more CSS files and
show that you can modify every pixel with the CSS files and the
component's mouse and keyboard functionality is "correct" (that you can
click on the label or the box of a checkbox, that you can tab through a
set of radio buttons, etc.
IMO, this is stage 1: For a given set of HTMLElements, you can use CSS to
affect every pixel. Later, we can try to solve issues where the
limitations of CSS (and background-image) somehow doesn't meet our needs.
My 2 cents,
-Alex
On 11/5/17, 10:30 PM, "Piotr Zarzycki" <pi...@gmail.com> wrote:
>Alex,
>
>You are saying about simple case where we can extend UIBase for create new
>Button, but what about more sophisticated for example Panel ? Do you want
>us to create from scratch again all of that instead use Basic ? This is
>how
>I see reading your last email or maybe I missing something.
>
>Thanks, Piotr
>
>
>2017-11-06 6:36 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> I'm not quite sure what the meaning of "based on Basic" means. I think
>> someone is about to go and move a bunch of classes around to better
>> organize our packages and classes, and I think that IUIBase and maybe
>> UIBase should end up back in Core (where it was before Harbs temporarily
>> wrapped the Sprites for SWF output).
>>
>> So, if you are saying that SkinnableCheckbox will extend UIBase, that
>> makes sense. Should it extend Basic Checkbox? Possibly, if the
>>override
>> of createElement is straightforward.
>>
>> IMO, we shouldn't worry about Express or Basic. Just figure out what
>> HTMLElements you need in what positions and sizes to get the visual
>> changes you want. Then once we get it looking right, we can look at how
>> it compares with the other components and decide if we want to
>>restructure
>> anything.
>>
>> I'm not quite sure how CSSCheckbox works. It could be that there is a
>>Div
>> where others have used a Span to hide the <input> and display something
>> else instead, otherwise I would think you couldn't control the visuals
>>of
>> the check via CSS. These are the kinds of things we have to decide on.
>>
>> It is fine to start with some list of components in order to bound the
>> work, but IMO, it is also important to have an understanding of the
>>design
>> principles so that other designers will have a better idea of how to add
>> some other component that isn't on the list someday. I guarantee
>>someone
>> will come up with something new and Carlos/Angelo won't have time to
>> design a default skin for it.
>>
>> When writing framework, I like to stop and consider whether any line of
>> code is going to lock someone into something they might not want.
>>That's
>> why we have beads and multiple component sets. We want everything to be
>> replaceable. I don't know if there is an analogy for Skins/Themes, but
>>I
>> think it would be to stop and consider if the HTMLElement topology 1)
>> allows every pixel to be changed, and 2) if any two HTMLElements
>>overlap,
>> if there are too many limitations imposed by that overlap. If someone
>> wants to Skin with Android, IOS, or even Windows 2.x or an old
>> green-screen terminal, can they?
>>
>> My 2 cents,
>> -Alex
>>
>> On 11/5/17, 1:29 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> >Basic is going to be the base for anything. I don’t think Express is
>> >going to be very helpful. It should probably just be built out from
>>Basic
>> >components and/or copied from Basic.
>> >
>> >For an example of a styleable component, take a look at CSSCheckbox. I
>> >think that’s a good example of a styleable component. You might be able
>> >to do better, but I had a need for a checkbox which could be styled
>>using
>> >CSS and I created that class. I wanted to use a topcoat-styled
>>checkbox,
>> >which I was able to do using that class like this:
>> >
>> >package com.printui.view.components
>> >{
>> > import org.apache.flex.html.CSSCheckBox;
>> >
>> > public class CheckBox extends CSSCheckBox
>> > {
>> > public function CheckBox(){
>> > super();
>> > className="topcoat-checkbox";
>> > checkClassName="topcoat-checkbox__checkmark";
>> > }
>> > }
>> >}
>> >
>> >I then used that class in my app.
>> >
>> >There might be more elegant ways to specify classes, but this is how I
>> >did it…
>> >
>> >Here’s what it looks like in the app:
>> >https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.evern
>> >ote.com%2Fl%2FAI_1QITiAqVCe5rgWuBlfIr3HjEQic1Dh
>> pQB%2Fimage.png&data=02%7C0
>> >1%7C%7Cdfc2dc02415b446e995108d524945950%7Cfa7b1b5a7b34438794aed2c178de
>> cee1
>> >%7C0%7C0%7C636455141932227764&sdata=CCCp3fmlnGFtImPTsEf9JsIXJdkcQV
>> g3zbkIch
>> >2buoc%3D&reserved=0
>> >
>> >Hope this is useful,
>> >Harbs
>> >
>> >> On Nov 5, 2017, at 11:01 PM, Piotr Zarzycki
>><pi...@gmail.com>
>> >>wrote:
>> >>
>> >> I was thinking about that and new component set is the approach
>>which we
>> >> should try, but we need to base on something. My first thoughts was
>> >>that it
>> >> should be Basic, cause I bet that once we start create style for each
>> >> component we will end up with some issue or we would like to create
>>some
>> >> additional features to those controls in order to make that theme
>> >>happen.
>> >> It leads my thought then farther let's say that we will start work in
>> >> following way:
>> >> 1) Basic is our base
>> >> 2) Carlos will prepare some appearance for component
>> >> 3) We are starting to work on that, but it's end up that our
>>component
>> >>need
>> >> some additional feature, which is do not suits for Basic
>> >> 4) We are adds that feature to Express and use in that place Express
>> >> component.
>> >>
>> >> It ends up that our component theme will be mix of Express and Basic
>> >>
>> >> Second approach is - Forget about Express, use Basic only and add to
>> >>Theme
>> >> set features if needed. Express will be always separate set, FAT and
>>it
>> >> will be responsibility for user if he would like to style it. - If
>>our
>> >> implementation will be in Theme enough robust, user should be able to
>> >>use
>> >> in his application Express with some styles from Theme set.
>> >>
>> >> Thoughts ?
>> >> Piotr
>> >>
>> >>
>> >> 2017-11-05 11:21 GMT+01:00 Harbs <ha...@gmail.com>:
>> >>
>> >>> I would suggest starting a new component set with a fresh slate
>>called
>> >>> Themed (or something like that).
>> >>>
>> >>> The Themed component set should give priority to style-ablitity and
>> >>>ease
>> >>> of use over just about every other consideration. I think of
>>Express as
>> >>> more of a middle-of the road approach to make things easier. A
>>Themed
>> >>>set
>> >>> would be more of a replacement for mx and spark.
>> >>>
>> >>> Yes. Definitely make a clear list of supported components. It’s
>> >>>probably
>> >>> more important to have quality of components rather than quantity. A
>> >>>few
>> >>> well constructed components is better than a lot of half-baked ones.
>> >>>More
>> >>> components could always be added.
>> >>>
>> >>> I’m very glad to hear that Angelo is working with you. That’s great
>> >>>news!
>> >>>
>> >>> Harbs
>> >>>
>> >>>> On Nov 5, 2017, at 12:12 PM, Carlos Rovira <
>> >>> carlos.rovira@codeoscopic.com> wrote:
>> >>>>
>> >>>> ok Alex,
>> >>>>
>> >>>> so if I understand correctly, you mean that we create our own set,
>> >>>>with
>> >>>> Basic as base right?
>> >>>> but we should go with Express? It's great that we could create many
>> >>>>sets
>> >>> in
>> >>>> Royale, and I think the Basic use
>> >>>> you commented is very licit and didn't think about that. But we
>>must
>> >>> think
>> >>>> in some *main* set, maybe is Express
>> >>>> and that I want to focus this effort for that concrete set.
>> >>>>
>> >>>> I mean, one important thing here is that we all agree in support a
>> >>> concrete
>> >>>> list of UI controls and components
>> >>>> I plan to make a discuss thread for this, since the theme feature
>>will
>> >>>> affect only to that controls, and if we want to include a new one
>> >>>> we should vote to include it, since it implies to include in
>>design,
>> >>>> implementation and all themes that we want to support.
>> >>>>
>> >>>> I think I'll create a discuss thread with this an other things we
>> >>>>talked
>> >>>> about since this is a huge effort and is important for all the
>> >>>> people that will be involved to work around things discussed, voted
>> >>>>and
>> >>>> approved by all.
>> >>>> We need to be synced here or we'll end working too much for
>>somehitng
>> >>> that
>> >>>> does not get to be useful in the end. I want to ensure this before
>> >>>> to start investing a huge amount of time.
>> >>>>
>> >>>> As well I was contacted by Angelo and talk about all this. He's
>>very
>> >>>> passionate as well on this and we'll seeing how we can combine our
>> >>> efforts
>> >>>> and if someone
>> >>>> more wants to join us.
>> >>>>
>> >>>> I'll be writing the discussion thread in order to plan the effort
>>in
>> >>> short.
>> >>>> Stay tuned :)
>> >>>>
>> >>>> 2017-11-05 8:29 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>> >>>>
>> >>>>> Hi Carlos,
>> >>>>>
>> >>>>> I think we're pretty much in agreement. Regarding Basic, for me,
>>I
>> >>>>>have
>> >>>>> created plenty of web pages with non-styleable checkboxes. I
>>don't
>> >>>>>care
>> >>>>> that the checkbox looks different on different browsers. I just
>>want
>> >>> the
>> >>>>> smallest simplest output. Just like taking an HTML editor and
>> >>>>>slapping
>> >>> in
>> >>>>> a few tags and calling it done. Would that be production? Sure,
>>if
>> >>>>>I'm
>> >>>>> just want someone to check a box before enabling a download
>>button.
>> >>> IOW,
>> >>>>> it would be for internal customers only.
>> >>>>>
>> >>>>> So, IMO, a Skinnable/Themeable component set would be something
>> >>>>>else. I
>> >>>>> think you will need that extra Span for a Checkbox. IMO, we
>>should
>> >>>>>just
>> >>>>> go and build these new components. And when we get it mostly
>> >>>>>working,
>> >>> we
>> >>>>> can compare against Basic and see if we want to parameterize the
>> >>>>>views
>> >>> in
>> >>>>> the low-level Basic components or not.
>> >>>>>
>> >>>>> My 2 cents,
>> >>>>> -Alex
>> >>>>>
>> >>>>> On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com on behalf of Carlos
>> >>> Rovira"
>> >>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
>> wrote:
>> >>>>>
>> >>>>>> HI Alex,
>> >>>>>>
>> >>>>>>
>> >>>>>> 2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>> >>>>>>
>> >>>>>>> Hi Carlos,
>> >>>>>>>
>> >>>>>>> I skimmed through
>> >>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>> https%3A%2F%2Fmaterial
>> >>>>>>>
>> >>>>>>>.io%2Fguidelines%2F%23&data=02%7C01%7C%
>> 7Cbb03216ec0b84fcb6ab108d5239
>> >>>>>>>7
>> >>>>> 82e0
>> >>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >>>>> 7C636454056000808812&sdata=g5
>> >>>>>>> M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last
>> >>> night.
>> >>>>>>>
>> >>>>>>> My impression is that there were two parts to it. First was the
>> >>>>>>> environment/principles section which talked about physical
>>objects
>> >>>>>>>and
>> >>>>>>> light (and motion), and then there were choices of widgets. For
>> >>>>>>> example,
>> >>>>>>> I didn't see anything in the first part that said that a text
>>input
>> >>> had
>> >>>>>>> to
>> >>>>>>> be a single line and couldn't be a box.
>> >>>>>>>
>> >>>>>>
>> >>>>>> Material guidelines could be a great way to start, but trying to
>> >>>>>>give
>> >>>>>> something different.
>> >>>>>> I think that we need to get something that looks great while be
>> >>>>>>clearly
>> >>>>>> different to google material,
>> >>>>>> bootstrap, and others so people could see us as an alternative.
>>That
>> >>> could
>> >>>>>> make people copying us
>> >>>>>> or adopting the whole Apache Royale SDK that is what we want in
>>the
>> >>>>>>end
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>> That made me think that we could use our widget set and apply
>> >>>>>>>Material
>> >>>>>>> environment and principles to it. If we decide not to, I would
>> >>>>>>>think
>> >>>>>>> you
>> >>>>>>> would want to have some sort of similar environment/principles
>> >>> document
>> >>>>>>> which seems like a fair amount of work. I think we'd end up
>> >>>>>>>looking
>> >>>>>>> different because we have different widgets and maybe some
>> >>>>>>>different
>> >>>>>>> colors. I'm pretty sure that we don't want to be different so
>>much
>> >>> that
>> >>>>>>> we don't create things that folks want to use. The priority to
>>me
>> >>>>>>>is
>> >>>>>>> just
>> >>>>>>> to prove that you can alter every pixel in every widget we have
>>so
>> >>> that
>> >>>>>>> others can provide custom skins as well. So starting with
>>Material
>> >>>>>>> principles seems like it would save us time, we can get
>>something
>> >>>>>>> released, and can innovate more later.
>> >>>>>>>
>> >>>>>>
>> >>>>>> I think as you that we need a way to make the "presentation" of
>>each
>> >>>>>> component highly customizable.
>> >>>>>> And we need to be different in visualization (art, colors, ...)
>>but
>> >>> not in
>> >>>>>> usability that is what people
>> >>>>>> needs to be consistently
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>> Maybe a good question for our users is: How many of you used
>>the
>> >>>>>>> default
>> >>>>>>> Flex skins vs a whole new set of skins? If most folks
>>completely
>> >>>>>>> re-skinned to match their corporate branding, it matters less
>>what
>> >>>>>>>our
>> >>>>>>> default is, and more that we can allow folks to customize every
>> >>>>>>>pixel.
>> >>>>>>>
>> >>>>>>>
>> >>>>>> We need both: a skin that will be highly customizable and to
>>change
>> >>> skins
>> >>>>>> to look very very different.
>> >>>>>> People with lees money or time in their Apps will choose the
>>first.
>> >>> People
>> >>>>>> that has more resources will go with the second.
>> >>>>>> Apache Royale needs to support both
>> >>>>>>
>> >>>>>>
>> >>>>>>> The wireframe can be black and white, IMO. I was thinking that
>> >>> "vivid"
>> >>>>>>> would have parameterized colors.
>> >>>>>>>
>> >>>>>>>
>> >>>>>> I started to think that wireframe could end having lots of
>> >>> customization
>> >>>>>> controls. For example:
>> >>>>>>
>> >>>>>> -2-3 main colors as we talked , and the same MDL does
>> >>>>>> -possibilitiy to be solid colors, or gradients
>> >>>>>> -possibility to have backgrounds more or less opaque
>> >>>>>>
>> >>>>>> if we see a concrete component like button:
>> >>>>>>
>> >>>>>> - configurable corners, square to round corners
>> >>>>>> - more blocky (relief) or more flat
>> >>>>>> ...
>> >>>>>>
>> >>>>>> So wireframe could be a concrete configuration of the main theme
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> Since Bootstrap was mentioned, I want to point out that the
>> >>>>>>>Flat.swc
>> >>> is
>> >>>>>>> a
>> >>>>>>> rough approximation of the Flat theme which is a Bootstrap
>>theme.
>> >>>>>>>It
>> >>>>>>> is a
>> >>>>>>> rough approximation because I could not use the Flat CSS file
>> >>>>>>>directly
>> >>>>>>> since it contains much more advanced CSS than we currently
>>support
>> >>>>>>>on
>> >>>>>>> the
>> >>>>>>> SWF side. But it presumed that the Checkbox was a Label with a
>> >>>>>>>Span
>> >>>>>>> that
>> >>>>>>> hides in front of or behind the <input type="check" /> in order
>>to
>> >>> allow
>> >>>>>>> customizing every pixel. Looks like MDL uses the same Span
>>trick
>> >>>>>>>but
>> >>>>>>> maybe without a symbol font.
>> >>>>>>>
>> >>>>>>> Basic is, IMO, truly meant to be Basic. I think the Basic
>>Checkbox
>> >>>>>>> should
>> >>>>>>> not have that extra Span. But it looks to me that a
>> >>>>>>>SkinnableCheckbox
>> >>>>>>> can
>> >>>>>>> add that extra Span and you either give it the same class name
>>that
>> >>>>>>> BootStrap or MDL uses or create our own set of classnames and
>>the
>> >>>>>>>CSS
>> >>>>>>> that
>> >>>>>>> goes with it.
>> >>>>>>>
>> >>>>>>>
>> >>>>>> The problem with Basic could be that if is very very basic and
>>looks
>> >>> with
>> >>>>>> a
>> >>>>>> very basic look (as it is very poorly stylizable), I think
>> >>>>>> People will not use it at all, in this case, I'll don't
>>understand
>> >>>>>>the
>> >>>>>> goal
>> >>>>>> with basic. It's intend ended as a base
>> >>>>>> but to not use in production? For this reason is what I want to
>> >>>>>>know if
>> >>>>>> you
>> >>>>>> think this theme feature could be plugged in basic or not.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> Of course, I could be wrong. This is not my area of expertise
>>at
>> >>>>>>>all.
>> >>>>>>>
>> >>>>>>
>> >>>>>> Hi Alex, maybe UX is not your expertise area, but your help here
>>is
>> >>> very
>> >>>>>> needed since we can get to great ideas in this field, but
>> >>>>>> maybe don't know how to bring it to implementation in Apache
>> >>>>>>Royale. I
>> >>>>>> think that you, Peter, Harbs,... are needed in order to
>> >>>>>> make this happen in the pure arquitecture side or this feature.
>> >>>>>>
>> >>>>>> Thanks
>> >>>>>>
>> >>>>>> -Alex
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of
>>Carlos
>> >>>>>>> Rovira"
>> >>>>>>> <carlos.rovira@gmail.com on behalf of
>> >>>>>>>carlos.rovira@codeoscopic.com>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> Hi Alex,
>> >>>>>>>>
>> >>>>>>>> 2017-11-03 7:39 GMT+01:00 Alex Harui
>><ah...@adobe.com.invalid>:
>> >>>>>>>>
>> >>>>>>>>> Hi Carlos,
>> >>>>>>>>>
>> >>>>>>>>> Looks good to me. Thanks for doing this.
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Thanks :)
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> I'm not sure I understand all of the aspects of this effort.
>>My
>> >>>>>>> current
>> >>>>>>>>> understanding is that Google Material is under the Apache
>>License
>> >>> and
>> >>>>>>>>> thus
>> >>>>>>>>> we can use it if we want to. Am I correct that
>> >>>>>>>>>MaterialDesignLite
>> >>> is
>> >>>>>>>>> one
>> >>>>>>>>> implementation of Google Material and we could create our own
>> >>>>>>>>> implementation and it could be visually different?
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> We can implement our own material in Royale, but I'm afraid
>>that
>> >>> doing
>> >>>>>>>> that
>> >>>>>>>> will not make us
>> >>>>>>>> highlight our solution against the rest of competitors. Another
>> >>>>>>>>point
>> >>>>>>> is
>> >>>>>>>> something I said various times:
>> >>>>>>>> When I did MDL, I notice a huge problem: MDL has its own set of
>> >>>>>>>> components,
>> >>>>>>>> some are in all sets (Button)
>> >>>>>>>> but others not (Card), and they has it's own implementation,
>>what
>> >>> make
>> >>>>>>> it
>> >>>>>>>> almost impossible generalize
>> >>>>>>>> a theme. For this reason I always point that we need our own
>>set
>> >>>>>>>>and
>> >>>>>>> there
>> >>>>>>>> we can implement themes. But other
>> >>>>>>>> *externa* sets will never get this since they have its own
>> >>>>>>> implementation
>> >>>>>>>> and most important once you start to develop
>> >>>>>>>> with MDL you can't go back and change for other. So MDL is for
>>me
>> >>>>>>>> something
>> >>>>>>>> we have until our own set are robust and
>> >>>>>>>> highly configurable in both the things we can do and how can it
>> >>>>>>>>could
>> >>>>>>> be
>> >>>>>>>> represented, and switch between style should be
>> >>>>>>>> really easy to change the global look of an App without much
>> >>>>>>>>hassle.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Also, IIRC, Material has different components than Flex did so
>> >>>>>>>>>we'd
>> >>>>>>> have
>> >>>>>>>>> to invent some new looks anyway. So having a TextInput with
>> >>>>>>>>>borders
>> >>>>>>> all
>> >>>>>>>>> around would just be our flavor of Material.
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> That's what I point above. We must to *freeze* the list of
>> >>>>>>>>components
>> >>>>>>> at
>> >>>>>>>> some time work over a concrete set
>> >>>>>>>> We can then plan in the future include a new component in the
>> >>> official
>> >>>>>>>> set,
>> >>>>>>>> and that will need to work on the themes we already
>> >>>>>>>> have to include the new one.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Regarding colors, it looks like Material is parameterized
>>around
>> >>>>>>>>>a
>> >>>>>>>>> couple
>> >>>>>>>>> of colors. So if we did our skins to work against
>>parameterized
>> >>>>>>> colors
>> >>>>>>>>> then would it really matter what color we choose?
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> That's completly right. I could make wireframe based on two or
>> >>>>>>>>three
>> >>>>>>>> colors
>> >>>>>>>> and as you change it in CSS all controls should tint
>> >>>>>>>> consistently.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Regarding Basic components, right now Checkbox is a
>><label><input
>> >>>>>>>>> type="check"/>caption</label>. AIUI, you cannot style the
>> >>>>>>>>><input>
>> >>> on
>> >>>>>>>>> many
>> >>>>>>>>> browsers, so I think we have to have a different set of
>>elements
>> >>>>>>>>>in
>> >>> a
>> >>>>>>>>> checkbox. It looks like Bootstrap uses:
>> >>>>>>>>>
>> >>>>>>>>> <label><input type="check"/><span />Caption</label>
>> >>>>>>>>>
>> >>>>>>>>> Where the span uses a special symbol font with checked and
>> >>>>>>>>>unchecked
>> >>>>>>>>> boxes.
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> That's what we need to figure. Should we make themes available
>>in
>> >>>>>>> Basic?
>> >>>>>>>> if
>> >>>>>>>> so, has basic the right implementation?
>> >>>>>>>> If not, and if we don't want to change the actual very basic
>> >>>>>>>> implementation, we need to put some "skin" implementation
>> >>>>>>>> that at least in JS implementation I figure that will change
>>one
>> >>>>>>>>face
>> >>>>>>> (the
>> >>>>>>>> actual basic) with the theme face.
>> >>>>>>>>
>> >>>>>>>> I'm thinking loud, since this is something we should explorer
>>all
>> >>>>>>> together
>> >>>>>>>> mixing the best ideas of people involved
>> >>>>>>>>
>> >>>>>>>> Thanks
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Thanks,
>> >>>>>>>>> Alex
>> >>>>>>>>>
>> >>>>>>>>> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of
>> Carlos
>> >>>>>>>>> Rovira"
>> >>>>>>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
>> >>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Hi,
>> >>>>>>>>>>
>> >>>>>>>>>> I want to expose my initial work (very very initial) on two
>> >>>>>>>>>>styles
>> >>>>>>> for
>> >>>>>>>>>> Royale
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> Wireframe:
>> >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> https%3A%2F%2Fsnag.gy%2
>> >>>>>>>>>> FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >>>>>>>>> 0f48%7Cfa7b1b5a7
>> >>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >>>>>>>>> sdata=%2Fk8YQxC5bDOaC
>> >>>>>>>>>> D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
>> >>>>>>>>>>
>> >>>>>>>>>> (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://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> https%3A%2F%2Fsnag.gy%2
>> >>>>>>>>>> FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >>>>>>>>> 0f48%7Cfa7b1b5a7
>> >>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >>>>>>>>> sdata=kxYE7ylOsXPUEeE
>> >>>>>>>>>> r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
>> >>>>>>>>>>
>> >>>>>>>>>> (*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
>> >>>>>>>>>><carlosrovira@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 <ha...@gmail.com>:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> BTW, the kind of thing we should be striving for in
>>theme-able
>> >>>>>>>>>>>> components
>> >>>>>>>>>>>> is something like this:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> https%3A%2F%2Fvcalend
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>ar.netlify.com%2F&data=02%7C01%7C%
>> 7C203485b5b9c744aed92608d5225
>> >>>>>>>>>>>>0
>> >>>>>>>>> 0f48%7Cf
>> >>>>>>>>>
>> >>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >>> 7C636452649612378558&sdata=
>> >>>>>>>>> b3VtV
>> >>>>>>>>>>>> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
>> >>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> https%3A%2F%2Fvcalen
>> >>>>>>>>>>>> dar.netlify.com%2F&data=02%7C01%7C%
>> >>> 7C203485b5b9c744aed92608d52250
>> >>>>>>>>> 0f48%7C
>> >>>>>>>>>
>> >>>>>>>>>> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >>> 7C636452649612378558&sdata=
>> >>>>>>>>> b3Vt
>> >>>>>>>>>>>> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> https%3A%2F%2Fpaste.a
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>pache.org%2FcOBC&data=02%7C01%7C%
>> 7C203485b5b9c744aed92608d52250
>> >>>>>>>>> 0f48%7Cfa
>> >>>>>>>>>>>>
>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >>>>>>>>> sdata=bRWKxm
>> >>>>>>>>>>>> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
>> >>>>>>>>>
>> >>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>> https%3A%2F%2Fpast
>> >>>>>>>>>>>> e
>> >>>>>>>>> .
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>apache.org%2FcOBC&data=02%7C01%7C%
>> 7C203485b5b9c744aed92608d5225
>> >>>>>>>>>>>>0
>> >>>>>>>>> 0f48%7Cf
>> >>>>>>>>>
>> >>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >>> 7C636452649612378558&sdata=
>> >>>>>>>>> bRWKx
>> >>>>>>>>>>>> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> (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
>> >>>>>>>>> <carlosrovira@apache.org
>> >>>>>>>>>>>> <ma...@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.lists@gmail.com
>> >>>>>>> <mailto:
>> >>>>>>>>>>>> harbs.lists@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
>> >>>>>>>>> <aharui@adobe.com.INVALID
>> >>>>>>>>>>>> <ma...@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
>> >>>>>>>>>>>
>> >>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> http%3A%2F%2Fabout.me%
>> >>>>>>>>>>>
>>2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >>>>>>>>> 0f48%7Cfa7b1
>> >>>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >>>>>>>>> sdata=C7a72gwfH2
>> >>>>>>>>>>> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> --
>> >>>>>>>>>> Carlos Rovira
>> >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> http%3A%2F%2Fabout.me%2
>> >>>>>>>>>> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >>>>>>>>> 0f48%7Cfa7b1b5
>> >>>>>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >>>>>>>>> sdata=C7a72gwfH264w
>> >>>>>>>>>> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> --
>> >>>>>>>>
>> >>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>> http%3A%2F%2Fwww.codeo
>> >>>>>>>> scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
>> >>>>>>> d8cf%7Cfa7b1b5a7b
>> >>>>>>>> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>> >>>>>>> sdata=Hm%2B6WIcqQTOHs0
>> >>>>>>>> UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>> >>>>>>> d8cf%7Cfa7b1b5a7b3
>> >>>>>>>> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>> >>>>>>> sdata=Hm%2B6WIcqQTOHs0U
>> >>>>>>>> ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>> >>>>>>> d8cf%7Cfa7b1b5a
>> >>>>>>>> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>> >>>>>>> sdata=b%2FFMr1Ajit94
>> >>>>>>>> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Carlos Rovira
>> >>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>> http%3A%2F%2Fabout.me%2
>> >>>>>> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
>> >>>>> 82e0%7Cfa7b1b5
>> >>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
>> >>>>> sdata=wYPMWW1wpTbtm
>> >>>>>> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>>
>> >>>>
>> >>>><https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fwww.co
>> >>>>deoscopic.com&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
>> 5950%7Cfa7b
>> >>>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&
>> sdata=Cszs7Ln
>> >>>>LaXf9z%2F9Dv7l%2Ba%2BxZJM%2FxOMqs8FFbzO061Cc%3D&reserved=0>
>> >>>>
>> >>>> Carlos Rovira
>> >>>>
>> >>>> Director General
>> >>>>
>> >>>> M: +34 607 22 60 05
>> >>>>
>> >>>>
>> >>>>https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fwww.cod
>> >>>>eoscopic.com&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
>> 5950%7Cfa7b1
>> >>>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&
>> sdata=Cszs7LnL
>> >>>>aXf9z%2F9Dv7l%2Ba%2BxZJM%2FxOMqs8FFbzO061Cc%3D&reserved=0
>> >>>>
>> >>>>
>> >>>> Conocenos Avant2 en 1 minuto!
>> >>>><https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Favant
>> >>>>2.es%2F%23video&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
>> 5950%7Cfa
>> >>>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&
>> sdata=iMuUY
>> >>>>4Y%2FdwWAKXOXR%2BlHO9WIWPnOjdlrTCBjC0t2QUQ%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.
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >>
>> >> Piotr Zarzycki
>> >>
>> >> Patreon:
>> >>*https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.pat
>>
>>>>reon.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
>> 59
>> >>50%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636455141932227764&sdata=
>> >>3KxMJ3IlEbtNDN7WtgzdqILz8LlPRtjjL%2FP61nzmgrM%3D&reserved=0
>> >>
>> >><https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.pat
>>
>>>>reon.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
>> 59
>> >>50%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636455141932227764&sdata=
>> >>3KxMJ3IlEbtNDN7WtgzdqILz8LlPRtjjL%2FP61nzmgrM%3D&reserved=0>*
>> >
>>
>>
>
>
>--
>
>Piotr Zarzycki
>
>Patreon:
>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cb4af937efcb74c87b31108d524dfe682
>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455466425743017&sdata=Idk
>aCqJCK%2FuapcPqmgJOsWzOqhfIL3rjQOh%2F3NMIV9k%3D&reserved=0
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cb4af937efcb74c87b31108d524dfe682
>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455466425743017&sdata=Idk
>aCqJCK%2FuapcPqmgJOsWzOqhfIL3rjQOh%2F3NMIV9k%3D&reserved=0>*
Re: Working on UI Controls styling
Posted by Piotr Zarzycki <pi...@gmail.com>.
Alex,
You are saying about simple case where we can extend UIBase for create new
Button, but what about more sophisticated for example Panel ? Do you want
us to create from scratch again all of that instead use Basic ? This is how
I see reading your last email or maybe I missing something.
Thanks, Piotr
2017-11-06 6:36 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> I'm not quite sure what the meaning of "based on Basic" means. I think
> someone is about to go and move a bunch of classes around to better
> organize our packages and classes, and I think that IUIBase and maybe
> UIBase should end up back in Core (where it was before Harbs temporarily
> wrapped the Sprites for SWF output).
>
> So, if you are saying that SkinnableCheckbox will extend UIBase, that
> makes sense. Should it extend Basic Checkbox? Possibly, if the override
> of createElement is straightforward.
>
> IMO, we shouldn't worry about Express or Basic. Just figure out what
> HTMLElements you need in what positions and sizes to get the visual
> changes you want. Then once we get it looking right, we can look at how
> it compares with the other components and decide if we want to restructure
> anything.
>
> I'm not quite sure how CSSCheckbox works. It could be that there is a Div
> where others have used a Span to hide the <input> and display something
> else instead, otherwise I would think you couldn't control the visuals of
> the check via CSS. These are the kinds of things we have to decide on.
>
> It is fine to start with some list of components in order to bound the
> work, but IMO, it is also important to have an understanding of the design
> principles so that other designers will have a better idea of how to add
> some other component that isn't on the list someday. I guarantee someone
> will come up with something new and Carlos/Angelo won't have time to
> design a default skin for it.
>
> When writing framework, I like to stop and consider whether any line of
> code is going to lock someone into something they might not want. That's
> why we have beads and multiple component sets. We want everything to be
> replaceable. I don't know if there is an analogy for Skins/Themes, but I
> think it would be to stop and consider if the HTMLElement topology 1)
> allows every pixel to be changed, and 2) if any two HTMLElements overlap,
> if there are too many limitations imposed by that overlap. If someone
> wants to Skin with Android, IOS, or even Windows 2.x or an old
> green-screen terminal, can they?
>
> My 2 cents,
> -Alex
>
> On 11/5/17, 1:29 PM, "Harbs" <ha...@gmail.com> wrote:
>
> >Basic is going to be the base for anything. I don’t think Express is
> >going to be very helpful. It should probably just be built out from Basic
> >components and/or copied from Basic.
> >
> >For an example of a styleable component, take a look at CSSCheckbox. I
> >think that’s a good example of a styleable component. You might be able
> >to do better, but I had a need for a checkbox which could be styled using
> >CSS and I created that class. I wanted to use a topcoat-styled checkbox,
> >which I was able to do using that class like this:
> >
> >package com.printui.view.components
> >{
> > import org.apache.flex.html.CSSCheckBox;
> >
> > public class CheckBox extends CSSCheckBox
> > {
> > public function CheckBox(){
> > super();
> > className="topcoat-checkbox";
> > checkClassName="topcoat-checkbox__checkmark";
> > }
> > }
> >}
> >
> >I then used that class in my app.
> >
> >There might be more elegant ways to specify classes, but this is how I
> >did it…
> >
> >Here’s what it looks like in the app:
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.evern
> >ote.com%2Fl%2FAI_1QITiAqVCe5rgWuBlfIr3HjEQic1Dh
> pQB%2Fimage.png&data=02%7C0
> >1%7C%7Cdfc2dc02415b446e995108d524945950%7Cfa7b1b5a7b34438794aed2c178de
> cee1
> >%7C0%7C0%7C636455141932227764&sdata=CCCp3fmlnGFtImPTsEf9JsIXJdkcQV
> g3zbkIch
> >2buoc%3D&reserved=0
> >
> >Hope this is useful,
> >Harbs
> >
> >> On Nov 5, 2017, at 11:01 PM, Piotr Zarzycki <pi...@gmail.com>
> >>wrote:
> >>
> >> I was thinking about that and new component set is the approach which we
> >> should try, but we need to base on something. My first thoughts was
> >>that it
> >> should be Basic, cause I bet that once we start create style for each
> >> component we will end up with some issue or we would like to create some
> >> additional features to those controls in order to make that theme
> >>happen.
> >> It leads my thought then farther let's say that we will start work in
> >> following way:
> >> 1) Basic is our base
> >> 2) Carlos will prepare some appearance for component
> >> 3) We are starting to work on that, but it's end up that our component
> >>need
> >> some additional feature, which is do not suits for Basic
> >> 4) We are adds that feature to Express and use in that place Express
> >> component.
> >>
> >> It ends up that our component theme will be mix of Express and Basic
> >>
> >> Second approach is - Forget about Express, use Basic only and add to
> >>Theme
> >> set features if needed. Express will be always separate set, FAT and it
> >> will be responsibility for user if he would like to style it. - If our
> >> implementation will be in Theme enough robust, user should be able to
> >>use
> >> in his application Express with some styles from Theme set.
> >>
> >> Thoughts ?
> >> Piotr
> >>
> >>
> >> 2017-11-05 11:21 GMT+01:00 Harbs <ha...@gmail.com>:
> >>
> >>> I would suggest starting a new component set with a fresh slate called
> >>> Themed (or something like that).
> >>>
> >>> The Themed component set should give priority to style-ablitity and
> >>>ease
> >>> of use over just about every other consideration. I think of Express as
> >>> more of a middle-of the road approach to make things easier. A Themed
> >>>set
> >>> would be more of a replacement for mx and spark.
> >>>
> >>> Yes. Definitely make a clear list of supported components. It’s
> >>>probably
> >>> more important to have quality of components rather than quantity. A
> >>>few
> >>> well constructed components is better than a lot of half-baked ones.
> >>>More
> >>> components could always be added.
> >>>
> >>> I’m very glad to hear that Angelo is working with you. That’s great
> >>>news!
> >>>
> >>> Harbs
> >>>
> >>>> On Nov 5, 2017, at 12:12 PM, Carlos Rovira <
> >>> carlos.rovira@codeoscopic.com> wrote:
> >>>>
> >>>> ok Alex,
> >>>>
> >>>> so if I understand correctly, you mean that we create our own set,
> >>>>with
> >>>> Basic as base right?
> >>>> but we should go with Express? It's great that we could create many
> >>>>sets
> >>> in
> >>>> Royale, and I think the Basic use
> >>>> you commented is very licit and didn't think about that. But we must
> >>> think
> >>>> in some *main* set, maybe is Express
> >>>> and that I want to focus this effort for that concrete set.
> >>>>
> >>>> I mean, one important thing here is that we all agree in support a
> >>> concrete
> >>>> list of UI controls and components
> >>>> I plan to make a discuss thread for this, since the theme feature will
> >>>> affect only to that controls, and if we want to include a new one
> >>>> we should vote to include it, since it implies to include in design,
> >>>> implementation and all themes that we want to support.
> >>>>
> >>>> I think I'll create a discuss thread with this an other things we
> >>>>talked
> >>>> about since this is a huge effort and is important for all the
> >>>> people that will be involved to work around things discussed, voted
> >>>>and
> >>>> approved by all.
> >>>> We need to be synced here or we'll end working too much for somehitng
> >>> that
> >>>> does not get to be useful in the end. I want to ensure this before
> >>>> to start investing a huge amount of time.
> >>>>
> >>>> As well I was contacted by Angelo and talk about all this. He's very
> >>>> passionate as well on this and we'll seeing how we can combine our
> >>> efforts
> >>>> and if someone
> >>>> more wants to join us.
> >>>>
> >>>> I'll be writing the discussion thread in order to plan the effort in
> >>> short.
> >>>> Stay tuned :)
> >>>>
> >>>> 2017-11-05 8:29 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >>>>
> >>>>> Hi Carlos,
> >>>>>
> >>>>> I think we're pretty much in agreement. Regarding Basic, for me, I
> >>>>>have
> >>>>> created plenty of web pages with non-styleable checkboxes. I don't
> >>>>>care
> >>>>> that the checkbox looks different on different browsers. I just want
> >>> the
> >>>>> smallest simplest output. Just like taking an HTML editor and
> >>>>>slapping
> >>> in
> >>>>> a few tags and calling it done. Would that be production? Sure, if
> >>>>>I'm
> >>>>> just want someone to check a box before enabling a download button.
> >>> IOW,
> >>>>> it would be for internal customers only.
> >>>>>
> >>>>> So, IMO, a Skinnable/Themeable component set would be something
> >>>>>else. I
> >>>>> think you will need that extra Span for a Checkbox. IMO, we should
> >>>>>just
> >>>>> go and build these new components. And when we get it mostly
> >>>>>working,
> >>> we
> >>>>> can compare against Basic and see if we want to parameterize the
> >>>>>views
> >>> in
> >>>>> the low-level Basic components or not.
> >>>>>
> >>>>> My 2 cents,
> >>>>> -Alex
> >>>>>
> >>>>> On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com on behalf of Carlos
> >>> Rovira"
> >>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> wrote:
> >>>>>
> >>>>>> HI Alex,
> >>>>>>
> >>>>>>
> >>>>>> 2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >>>>>>
> >>>>>>> Hi Carlos,
> >>>>>>>
> >>>>>>> I skimmed through
> >>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>> https%3A%2F%2Fmaterial
> >>>>>>>
> >>>>>>>.io%2Fguidelines%2F%23&data=02%7C01%7C%
> 7Cbb03216ec0b84fcb6ab108d5239
> >>>>>>>7
> >>>>> 82e0
> >>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>>>> 7C636454056000808812&sdata=g5
> >>>>>>> M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last
> >>> night.
> >>>>>>>
> >>>>>>> My impression is that there were two parts to it. First was the
> >>>>>>> environment/principles section which talked about physical objects
> >>>>>>>and
> >>>>>>> light (and motion), and then there were choices of widgets. For
> >>>>>>> example,
> >>>>>>> I didn't see anything in the first part that said that a text input
> >>> had
> >>>>>>> to
> >>>>>>> be a single line and couldn't be a box.
> >>>>>>>
> >>>>>>
> >>>>>> Material guidelines could be a great way to start, but trying to
> >>>>>>give
> >>>>>> something different.
> >>>>>> I think that we need to get something that looks great while be
> >>>>>>clearly
> >>>>>> different to google material,
> >>>>>> bootstrap, and others so people could see us as an alternative. That
> >>> could
> >>>>>> make people copying us
> >>>>>> or adopting the whole Apache Royale SDK that is what we want in the
> >>>>>>end
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> That made me think that we could use our widget set and apply
> >>>>>>>Material
> >>>>>>> environment and principles to it. If we decide not to, I would
> >>>>>>>think
> >>>>>>> you
> >>>>>>> would want to have some sort of similar environment/principles
> >>> document
> >>>>>>> which seems like a fair amount of work. I think we'd end up
> >>>>>>>looking
> >>>>>>> different because we have different widgets and maybe some
> >>>>>>>different
> >>>>>>> colors. I'm pretty sure that we don't want to be different so much
> >>> that
> >>>>>>> we don't create things that folks want to use. The priority to me
> >>>>>>>is
> >>>>>>> just
> >>>>>>> to prove that you can alter every pixel in every widget we have so
> >>> that
> >>>>>>> others can provide custom skins as well. So starting with Material
> >>>>>>> principles seems like it would save us time, we can get something
> >>>>>>> released, and can innovate more later.
> >>>>>>>
> >>>>>>
> >>>>>> I think as you that we need a way to make the "presentation" of each
> >>>>>> component highly customizable.
> >>>>>> And we need to be different in visualization (art, colors, ...) but
> >>> not in
> >>>>>> usability that is what people
> >>>>>> needs to be consistently
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Maybe a good question for our users is: How many of you used the
> >>>>>>> default
> >>>>>>> Flex skins vs a whole new set of skins? If most folks completely
> >>>>>>> re-skinned to match their corporate branding, it matters less what
> >>>>>>>our
> >>>>>>> default is, and more that we can allow folks to customize every
> >>>>>>>pixel.
> >>>>>>>
> >>>>>>>
> >>>>>> We need both: a skin that will be highly customizable and to change
> >>> skins
> >>>>>> to look very very different.
> >>>>>> People with lees money or time in their Apps will choose the first.
> >>> People
> >>>>>> that has more resources will go with the second.
> >>>>>> Apache Royale needs to support both
> >>>>>>
> >>>>>>
> >>>>>>> The wireframe can be black and white, IMO. I was thinking that
> >>> "vivid"
> >>>>>>> would have parameterized colors.
> >>>>>>>
> >>>>>>>
> >>>>>> I started to think that wireframe could end having lots of
> >>> customization
> >>>>>> controls. For example:
> >>>>>>
> >>>>>> -2-3 main colors as we talked , and the same MDL does
> >>>>>> -possibilitiy to be solid colors, or gradients
> >>>>>> -possibility to have backgrounds more or less opaque
> >>>>>>
> >>>>>> if we see a concrete component like button:
> >>>>>>
> >>>>>> - configurable corners, square to round corners
> >>>>>> - more blocky (relief) or more flat
> >>>>>> ...
> >>>>>>
> >>>>>> So wireframe could be a concrete configuration of the main theme
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Since Bootstrap was mentioned, I want to point out that the
> >>>>>>>Flat.swc
> >>> is
> >>>>>>> a
> >>>>>>> rough approximation of the Flat theme which is a Bootstrap theme.
> >>>>>>>It
> >>>>>>> is a
> >>>>>>> rough approximation because I could not use the Flat CSS file
> >>>>>>>directly
> >>>>>>> since it contains much more advanced CSS than we currently support
> >>>>>>>on
> >>>>>>> the
> >>>>>>> SWF side. But it presumed that the Checkbox was a Label with a
> >>>>>>>Span
> >>>>>>> that
> >>>>>>> hides in front of or behind the <input type="check" /> in order to
> >>> allow
> >>>>>>> customizing every pixel. Looks like MDL uses the same Span trick
> >>>>>>>but
> >>>>>>> maybe without a symbol font.
> >>>>>>>
> >>>>>>> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
> >>>>>>> should
> >>>>>>> not have that extra Span. But it looks to me that a
> >>>>>>>SkinnableCheckbox
> >>>>>>> can
> >>>>>>> add that extra Span and you either give it the same class name that
> >>>>>>> BootStrap or MDL uses or create our own set of classnames and the
> >>>>>>>CSS
> >>>>>>> that
> >>>>>>> goes with it.
> >>>>>>>
> >>>>>>>
> >>>>>> The problem with Basic could be that if is very very basic and looks
> >>> with
> >>>>>> a
> >>>>>> very basic look (as it is very poorly stylizable), I think
> >>>>>> People will not use it at all, in this case, I'll don't understand
> >>>>>>the
> >>>>>> goal
> >>>>>> with basic. It's intend ended as a base
> >>>>>> but to not use in production? For this reason is what I want to
> >>>>>>know if
> >>>>>> you
> >>>>>> think this theme feature could be plugged in basic or not.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Of course, I could be wrong. This is not my area of expertise at
> >>>>>>>all.
> >>>>>>>
> >>>>>>
> >>>>>> Hi Alex, maybe UX is not your expertise area, but your help here is
> >>> very
> >>>>>> needed since we can get to great ideas in this field, but
> >>>>>> maybe don't know how to bring it to implementation in Apache
> >>>>>>Royale. I
> >>>>>> think that you, Peter, Harbs,... are needed in order to
> >>>>>> make this happen in the pure arquitecture side or this feature.
> >>>>>>
> >>>>>> Thanks
> >>>>>>
> >>>>>> -Alex
> >>>>>>>
> >>>>>>>
> >>>>>>> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
> >>>>>>> Rovira"
> >>>>>>> <carlos.rovira@gmail.com on behalf of
> >>>>>>>carlos.rovira@codeoscopic.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi Alex,
> >>>>>>>>
> >>>>>>>> 2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >>>>>>>>
> >>>>>>>>> Hi Carlos,
> >>>>>>>>>
> >>>>>>>>> Looks good to me. Thanks for doing this.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks :)
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I'm not sure I understand all of the aspects of this effort. My
> >>>>>>> current
> >>>>>>>>> understanding is that Google Material is under the Apache License
> >>> and
> >>>>>>>>> thus
> >>>>>>>>> we can use it if we want to. Am I correct that
> >>>>>>>>>MaterialDesignLite
> >>> is
> >>>>>>>>> one
> >>>>>>>>> implementation of Google Material and we could create our own
> >>>>>>>>> implementation and it could be visually different?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> We can implement our own material in Royale, but I'm afraid that
> >>> doing
> >>>>>>>> that
> >>>>>>>> will not make us
> >>>>>>>> highlight our solution against the rest of competitors. Another
> >>>>>>>>point
> >>>>>>> is
> >>>>>>>> something I said various times:
> >>>>>>>> When I did MDL, I notice a huge problem: MDL has its own set of
> >>>>>>>> components,
> >>>>>>>> some are in all sets (Button)
> >>>>>>>> but others not (Card), and they has it's own implementation, what
> >>> make
> >>>>>>> it
> >>>>>>>> almost impossible generalize
> >>>>>>>> a theme. For this reason I always point that we need our own set
> >>>>>>>>and
> >>>>>>> there
> >>>>>>>> we can implement themes. But other
> >>>>>>>> *externa* sets will never get this since they have its own
> >>>>>>> implementation
> >>>>>>>> and most important once you start to develop
> >>>>>>>> with MDL you can't go back and change for other. So MDL is for me
> >>>>>>>> something
> >>>>>>>> we have until our own set are robust and
> >>>>>>>> highly configurable in both the things we can do and how can it
> >>>>>>>>could
> >>>>>>> be
> >>>>>>>> represented, and switch between style should be
> >>>>>>>> really easy to change the global look of an App without much
> >>>>>>>>hassle.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Also, IIRC, Material has different components than Flex did so
> >>>>>>>>>we'd
> >>>>>>> have
> >>>>>>>>> to invent some new looks anyway. So having a TextInput with
> >>>>>>>>>borders
> >>>>>>> all
> >>>>>>>>> around would just be our flavor of Material.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> That's what I point above. We must to *freeze* the list of
> >>>>>>>>components
> >>>>>>> at
> >>>>>>>> some time work over a concrete set
> >>>>>>>> We can then plan in the future include a new component in the
> >>> official
> >>>>>>>> set,
> >>>>>>>> and that will need to work on the themes we already
> >>>>>>>> have to include the new one.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Regarding colors, it looks like Material is parameterized around
> >>>>>>>>>a
> >>>>>>>>> couple
> >>>>>>>>> of colors. So if we did our skins to work against parameterized
> >>>>>>> colors
> >>>>>>>>> then would it really matter what color we choose?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> That's completly right. I could make wireframe based on two or
> >>>>>>>>three
> >>>>>>>> colors
> >>>>>>>> and as you change it in CSS all controls should tint
> >>>>>>>> consistently.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Regarding Basic components, right now Checkbox is a <label><input
> >>>>>>>>> type="check"/>caption</label>. AIUI, you cannot style the
> >>>>>>>>><input>
> >>> on
> >>>>>>>>> many
> >>>>>>>>> browsers, so I think we have to have a different set of elements
> >>>>>>>>>in
> >>> a
> >>>>>>>>> checkbox. It looks like Bootstrap uses:
> >>>>>>>>>
> >>>>>>>>> <label><input type="check"/><span />Caption</label>
> >>>>>>>>>
> >>>>>>>>> Where the span uses a special symbol font with checked and
> >>>>>>>>>unchecked
> >>>>>>>>> boxes.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> That's what we need to figure. Should we make themes available in
> >>>>>>> Basic?
> >>>>>>>> if
> >>>>>>>> so, has basic the right implementation?
> >>>>>>>> If not, and if we don't want to change the actual very basic
> >>>>>>>> implementation, we need to put some "skin" implementation
> >>>>>>>> that at least in JS implementation I figure that will change one
> >>>>>>>>face
> >>>>>>> (the
> >>>>>>>> actual basic) with the theme face.
> >>>>>>>>
> >>>>>>>> I'm thinking loud, since this is something we should explorer all
> >>>>>>> together
> >>>>>>>> mixing the best ideas of people involved
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Alex
> >>>>>>>>>
> >>>>>>>>> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of
> Carlos
> >>>>>>>>> Rovira"
> >>>>>>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> I want to expose my initial work (very very initial) on two
> >>>>>>>>>>styles
> >>>>>>> for
> >>>>>>>>>> Royale
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Wireframe:
> >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> https%3A%2F%2Fsnag.gy%2
> >>>>>>>>>> FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7Cfa7b1b5a7
> >>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>>>>> sdata=%2Fk8YQxC5bDOaC
> >>>>>>>>>> D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>> (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://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> https%3A%2F%2Fsnag.gy%2
> >>>>>>>>>> FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7Cfa7b1b5a7
> >>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>>>>> sdata=kxYE7ylOsXPUEeE
> >>>>>>>>>> r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>> (*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
> >>>>>>>>>><carlosrovira@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 <ha...@gmail.com>:
> >>>>>>>>>>>
> >>>>>>>>>>>> BTW, the kind of thing we should be striving for in theme-able
> >>>>>>>>>>>> components
> >>>>>>>>>>>> is something like this:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> https%3A%2F%2Fvcalend
> >>>>>>>>>>>>
> >>>>>>>>>>>>ar.netlify.com%2F&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d5225
> >>>>>>>>>>>>0
> >>>>>>>>> 0f48%7Cf
> >>>>>>>>>
> >>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>> 7C636452649612378558&sdata=
> >>>>>>>>> b3VtV
> >>>>>>>>>>>> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
> >>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> https%3A%2F%2Fvcalen
> >>>>>>>>>>>> dar.netlify.com%2F&data=02%7C01%7C%
> >>> 7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7C
> >>>>>>>>>
> >>>>>>>>>> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>> 7C636452649612378558&sdata=
> >>>>>>>>> b3Vt
> >>>>>>>>>>>> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> https%3A%2F%2Fpaste.a
> >>>>>>>>>>>>
> >>>>>>>>>>>>pache.org%2FcOBC&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7Cfa
> >>>>>>>>>>>> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>>>>> sdata=bRWKxm
> >>>>>>>>>>>> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
> >>>>>>>>>
> >>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>> https%3A%2F%2Fpast
> >>>>>>>>>>>> e
> >>>>>>>>> .
> >>>>>>>>>>>>
> >>>>>>>>>>>>apache.org%2FcOBC&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d5225
> >>>>>>>>>>>>0
> >>>>>>>>> 0f48%7Cf
> >>>>>>>>>
> >>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>> 7C636452649612378558&sdata=
> >>>>>>>>> bRWKx
> >>>>>>>>>>>> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> (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
> >>>>>>>>> <carlosrovira@apache.org
> >>>>>>>>>>>> <ma...@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.lists@gmail.com
> >>>>>>> <mailto:
> >>>>>>>>>>>> harbs.lists@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
> >>>>>>>>> <aharui@adobe.com.INVALID
> >>>>>>>>>>>> <ma...@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
> >>>>>>>>>>>
> >>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> http%3A%2F%2Fabout.me%
> >>>>>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7Cfa7b1
> >>>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>>>>> sdata=C7a72gwfH2
> >>>>>>>>>>> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Carlos Rovira
> >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> http%3A%2F%2Fabout.me%2
> >>>>>>>>>> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>>>>> 0f48%7Cfa7b1b5
> >>>>>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>>>>> sdata=C7a72gwfH264w
> >>>>>>>>>> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>>
> >>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>> http%3A%2F%2Fwww.codeo
> >>>>>>>> scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
> >>>>>>> d8cf%7Cfa7b1b5a7b
> >>>>>>>> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> >>>>>>> sdata=Hm%2B6WIcqQTOHs0
> >>>>>>>> UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> >>>>>>> d8cf%7Cfa7b1b5a7b3
> >>>>>>>> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> >>>>>>> sdata=Hm%2B6WIcqQTOHs0U
> >>>>>>>> ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> >>>>>>> d8cf%7Cfa7b1b5a
> >>>>>>>> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> >>>>>>> sdata=b%2FFMr1Ajit94
> >>>>>>>> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Carlos Rovira
> >>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>> http%3A%2F%2Fabout.me%2
> >>>>>> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
> >>>>> 82e0%7Cfa7b1b5
> >>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
> >>>>> sdata=wYPMWW1wpTbtm
> >>>>>> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>>
> >>>><https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.co
> >>>>deoscopic.com&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
> 5950%7Cfa7b
> >>>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&
> sdata=Cszs7Ln
> >>>>LaXf9z%2F9Dv7l%2Ba%2BxZJM%2FxOMqs8FFbzO061Cc%3D&reserved=0>
> >>>>
> >>>> Carlos Rovira
> >>>>
> >>>> Director General
> >>>>
> >>>> M: +34 607 22 60 05
> >>>>
> >>>>
> >>>>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.cod
> >>>>eoscopic.com&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
> 5950%7Cfa7b1
> >>>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&
> sdata=Cszs7LnL
> >>>>aXf9z%2F9Dv7l%2Ba%2BxZJM%2FxOMqs8FFbzO061Cc%3D&reserved=0
> >>>>
> >>>>
> >>>> Conocenos Avant2 en 1 minuto!
> >>>><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Favant
> >>>>2.es%2F%23video&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
> 5950%7Cfa
> >>>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&
> sdata=iMuUY
> >>>>4Y%2FdwWAKXOXR%2BlHO9WIWPnOjdlrTCBjC0t2QUQ%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.
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon:
> >>*https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.pat
> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
> 59
> >>50%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636455141932227764&sdata=
> >>3KxMJ3IlEbtNDN7WtgzdqILz8LlPRtjjL%2FP61nzmgrM%3D&reserved=0
> >>
> >><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.pat
> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
> 59
> >>50%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636455141932227764&sdata=
> >>3KxMJ3IlEbtNDN7WtgzdqILz8LlPRtjjL%2FP61nzmgrM%3D&reserved=0>*
> >
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Working on UI Controls styling
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I'm not quite sure what the meaning of "based on Basic" means. I think
someone is about to go and move a bunch of classes around to better
organize our packages and classes, and I think that IUIBase and maybe
UIBase should end up back in Core (where it was before Harbs temporarily
wrapped the Sprites for SWF output).
So, if you are saying that SkinnableCheckbox will extend UIBase, that
makes sense. Should it extend Basic Checkbox? Possibly, if the override
of createElement is straightforward.
IMO, we shouldn't worry about Express or Basic. Just figure out what
HTMLElements you need in what positions and sizes to get the visual
changes you want. Then once we get it looking right, we can look at how
it compares with the other components and decide if we want to restructure
anything.
I'm not quite sure how CSSCheckbox works. It could be that there is a Div
where others have used a Span to hide the <input> and display something
else instead, otherwise I would think you couldn't control the visuals of
the check via CSS. These are the kinds of things we have to decide on.
It is fine to start with some list of components in order to bound the
work, but IMO, it is also important to have an understanding of the design
principles so that other designers will have a better idea of how to add
some other component that isn't on the list someday. I guarantee someone
will come up with something new and Carlos/Angelo won't have time to
design a default skin for it.
When writing framework, I like to stop and consider whether any line of
code is going to lock someone into something they might not want. That's
why we have beads and multiple component sets. We want everything to be
replaceable. I don't know if there is an analogy for Skins/Themes, but I
think it would be to stop and consider if the HTMLElement topology 1)
allows every pixel to be changed, and 2) if any two HTMLElements overlap,
if there are too many limitations imposed by that overlap. If someone
wants to Skin with Android, IOS, or even Windows 2.x or an old
green-screen terminal, can they?
My 2 cents,
-Alex
On 11/5/17, 1:29 PM, "Harbs" <ha...@gmail.com> wrote:
>Basic is going to be the base for anything. I don’t think Express is
>going to be very helpful. It should probably just be built out from Basic
>components and/or copied from Basic.
>
>For an example of a styleable component, take a look at CSSCheckbox. I
>think that’s a good example of a styleable component. You might be able
>to do better, but I had a need for a checkbox which could be styled using
>CSS and I created that class. I wanted to use a topcoat-styled checkbox,
>which I was able to do using that class like this:
>
>package com.printui.view.components
>{
> import org.apache.flex.html.CSSCheckBox;
>
> public class CheckBox extends CSSCheckBox
> {
> public function CheckBox(){
> super();
> className="topcoat-checkbox";
> checkClassName="topcoat-checkbox__checkmark";
> }
> }
>}
>
>I then used that class in my app.
>
>There might be more elegant ways to specify classes, but this is how I
>did it…
>
>Here’s what it looks like in the app:
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.evern
>ote.com%2Fl%2FAI_1QITiAqVCe5rgWuBlfIr3HjEQic1DhpQB%2Fimage.png&data=02%7C0
>1%7C%7Cdfc2dc02415b446e995108d524945950%7Cfa7b1b5a7b34438794aed2c178decee1
>%7C0%7C0%7C636455141932227764&sdata=CCCp3fmlnGFtImPTsEf9JsIXJdkcQVg3zbkIch
>2buoc%3D&reserved=0
>
>Hope this is useful,
>Harbs
>
>> On Nov 5, 2017, at 11:01 PM, Piotr Zarzycki <pi...@gmail.com>
>>wrote:
>>
>> I was thinking about that and new component set is the approach which we
>> should try, but we need to base on something. My first thoughts was
>>that it
>> should be Basic, cause I bet that once we start create style for each
>> component we will end up with some issue or we would like to create some
>> additional features to those controls in order to make that theme
>>happen.
>> It leads my thought then farther let's say that we will start work in
>> following way:
>> 1) Basic is our base
>> 2) Carlos will prepare some appearance for component
>> 3) We are starting to work on that, but it's end up that our component
>>need
>> some additional feature, which is do not suits for Basic
>> 4) We are adds that feature to Express and use in that place Express
>> component.
>>
>> It ends up that our component theme will be mix of Express and Basic
>>
>> Second approach is - Forget about Express, use Basic only and add to
>>Theme
>> set features if needed. Express will be always separate set, FAT and it
>> will be responsibility for user if he would like to style it. - If our
>> implementation will be in Theme enough robust, user should be able to
>>use
>> in his application Express with some styles from Theme set.
>>
>> Thoughts ?
>> Piotr
>>
>>
>> 2017-11-05 11:21 GMT+01:00 Harbs <ha...@gmail.com>:
>>
>>> I would suggest starting a new component set with a fresh slate called
>>> Themed (or something like that).
>>>
>>> The Themed component set should give priority to style-ablitity and
>>>ease
>>> of use over just about every other consideration. I think of Express as
>>> more of a middle-of the road approach to make things easier. A Themed
>>>set
>>> would be more of a replacement for mx and spark.
>>>
>>> Yes. Definitely make a clear list of supported components. It’s
>>>probably
>>> more important to have quality of components rather than quantity. A
>>>few
>>> well constructed components is better than a lot of half-baked ones.
>>>More
>>> components could always be added.
>>>
>>> I’m very glad to hear that Angelo is working with you. That’s great
>>>news!
>>>
>>> Harbs
>>>
>>>> On Nov 5, 2017, at 12:12 PM, Carlos Rovira <
>>> carlos.rovira@codeoscopic.com> wrote:
>>>>
>>>> ok Alex,
>>>>
>>>> so if I understand correctly, you mean that we create our own set,
>>>>with
>>>> Basic as base right?
>>>> but we should go with Express? It's great that we could create many
>>>>sets
>>> in
>>>> Royale, and I think the Basic use
>>>> you commented is very licit and didn't think about that. But we must
>>> think
>>>> in some *main* set, maybe is Express
>>>> and that I want to focus this effort for that concrete set.
>>>>
>>>> I mean, one important thing here is that we all agree in support a
>>> concrete
>>>> list of UI controls and components
>>>> I plan to make a discuss thread for this, since the theme feature will
>>>> affect only to that controls, and if we want to include a new one
>>>> we should vote to include it, since it implies to include in design,
>>>> implementation and all themes that we want to support.
>>>>
>>>> I think I'll create a discuss thread with this an other things we
>>>>talked
>>>> about since this is a huge effort and is important for all the
>>>> people that will be involved to work around things discussed, voted
>>>>and
>>>> approved by all.
>>>> We need to be synced here or we'll end working too much for somehitng
>>> that
>>>> does not get to be useful in the end. I want to ensure this before
>>>> to start investing a huge amount of time.
>>>>
>>>> As well I was contacted by Angelo and talk about all this. He's very
>>>> passionate as well on this and we'll seeing how we can combine our
>>> efforts
>>>> and if someone
>>>> more wants to join us.
>>>>
>>>> I'll be writing the discussion thread in order to plan the effort in
>>> short.
>>>> Stay tuned :)
>>>>
>>>> 2017-11-05 8:29 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>
>>>>> Hi Carlos,
>>>>>
>>>>> I think we're pretty much in agreement. Regarding Basic, for me, I
>>>>>have
>>>>> created plenty of web pages with non-styleable checkboxes. I don't
>>>>>care
>>>>> that the checkbox looks different on different browsers. I just want
>>> the
>>>>> smallest simplest output. Just like taking an HTML editor and
>>>>>slapping
>>> in
>>>>> a few tags and calling it done. Would that be production? Sure, if
>>>>>I'm
>>>>> just want someone to check a box before enabling a download button.
>>> IOW,
>>>>> it would be for internal customers only.
>>>>>
>>>>> So, IMO, a Skinnable/Themeable component set would be something
>>>>>else. I
>>>>> think you will need that extra Span for a Checkbox. IMO, we should
>>>>>just
>>>>> go and build these new components. And when we get it mostly
>>>>>working,
>>> we
>>>>> can compare against Basic and see if we want to parameterize the
>>>>>views
>>> in
>>>>> the low-level Basic components or not.
>>>>>
>>>>> My 2 cents,
>>>>> -Alex
>>>>>
>>>>> On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>> Rovira"
>>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>>>>
>>>>>> HI Alex,
>>>>>>
>>>>>>
>>>>>> 2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>>>
>>>>>>> Hi Carlos,
>>>>>>>
>>>>>>> I skimmed through
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>> https%3A%2F%2Fmaterial
>>>>>>>
>>>>>>>.io%2Fguidelines%2F%23&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d5239
>>>>>>>7
>>>>> 82e0
>>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>> 7C636454056000808812&sdata=g5
>>>>>>> M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last
>>> night.
>>>>>>>
>>>>>>> My impression is that there were two parts to it. First was the
>>>>>>> environment/principles section which talked about physical objects
>>>>>>>and
>>>>>>> light (and motion), and then there were choices of widgets. For
>>>>>>> example,
>>>>>>> I didn't see anything in the first part that said that a text input
>>> had
>>>>>>> to
>>>>>>> be a single line and couldn't be a box.
>>>>>>>
>>>>>>
>>>>>> Material guidelines could be a great way to start, but trying to
>>>>>>give
>>>>>> something different.
>>>>>> I think that we need to get something that looks great while be
>>>>>>clearly
>>>>>> different to google material,
>>>>>> bootstrap, and others so people could see us as an alternative. That
>>> could
>>>>>> make people copying us
>>>>>> or adopting the whole Apache Royale SDK that is what we want in the
>>>>>>end
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> That made me think that we could use our widget set and apply
>>>>>>>Material
>>>>>>> environment and principles to it. If we decide not to, I would
>>>>>>>think
>>>>>>> you
>>>>>>> would want to have some sort of similar environment/principles
>>> document
>>>>>>> which seems like a fair amount of work. I think we'd end up
>>>>>>>looking
>>>>>>> different because we have different widgets and maybe some
>>>>>>>different
>>>>>>> colors. I'm pretty sure that we don't want to be different so much
>>> that
>>>>>>> we don't create things that folks want to use. The priority to me
>>>>>>>is
>>>>>>> just
>>>>>>> to prove that you can alter every pixel in every widget we have so
>>> that
>>>>>>> others can provide custom skins as well. So starting with Material
>>>>>>> principles seems like it would save us time, we can get something
>>>>>>> released, and can innovate more later.
>>>>>>>
>>>>>>
>>>>>> I think as you that we need a way to make the "presentation" of each
>>>>>> component highly customizable.
>>>>>> And we need to be different in visualization (art, colors, ...) but
>>> not in
>>>>>> usability that is what people
>>>>>> needs to be consistently
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Maybe a good question for our users is: How many of you used the
>>>>>>> default
>>>>>>> Flex skins vs a whole new set of skins? If most folks completely
>>>>>>> re-skinned to match their corporate branding, it matters less what
>>>>>>>our
>>>>>>> default is, and more that we can allow folks to customize every
>>>>>>>pixel.
>>>>>>>
>>>>>>>
>>>>>> We need both: a skin that will be highly customizable and to change
>>> skins
>>>>>> to look very very different.
>>>>>> People with lees money or time in their Apps will choose the first.
>>> People
>>>>>> that has more resources will go with the second.
>>>>>> Apache Royale needs to support both
>>>>>>
>>>>>>
>>>>>>> The wireframe can be black and white, IMO. I was thinking that
>>> "vivid"
>>>>>>> would have parameterized colors.
>>>>>>>
>>>>>>>
>>>>>> I started to think that wireframe could end having lots of
>>> customization
>>>>>> controls. For example:
>>>>>>
>>>>>> -2-3 main colors as we talked , and the same MDL does
>>>>>> -possibilitiy to be solid colors, or gradients
>>>>>> -possibility to have backgrounds more or less opaque
>>>>>>
>>>>>> if we see a concrete component like button:
>>>>>>
>>>>>> - configurable corners, square to round corners
>>>>>> - more blocky (relief) or more flat
>>>>>> ...
>>>>>>
>>>>>> So wireframe could be a concrete configuration of the main theme
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Since Bootstrap was mentioned, I want to point out that the
>>>>>>>Flat.swc
>>> is
>>>>>>> a
>>>>>>> rough approximation of the Flat theme which is a Bootstrap theme.
>>>>>>>It
>>>>>>> is a
>>>>>>> rough approximation because I could not use the Flat CSS file
>>>>>>>directly
>>>>>>> since it contains much more advanced CSS than we currently support
>>>>>>>on
>>>>>>> the
>>>>>>> SWF side. But it presumed that the Checkbox was a Label with a
>>>>>>>Span
>>>>>>> that
>>>>>>> hides in front of or behind the <input type="check" /> in order to
>>> allow
>>>>>>> customizing every pixel. Looks like MDL uses the same Span trick
>>>>>>>but
>>>>>>> maybe without a symbol font.
>>>>>>>
>>>>>>> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
>>>>>>> should
>>>>>>> not have that extra Span. But it looks to me that a
>>>>>>>SkinnableCheckbox
>>>>>>> can
>>>>>>> add that extra Span and you either give it the same class name that
>>>>>>> BootStrap or MDL uses or create our own set of classnames and the
>>>>>>>CSS
>>>>>>> that
>>>>>>> goes with it.
>>>>>>>
>>>>>>>
>>>>>> The problem with Basic could be that if is very very basic and looks
>>> with
>>>>>> a
>>>>>> very basic look (as it is very poorly stylizable), I think
>>>>>> People will not use it at all, in this case, I'll don't understand
>>>>>>the
>>>>>> goal
>>>>>> with basic. It's intend ended as a base
>>>>>> but to not use in production? For this reason is what I want to
>>>>>>know if
>>>>>> you
>>>>>> think this theme feature could be plugged in basic or not.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Of course, I could be wrong. This is not my area of expertise at
>>>>>>>all.
>>>>>>>
>>>>>>
>>>>>> Hi Alex, maybe UX is not your expertise area, but your help here is
>>> very
>>>>>> needed since we can get to great ideas in this field, but
>>>>>> maybe don't know how to bring it to implementation in Apache
>>>>>>Royale. I
>>>>>> think that you, Peter, Harbs,... are needed in order to
>>>>>> make this happen in the pure arquitecture side or this feature.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -Alex
>>>>>>>
>>>>>>>
>>>>>>> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>>>>>> Rovira"
>>>>>>> <carlos.rovira@gmail.com on behalf of
>>>>>>>carlos.rovira@codeoscopic.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Alex,
>>>>>>>>
>>>>>>>> 2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>>>>>
>>>>>>>>> Hi Carlos,
>>>>>>>>>
>>>>>>>>> Looks good to me. Thanks for doing this.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks :)
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm not sure I understand all of the aspects of this effort. My
>>>>>>> current
>>>>>>>>> understanding is that Google Material is under the Apache License
>>> and
>>>>>>>>> thus
>>>>>>>>> we can use it if we want to. Am I correct that
>>>>>>>>>MaterialDesignLite
>>> is
>>>>>>>>> one
>>>>>>>>> implementation of Google Material and we could create our own
>>>>>>>>> implementation and it could be visually different?
>>>>>>>>>
>>>>>>>>
>>>>>>>> We can implement our own material in Royale, but I'm afraid that
>>> doing
>>>>>>>> that
>>>>>>>> will not make us
>>>>>>>> highlight our solution against the rest of competitors. Another
>>>>>>>>point
>>>>>>> is
>>>>>>>> something I said various times:
>>>>>>>> When I did MDL, I notice a huge problem: MDL has its own set of
>>>>>>>> components,
>>>>>>>> some are in all sets (Button)
>>>>>>>> but others not (Card), and they has it's own implementation, what
>>> make
>>>>>>> it
>>>>>>>> almost impossible generalize
>>>>>>>> a theme. For this reason I always point that we need our own set
>>>>>>>>and
>>>>>>> there
>>>>>>>> we can implement themes. But other
>>>>>>>> *externa* sets will never get this since they have its own
>>>>>>> implementation
>>>>>>>> and most important once you start to develop
>>>>>>>> with MDL you can't go back and change for other. So MDL is for me
>>>>>>>> something
>>>>>>>> we have until our own set are robust and
>>>>>>>> highly configurable in both the things we can do and how can it
>>>>>>>>could
>>>>>>> be
>>>>>>>> represented, and switch between style should be
>>>>>>>> really easy to change the global look of an App without much
>>>>>>>>hassle.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also, IIRC, Material has different components than Flex did so
>>>>>>>>>we'd
>>>>>>> have
>>>>>>>>> to invent some new looks anyway. So having a TextInput with
>>>>>>>>>borders
>>>>>>> all
>>>>>>>>> around would just be our flavor of Material.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's what I point above. We must to *freeze* the list of
>>>>>>>>components
>>>>>>> at
>>>>>>>> some time work over a concrete set
>>>>>>>> We can then plan in the future include a new component in the
>>> official
>>>>>>>> set,
>>>>>>>> and that will need to work on the themes we already
>>>>>>>> have to include the new one.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regarding colors, it looks like Material is parameterized around
>>>>>>>>>a
>>>>>>>>> couple
>>>>>>>>> of colors. So if we did our skins to work against parameterized
>>>>>>> colors
>>>>>>>>> then would it really matter what color we choose?
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's completly right. I could make wireframe based on two or
>>>>>>>>three
>>>>>>>> colors
>>>>>>>> and as you change it in CSS all controls should tint
>>>>>>>> consistently.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regarding Basic components, right now Checkbox is a <label><input
>>>>>>>>> type="check"/>caption</label>. AIUI, you cannot style the
>>>>>>>>><input>
>>> on
>>>>>>>>> many
>>>>>>>>> browsers, so I think we have to have a different set of elements
>>>>>>>>>in
>>> a
>>>>>>>>> checkbox. It looks like Bootstrap uses:
>>>>>>>>>
>>>>>>>>> <label><input type="check"/><span />Caption</label>
>>>>>>>>>
>>>>>>>>> Where the span uses a special symbol font with checked and
>>>>>>>>>unchecked
>>>>>>>>> boxes.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's what we need to figure. Should we make themes available in
>>>>>>> Basic?
>>>>>>>> if
>>>>>>>> so, has basic the right implementation?
>>>>>>>> If not, and if we don't want to change the actual very basic
>>>>>>>> implementation, we need to put some "skin" implementation
>>>>>>>> that at least in JS implementation I figure that will change one
>>>>>>>>face
>>>>>>> (the
>>>>>>>> actual basic) with the theme face.
>>>>>>>>
>>>>>>>> I'm thinking loud, since this is something we should explorer all
>>>>>>> together
>>>>>>>> mixing the best ideas of people involved
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos
>>>>>>>>> Rovira"
>>>>>>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I want to expose my initial work (very very initial) on two
>>>>>>>>>>styles
>>>>>>> for
>>>>>>>>>> Royale
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Wireframe:
>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fsnag.gy%2
>>>>>>>>>> FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa7b1b5a7
>>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=%2Fk8YQxC5bDOaC
>>>>>>>>>> D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
>>>>>>>>>>
>>>>>>>>>> (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://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fsnag.gy%2
>>>>>>>>>> FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa7b1b5a7
>>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=kxYE7ylOsXPUEeE
>>>>>>>>>> r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
>>>>>>>>>>
>>>>>>>>>> (*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
>>>>>>>>>><carlosrovira@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 <ha...@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> BTW, the kind of thing we should be striving for in theme-able
>>>>>>>>>>>> components
>>>>>>>>>>>> is something like this:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fvcalend
>>>>>>>>>>>>
>>>>>>>>>>>>ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d5225
>>>>>>>>>>>>0
>>>>>>>>> 0f48%7Cf
>>>>>>>>>
>>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636452649612378558&sdata=
>>>>>>>>> b3VtV
>>>>>>>>>>>> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
>>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fvcalen
>>>>>>>>>>>> dar.netlify.com%2F&data=02%7C01%7C%
>>> 7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7C
>>>>>>>>>
>>>>>>>>>> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636452649612378558&sdata=
>>>>>>>>> b3Vt
>>>>>>>>>>>> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> https%3A%2F%2Fpaste.a
>>>>>>>>>>>>
>>>>>>>>>>>>pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa
>>>>>>>>>>>> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=bRWKxm
>>>>>>>>>>>> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
>>>>>>>>>
>>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> https%3A%2F%2Fpast
>>>>>>>>>>>> e
>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>>>apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d5225
>>>>>>>>>>>>0
>>>>>>>>> 0f48%7Cf
>>>>>>>>>
>>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636452649612378558&sdata=
>>>>>>>>> bRWKx
>>>>>>>>>>>> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
>>>>>>>>>>>>>
>>>>>>>>>>>>> (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
>>>>>>>>> <carlosrovira@apache.org
>>>>>>>>>>>> <ma...@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.lists@gmail.com
>>>>>>> <mailto:
>>>>>>>>>>>> harbs.lists@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
>>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>
>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> http%3A%2F%2Fabout.me%
>>>>>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa7b1
>>>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=C7a72gwfH2
>>>>>>>>>>> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Carlos Rovira
>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>> http%3A%2F%2Fabout.me%2
>>>>>>>>>> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>>> 0f48%7Cfa7b1b5
>>>>>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>>> sdata=C7a72gwfH264w
>>>>>>>>>> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> http%3A%2F%2Fwww.codeo
>>>>>>>> scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
>>>>>>> d8cf%7Cfa7b1b5a7b
>>>>>>>> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>>>>> sdata=Hm%2B6WIcqQTOHs0
>>>>>>>> UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>>>>>>> d8cf%7Cfa7b1b5a7b3
>>>>>>>> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>>>>> sdata=Hm%2B6WIcqQTOHs0U
>>>>>>>> ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>>>>>>> d8cf%7Cfa7b1b5a
>>>>>>>> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>>>>> sdata=b%2FFMr1Ajit94
>>>>>>>> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>> http%3A%2F%2Fabout.me%2
>>>>>> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
>>>>> 82e0%7Cfa7b1b5
>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
>>>>> sdata=wYPMWW1wpTbtm
>>>>>> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.co
>>>>deoscopic.com&data=02%7C01%7C%7Cdfc2dc02415b446e995108d524945950%7Cfa7b
>>>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&sdata=Cszs7Ln
>>>>LaXf9z%2F9Dv7l%2Ba%2BxZJM%2FxOMqs8FFbzO061Cc%3D&reserved=0>
>>>>
>>>> Carlos Rovira
>>>>
>>>> Director General
>>>>
>>>> M: +34 607 22 60 05
>>>>
>>>>
>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cod
>>>>eoscopic.com&data=02%7C01%7C%7Cdfc2dc02415b446e995108d524945950%7Cfa7b1
>>>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&sdata=Cszs7LnL
>>>>aXf9z%2F9Dv7l%2Ba%2BxZJM%2FxOMqs8FFbzO061Cc%3D&reserved=0
>>>>
>>>>
>>>> Conocenos Avant2 en 1 minuto!
>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant
>>>>2.es%2F%23video&data=02%7C01%7C%7Cdfc2dc02415b446e995108d524945950%7Cfa
>>>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&sdata=iMuUY
>>>>4Y%2FdwWAKXOXR%2BlHO9WIWPnOjdlrTCBjC0t2QUQ%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.
>>>
>>>
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>> Patreon:
>>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat
>>reon.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cdfc2dc02415b446e995108d5249459
>>50%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&sdata=
>>3KxMJ3IlEbtNDN7WtgzdqILz8LlPRtjjL%2FP61nzmgrM%3D&reserved=0
>>
>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat
>>reon.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cdfc2dc02415b446e995108d5249459
>>50%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&sdata=
>>3KxMJ3IlEbtNDN7WtgzdqILz8LlPRtjjL%2FP61nzmgrM%3D&reserved=0>*
>
Re: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
Basic is going to be the base for anything. I don’t think Express is going to be very helpful. It should probably just be built out from Basic components and/or copied from Basic.
For an example of a styleable component, take a look at CSSCheckbox. I think that’s a good example of a styleable component. You might be able to do better, but I had a need for a checkbox which could be styled using CSS and I created that class. I wanted to use a topcoat-styled checkbox, which I was able to do using that class like this:
package com.printui.view.components
{
import org.apache.flex.html.CSSCheckBox;
public class CheckBox extends CSSCheckBox
{
public function CheckBox(){
super();
className="topcoat-checkbox";
checkClassName="topcoat-checkbox__checkmark";
}
}
}
I then used that class in my app.
There might be more elegant ways to specify classes, but this is how I did it…
Here’s what it looks like in the app:
https://www.evernote.com/l/AI_1QITiAqVCe5rgWuBlfIr3HjEQic1DhpQB/image.png
Hope this is useful,
Harbs
> On Nov 5, 2017, at 11:01 PM, Piotr Zarzycki <pi...@gmail.com> wrote:
>
> I was thinking about that and new component set is the approach which we
> should try, but we need to base on something. My first thoughts was that it
> should be Basic, cause I bet that once we start create style for each
> component we will end up with some issue or we would like to create some
> additional features to those controls in order to make that theme happen.
> It leads my thought then farther let's say that we will start work in
> following way:
> 1) Basic is our base
> 2) Carlos will prepare some appearance for component
> 3) We are starting to work on that, but it's end up that our component need
> some additional feature, which is do not suits for Basic
> 4) We are adds that feature to Express and use in that place Express
> component.
>
> It ends up that our component theme will be mix of Express and Basic
>
> Second approach is - Forget about Express, use Basic only and add to Theme
> set features if needed. Express will be always separate set, FAT and it
> will be responsibility for user if he would like to style it. - If our
> implementation will be in Theme enough robust, user should be able to use
> in his application Express with some styles from Theme set.
>
> Thoughts ?
> Piotr
>
>
> 2017-11-05 11:21 GMT+01:00 Harbs <ha...@gmail.com>:
>
>> I would suggest starting a new component set with a fresh slate called
>> Themed (or something like that).
>>
>> The Themed component set should give priority to style-ablitity and ease
>> of use over just about every other consideration. I think of Express as
>> more of a middle-of the road approach to make things easier. A Themed set
>> would be more of a replacement for mx and spark.
>>
>> Yes. Definitely make a clear list of supported components. It’s probably
>> more important to have quality of components rather than quantity. A few
>> well constructed components is better than a lot of half-baked ones. More
>> components could always be added.
>>
>> I’m very glad to hear that Angelo is working with you. That’s great news!
>>
>> Harbs
>>
>>> On Nov 5, 2017, at 12:12 PM, Carlos Rovira <
>> carlos.rovira@codeoscopic.com> wrote:
>>>
>>> ok Alex,
>>>
>>> so if I understand correctly, you mean that we create our own set, with
>>> Basic as base right?
>>> but we should go with Express? It's great that we could create many sets
>> in
>>> Royale, and I think the Basic use
>>> you commented is very licit and didn't think about that. But we must
>> think
>>> in some *main* set, maybe is Express
>>> and that I want to focus this effort for that concrete set.
>>>
>>> I mean, one important thing here is that we all agree in support a
>> concrete
>>> list of UI controls and components
>>> I plan to make a discuss thread for this, since the theme feature will
>>> affect only to that controls, and if we want to include a new one
>>> we should vote to include it, since it implies to include in design,
>>> implementation and all themes that we want to support.
>>>
>>> I think I'll create a discuss thread with this an other things we talked
>>> about since this is a huge effort and is important for all the
>>> people that will be involved to work around things discussed, voted and
>>> approved by all.
>>> We need to be synced here or we'll end working too much for somehitng
>> that
>>> does not get to be useful in the end. I want to ensure this before
>>> to start investing a huge amount of time.
>>>
>>> As well I was contacted by Angelo and talk about all this. He's very
>>> passionate as well on this and we'll seeing how we can combine our
>> efforts
>>> and if someone
>>> more wants to join us.
>>>
>>> I'll be writing the discussion thread in order to plan the effort in
>> short.
>>> Stay tuned :)
>>>
>>> 2017-11-05 8:29 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>
>>>> Hi Carlos,
>>>>
>>>> I think we're pretty much in agreement. Regarding Basic, for me, I have
>>>> created plenty of web pages with non-styleable checkboxes. I don't care
>>>> that the checkbox looks different on different browsers. I just want
>> the
>>>> smallest simplest output. Just like taking an HTML editor and slapping
>> in
>>>> a few tags and calling it done. Would that be production? Sure, if I'm
>>>> just want someone to check a box before enabling a download button.
>> IOW,
>>>> it would be for internal customers only.
>>>>
>>>> So, IMO, a Skinnable/Themeable component set would be something else. I
>>>> think you will need that extra Span for a Checkbox. IMO, we should just
>>>> go and build these new components. And when we get it mostly working,
>> we
>>>> can compare against Basic and see if we want to parameterize the views
>> in
>>>> the low-level Basic components or not.
>>>>
>>>> My 2 cents,
>>>> -Alex
>>>>
>>>> On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com on behalf of Carlos
>> Rovira"
>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>>>
>>>>> HI Alex,
>>>>>
>>>>>
>>>>> 2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>>
>>>>>> Hi Carlos,
>>>>>>
>>>>>> I skimmed through
>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>> https%3A%2F%2Fmaterial
>>>>>> .io%2Fguidelines%2F%23&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
>>>> 82e0
>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>> 7C636454056000808812&sdata=g5
>>>>>> M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last
>> night.
>>>>>>
>>>>>> My impression is that there were two parts to it. First was the
>>>>>> environment/principles section which talked about physical objects and
>>>>>> light (and motion), and then there were choices of widgets. For
>>>>>> example,
>>>>>> I didn't see anything in the first part that said that a text input
>> had
>>>>>> to
>>>>>> be a single line and couldn't be a box.
>>>>>>
>>>>>
>>>>> Material guidelines could be a great way to start, but trying to give
>>>>> something different.
>>>>> I think that we need to get something that looks great while be clearly
>>>>> different to google material,
>>>>> bootstrap, and others so people could see us as an alternative. That
>> could
>>>>> make people copying us
>>>>> or adopting the whole Apache Royale SDK that is what we want in the end
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> That made me think that we could use our widget set and apply Material
>>>>>> environment and principles to it. If we decide not to, I would think
>>>>>> you
>>>>>> would want to have some sort of similar environment/principles
>> document
>>>>>> which seems like a fair amount of work. I think we'd end up looking
>>>>>> different because we have different widgets and maybe some different
>>>>>> colors. I'm pretty sure that we don't want to be different so much
>> that
>>>>>> we don't create things that folks want to use. The priority to me is
>>>>>> just
>>>>>> to prove that you can alter every pixel in every widget we have so
>> that
>>>>>> others can provide custom skins as well. So starting with Material
>>>>>> principles seems like it would save us time, we can get something
>>>>>> released, and can innovate more later.
>>>>>>
>>>>>
>>>>> I think as you that we need a way to make the "presentation" of each
>>>>> component highly customizable.
>>>>> And we need to be different in visualization (art, colors, ...) but
>> not in
>>>>> usability that is what people
>>>>> needs to be consistently
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Maybe a good question for our users is: How many of you used the
>>>>>> default
>>>>>> Flex skins vs a whole new set of skins? If most folks completely
>>>>>> re-skinned to match their corporate branding, it matters less what our
>>>>>> default is, and more that we can allow folks to customize every pixel.
>>>>>>
>>>>>>
>>>>> We need both: a skin that will be highly customizable and to change
>> skins
>>>>> to look very very different.
>>>>> People with lees money or time in their Apps will choose the first.
>> People
>>>>> that has more resources will go with the second.
>>>>> Apache Royale needs to support both
>>>>>
>>>>>
>>>>>> The wireframe can be black and white, IMO. I was thinking that
>> "vivid"
>>>>>> would have parameterized colors.
>>>>>>
>>>>>>
>>>>> I started to think that wireframe could end having lots of
>> customization
>>>>> controls. For example:
>>>>>
>>>>> -2-3 main colors as we talked , and the same MDL does
>>>>> -possibilitiy to be solid colors, or gradients
>>>>> -possibility to have backgrounds more or less opaque
>>>>>
>>>>> if we see a concrete component like button:
>>>>>
>>>>> - configurable corners, square to round corners
>>>>> - more blocky (relief) or more flat
>>>>> ...
>>>>>
>>>>> So wireframe could be a concrete configuration of the main theme
>>>>>
>>>>>
>>>>>
>>>>>> Since Bootstrap was mentioned, I want to point out that the Flat.swc
>> is
>>>>>> a
>>>>>> rough approximation of the Flat theme which is a Bootstrap theme. It
>>>>>> is a
>>>>>> rough approximation because I could not use the Flat CSS file directly
>>>>>> since it contains much more advanced CSS than we currently support on
>>>>>> the
>>>>>> SWF side. But it presumed that the Checkbox was a Label with a Span
>>>>>> that
>>>>>> hides in front of or behind the <input type="check" /> in order to
>> allow
>>>>>> customizing every pixel. Looks like MDL uses the same Span trick but
>>>>>> maybe without a symbol font.
>>>>>>
>>>>>> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
>>>>>> should
>>>>>> not have that extra Span. But it looks to me that a SkinnableCheckbox
>>>>>> can
>>>>>> add that extra Span and you either give it the same class name that
>>>>>> BootStrap or MDL uses or create our own set of classnames and the CSS
>>>>>> that
>>>>>> goes with it.
>>>>>>
>>>>>>
>>>>> The problem with Basic could be that if is very very basic and looks
>> with
>>>>> a
>>>>> very basic look (as it is very poorly stylizable), I think
>>>>> People will not use it at all, in this case, I'll don't understand the
>>>>> goal
>>>>> with basic. It's intend ended as a base
>>>>> but to not use in production? For this reason is what I want to know if
>>>>> you
>>>>> think this theme feature could be plugged in basic or not.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Of course, I could be wrong. This is not my area of expertise at all.
>>>>>>
>>>>>
>>>>> Hi Alex, maybe UX is not your expertise area, but your help here is
>> very
>>>>> needed since we can get to great ideas in this field, but
>>>>> maybe don't know how to bring it to implementation in Apache Royale. I
>>>>> think that you, Peter, Harbs,... are needed in order to
>>>>> make this happen in the pure arquitecture side or this feature.
>>>>>
>>>>> Thanks
>>>>>
>>>>> -Alex
>>>>>>
>>>>>>
>>>>>> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>>>>> Rovira"
>>>>>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>> 2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>>>>
>>>>>>>> Hi Carlos,
>>>>>>>>
>>>>>>>> Looks good to me. Thanks for doing this.
>>>>>>>>
>>>>>>>
>>>>>>> Thanks :)
>>>>>>>
>>>>>>>>
>>>>>>>> I'm not sure I understand all of the aspects of this effort. My
>>>>>> current
>>>>>>>> understanding is that Google Material is under the Apache License
>> and
>>>>>>>> thus
>>>>>>>> we can use it if we want to. Am I correct that MaterialDesignLite
>> is
>>>>>>>> one
>>>>>>>> implementation of Google Material and we could create our own
>>>>>>>> implementation and it could be visually different?
>>>>>>>>
>>>>>>>
>>>>>>> We can implement our own material in Royale, but I'm afraid that
>> doing
>>>>>>> that
>>>>>>> will not make us
>>>>>>> highlight our solution against the rest of competitors. Another point
>>>>>> is
>>>>>>> something I said various times:
>>>>>>> When I did MDL, I notice a huge problem: MDL has its own set of
>>>>>>> components,
>>>>>>> some are in all sets (Button)
>>>>>>> but others not (Card), and they has it's own implementation, what
>> make
>>>>>> it
>>>>>>> almost impossible generalize
>>>>>>> a theme. For this reason I always point that we need our own set and
>>>>>> there
>>>>>>> we can implement themes. But other
>>>>>>> *externa* sets will never get this since they have its own
>>>>>> implementation
>>>>>>> and most important once you start to develop
>>>>>>> with MDL you can't go back and change for other. So MDL is for me
>>>>>>> something
>>>>>>> we have until our own set are robust and
>>>>>>> highly configurable in both the things we can do and how can it could
>>>>>> be
>>>>>>> represented, and switch between style should be
>>>>>>> really easy to change the global look of an App without much hassle.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Also, IIRC, Material has different components than Flex did so we'd
>>>>>> have
>>>>>>>> to invent some new looks anyway. So having a TextInput with borders
>>>>>> all
>>>>>>>> around would just be our flavor of Material.
>>>>>>>>
>>>>>>>
>>>>>>> That's what I point above. We must to *freeze* the list of components
>>>>>> at
>>>>>>> some time work over a concrete set
>>>>>>> We can then plan in the future include a new component in the
>> official
>>>>>>> set,
>>>>>>> and that will need to work on the themes we already
>>>>>>> have to include the new one.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Regarding colors, it looks like Material is parameterized around a
>>>>>>>> couple
>>>>>>>> of colors. So if we did our skins to work against parameterized
>>>>>> colors
>>>>>>>> then would it really matter what color we choose?
>>>>>>>>
>>>>>>>
>>>>>>> That's completly right. I could make wireframe based on two or three
>>>>>>> colors
>>>>>>> and as you change it in CSS all controls should tint
>>>>>>> consistently.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Regarding Basic components, right now Checkbox is a <label><input
>>>>>>>> type="check"/>caption</label>. AIUI, you cannot style the <input>
>> on
>>>>>>>> many
>>>>>>>> browsers, so I think we have to have a different set of elements in
>> a
>>>>>>>> checkbox. It looks like Bootstrap uses:
>>>>>>>>
>>>>>>>> <label><input type="check"/><span />Caption</label>
>>>>>>>>
>>>>>>>> Where the span uses a special symbol font with checked and unchecked
>>>>>>>> boxes.
>>>>>>>>
>>>>>>>
>>>>>>> That's what we need to figure. Should we make themes available in
>>>>>> Basic?
>>>>>>> if
>>>>>>> so, has basic the right implementation?
>>>>>>> If not, and if we don't want to change the actual very basic
>>>>>>> implementation, we need to put some "skin" implementation
>>>>>>> that at least in JS implementation I figure that will change one face
>>>>>> (the
>>>>>>> actual basic) with the theme face.
>>>>>>>
>>>>>>> I'm thinking loud, since this is something we should explorer all
>>>>>> together
>>>>>>> mixing the best ideas of people involved
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alex
>>>>>>>>
>>>>>>>> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos
>>>>>>>> Rovira"
>>>>>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I want to expose my initial work (very very initial) on two styles
>>>>>> for
>>>>>>>>> Royale
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Wireframe:
>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> https%3A%2F%2Fsnag.gy%2
>>>>>>>>> FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>> 0f48%7Cfa7b1b5a7
>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>> sdata=%2Fk8YQxC5bDOaC
>>>>>>>>> D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
>>>>>>>>>
>>>>>>>>> (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://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> https%3A%2F%2Fsnag.gy%2
>>>>>>>>> FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>> 0f48%7Cfa7b1b5a7
>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>> sdata=kxYE7ylOsXPUEeE
>>>>>>>>> r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
>>>>>>>>>
>>>>>>>>> (*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 <carlosrovira@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 <ha...@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> BTW, the kind of thing we should be striving for in theme-able
>>>>>>>>>>> components
>>>>>>>>>>> is something like this:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> https%3A%2F%2Fvcalend
>>>>>>>>>>> ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>> 0f48%7Cf
>>>>>>>>
>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636452649612378558&sdata=
>>>>>>>> b3VtV
>>>>>>>>>>> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> https%3A%2F%2Fvcalen
>>>>>>>>>>> dar.netlify.com%2F&data=02%7C01%7C%
>> 7C203485b5b9c744aed92608d52250
>>>>>>>> 0f48%7C
>>>>>>>>
>>>>>>>>> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636452649612378558&sdata=
>>>>>>>> b3Vt
>>>>>>>>>>> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
>>>>>>>>>>>
>>>>>>>>>>>> On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> https%3A%2F%2Fpaste.a
>>>>>>>>>>> pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>> 0f48%7Cfa
>>>>>>>>>>> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>> sdata=bRWKxm
>>>>>>>>>>> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
>>>>>>>>
>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>> https%3A%2F%2Fpast
>>>>>>>>>>> e
>>>>>>>> .
>>>>>>>>>>> apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>> 0f48%7Cf
>>>>>>>>
>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636452649612378558&sdata=
>>>>>>>> bRWKx
>>>>>>>>>>> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
>>>>>>>>>>>>
>>>>>>>>>>>> (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
>>>>>>>> <carlosrovira@apache.org
>>>>>>>>>>> <ma...@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.lists@gmail.com
>>>>>> <mailto:
>>>>>>>>>>> harbs.lists@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
>>>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>>>> <ma...@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
>>>>>>>>>>
>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> http%3A%2F%2Fabout.me%
>>>>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>> 0f48%7Cfa7b1
>>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>> sdata=C7a72gwfH2
>>>>>>>>>> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Carlos Rovira
>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> http%3A%2F%2Fabout.me%2
>>>>>>>>> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>>>> 0f48%7Cfa7b1b5
>>>>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>>>> sdata=C7a72gwfH264w
>>>>>>>>> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>> http%3A%2F%2Fwww.codeo
>>>>>>> scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
>>>>>> d8cf%7Cfa7b1b5a7b
>>>>>>> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>>>> sdata=Hm%2B6WIcqQTOHs0
>>>>>>> UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>>>>>> d8cf%7Cfa7b1b5a7b3
>>>>>>> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>>>> sdata=Hm%2B6WIcqQTOHs0U
>>>>>>> ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>>>>>> d8cf%7Cfa7b1b5a
>>>>>>> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>>>> sdata=b%2FFMr1Ajit94
>>>>>>> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>> http%3A%2F%2Fabout.me%2
>>>>> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
>>>> 82e0%7Cfa7b1b5
>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
>>>> sdata=wYPMWW1wpTbtm
>>>>> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> <http://www.codeoscopic.com>
>>>
>>> Carlos Rovira
>>>
>>> Director General
>>>
>>> M: +34 607 22 60 05
>>>
>>> http://www.codeoscopic.com
>>>
>>>
>>> Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
>>>
>>>
>>> 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.
>>
>>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
Re: Working on UI Controls styling
Posted by Piotr Zarzycki <pi...@gmail.com>.
I was thinking about that and new component set is the approach which we
should try, but we need to base on something. My first thoughts was that it
should be Basic, cause I bet that once we start create style for each
component we will end up with some issue or we would like to create some
additional features to those controls in order to make that theme happen.
It leads my thought then farther let's say that we will start work in
following way:
1) Basic is our base
2) Carlos will prepare some appearance for component
3) We are starting to work on that, but it's end up that our component need
some additional feature, which is do not suits for Basic
4) We are adds that feature to Express and use in that place Express
component.
It ends up that our component theme will be mix of Express and Basic
Second approach is - Forget about Express, use Basic only and add to Theme
set features if needed. Express will be always separate set, FAT and it
will be responsibility for user if he would like to style it. - If our
implementation will be in Theme enough robust, user should be able to use
in his application Express with some styles from Theme set.
Thoughts ?
Piotr
2017-11-05 11:21 GMT+01:00 Harbs <ha...@gmail.com>:
> I would suggest starting a new component set with a fresh slate called
> Themed (or something like that).
>
> The Themed component set should give priority to style-ablitity and ease
> of use over just about every other consideration. I think of Express as
> more of a middle-of the road approach to make things easier. A Themed set
> would be more of a replacement for mx and spark.
>
> Yes. Definitely make a clear list of supported components. It’s probably
> more important to have quality of components rather than quantity. A few
> well constructed components is better than a lot of half-baked ones. More
> components could always be added.
>
> I’m very glad to hear that Angelo is working with you. That’s great news!
>
> Harbs
>
> > On Nov 5, 2017, at 12:12 PM, Carlos Rovira <
> carlos.rovira@codeoscopic.com> wrote:
> >
> > ok Alex,
> >
> > so if I understand correctly, you mean that we create our own set, with
> > Basic as base right?
> > but we should go with Express? It's great that we could create many sets
> in
> > Royale, and I think the Basic use
> > you commented is very licit and didn't think about that. But we must
> think
> > in some *main* set, maybe is Express
> > and that I want to focus this effort for that concrete set.
> >
> > I mean, one important thing here is that we all agree in support a
> concrete
> > list of UI controls and components
> > I plan to make a discuss thread for this, since the theme feature will
> > affect only to that controls, and if we want to include a new one
> > we should vote to include it, since it implies to include in design,
> > implementation and all themes that we want to support.
> >
> > I think I'll create a discuss thread with this an other things we talked
> > about since this is a huge effort and is important for all the
> > people that will be involved to work around things discussed, voted and
> > approved by all.
> > We need to be synced here or we'll end working too much for somehitng
> that
> > does not get to be useful in the end. I want to ensure this before
> > to start investing a huge amount of time.
> >
> > As well I was contacted by Angelo and talk about all this. He's very
> > passionate as well on this and we'll seeing how we can combine our
> efforts
> > and if someone
> > more wants to join us.
> >
> > I'll be writing the discussion thread in order to plan the effort in
> short.
> > Stay tuned :)
> >
> > 2017-11-05 8:29 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >
> >> Hi Carlos,
> >>
> >> I think we're pretty much in agreement. Regarding Basic, for me, I have
> >> created plenty of web pages with non-styleable checkboxes. I don't care
> >> that the checkbox looks different on different browsers. I just want
> the
> >> smallest simplest output. Just like taking an HTML editor and slapping
> in
> >> a few tags and calling it done. Would that be production? Sure, if I'm
> >> just want someone to check a box before enabling a download button.
> IOW,
> >> it would be for internal customers only.
> >>
> >> So, IMO, a Skinnable/Themeable component set would be something else. I
> >> think you will need that extra Span for a Checkbox. IMO, we should just
> >> go and build these new components. And when we get it mostly working,
> we
> >> can compare against Basic and see if we want to parameterize the views
> in
> >> the low-level Basic components or not.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira"
> >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
> >>
> >>> HI Alex,
> >>>
> >>>
> >>> 2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >>>
> >>>> Hi Carlos,
> >>>>
> >>>> I skimmed through
> >>>> https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fmaterial
> >>>> .io%2Fguidelines%2F%23&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
> >> 82e0
> >>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636454056000808812&sdata=g5
> >>>> M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last
> night.
> >>>>
> >>>> My impression is that there were two parts to it. First was the
> >>>> environment/principles section which talked about physical objects and
> >>>> light (and motion), and then there were choices of widgets. For
> >>>> example,
> >>>> I didn't see anything in the first part that said that a text input
> had
> >>>> to
> >>>> be a single line and couldn't be a box.
> >>>>
> >>>
> >>> Material guidelines could be a great way to start, but trying to give
> >>> something different.
> >>> I think that we need to get something that looks great while be clearly
> >>> different to google material,
> >>> bootstrap, and others so people could see us as an alternative. That
> could
> >>> make people copying us
> >>> or adopting the whole Apache Royale SDK that is what we want in the end
> >>>
> >>>
> >>>
> >>>>
> >>>> That made me think that we could use our widget set and apply Material
> >>>> environment and principles to it. If we decide not to, I would think
> >>>> you
> >>>> would want to have some sort of similar environment/principles
> document
> >>>> which seems like a fair amount of work. I think we'd end up looking
> >>>> different because we have different widgets and maybe some different
> >>>> colors. I'm pretty sure that we don't want to be different so much
> that
> >>>> we don't create things that folks want to use. The priority to me is
> >>>> just
> >>>> to prove that you can alter every pixel in every widget we have so
> that
> >>>> others can provide custom skins as well. So starting with Material
> >>>> principles seems like it would save us time, we can get something
> >>>> released, and can innovate more later.
> >>>>
> >>>
> >>> I think as you that we need a way to make the "presentation" of each
> >>> component highly customizable.
> >>> And we need to be different in visualization (art, colors, ...) but
> not in
> >>> usability that is what people
> >>> needs to be consistently
> >>>
> >>>
> >>>
> >>>>
> >>>> Maybe a good question for our users is: How many of you used the
> >>>> default
> >>>> Flex skins vs a whole new set of skins? If most folks completely
> >>>> re-skinned to match their corporate branding, it matters less what our
> >>>> default is, and more that we can allow folks to customize every pixel.
> >>>>
> >>>>
> >>> We need both: a skin that will be highly customizable and to change
> skins
> >>> to look very very different.
> >>> People with lees money or time in their Apps will choose the first.
> People
> >>> that has more resources will go with the second.
> >>> Apache Royale needs to support both
> >>>
> >>>
> >>>> The wireframe can be black and white, IMO. I was thinking that
> "vivid"
> >>>> would have parameterized colors.
> >>>>
> >>>>
> >>> I started to think that wireframe could end having lots of
> customization
> >>> controls. For example:
> >>>
> >>> -2-3 main colors as we talked , and the same MDL does
> >>> -possibilitiy to be solid colors, or gradients
> >>> -possibility to have backgrounds more or less opaque
> >>>
> >>> if we see a concrete component like button:
> >>>
> >>> - configurable corners, square to round corners
> >>> - more blocky (relief) or more flat
> >>> ...
> >>>
> >>> So wireframe could be a concrete configuration of the main theme
> >>>
> >>>
> >>>
> >>>> Since Bootstrap was mentioned, I want to point out that the Flat.swc
> is
> >>>> a
> >>>> rough approximation of the Flat theme which is a Bootstrap theme. It
> >>>> is a
> >>>> rough approximation because I could not use the Flat CSS file directly
> >>>> since it contains much more advanced CSS than we currently support on
> >>>> the
> >>>> SWF side. But it presumed that the Checkbox was a Label with a Span
> >>>> that
> >>>> hides in front of or behind the <input type="check" /> in order to
> allow
> >>>> customizing every pixel. Looks like MDL uses the same Span trick but
> >>>> maybe without a symbol font.
> >>>>
> >>>> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
> >>>> should
> >>>> not have that extra Span. But it looks to me that a SkinnableCheckbox
> >>>> can
> >>>> add that extra Span and you either give it the same class name that
> >>>> BootStrap or MDL uses or create our own set of classnames and the CSS
> >>>> that
> >>>> goes with it.
> >>>>
> >>>>
> >>> The problem with Basic could be that if is very very basic and looks
> with
> >>> a
> >>> very basic look (as it is very poorly stylizable), I think
> >>> People will not use it at all, in this case, I'll don't understand the
> >>> goal
> >>> with basic. It's intend ended as a base
> >>> but to not use in production? For this reason is what I want to know if
> >>> you
> >>> think this theme feature could be plugged in basic or not.
> >>>
> >>>
> >>>
> >>>
> >>>> Of course, I could be wrong. This is not my area of expertise at all.
> >>>>
> >>>
> >>> Hi Alex, maybe UX is not your expertise area, but your help here is
> very
> >>> needed since we can get to great ideas in this field, but
> >>> maybe don't know how to bring it to implementation in Apache Royale. I
> >>> think that you, Peter, Harbs,... are needed in order to
> >>> make this happen in the pure arquitecture side or this feature.
> >>>
> >>> Thanks
> >>>
> >>> -Alex
> >>>>
> >>>>
> >>>> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
> >>>> Rovira"
> >>>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> >>>> wrote:
> >>>>
> >>>>> Hi Alex,
> >>>>>
> >>>>> 2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >>>>>
> >>>>>> Hi Carlos,
> >>>>>>
> >>>>>> Looks good to me. Thanks for doing this.
> >>>>>>
> >>>>>
> >>>>> Thanks :)
> >>>>>
> >>>>>>
> >>>>>> I'm not sure I understand all of the aspects of this effort. My
> >>>> current
> >>>>>> understanding is that Google Material is under the Apache License
> and
> >>>>>> thus
> >>>>>> we can use it if we want to. Am I correct that MaterialDesignLite
> is
> >>>>>> one
> >>>>>> implementation of Google Material and we could create our own
> >>>>>> implementation and it could be visually different?
> >>>>>>
> >>>>>
> >>>>> We can implement our own material in Royale, but I'm afraid that
> doing
> >>>>> that
> >>>>> will not make us
> >>>>> highlight our solution against the rest of competitors. Another point
> >>>> is
> >>>>> something I said various times:
> >>>>> When I did MDL, I notice a huge problem: MDL has its own set of
> >>>>> components,
> >>>>> some are in all sets (Button)
> >>>>> but others not (Card), and they has it's own implementation, what
> make
> >>>> it
> >>>>> almost impossible generalize
> >>>>> a theme. For this reason I always point that we need our own set and
> >>>> there
> >>>>> we can implement themes. But other
> >>>>> *externa* sets will never get this since they have its own
> >>>> implementation
> >>>>> and most important once you start to develop
> >>>>> with MDL you can't go back and change for other. So MDL is for me
> >>>>> something
> >>>>> we have until our own set are robust and
> >>>>> highly configurable in both the things we can do and how can it could
> >>>> be
> >>>>> represented, and switch between style should be
> >>>>> really easy to change the global look of an App without much hassle.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Also, IIRC, Material has different components than Flex did so we'd
> >>>> have
> >>>>>> to invent some new looks anyway. So having a TextInput with borders
> >>>> all
> >>>>>> around would just be our flavor of Material.
> >>>>>>
> >>>>>
> >>>>> That's what I point above. We must to *freeze* the list of components
> >>>> at
> >>>>> some time work over a concrete set
> >>>>> We can then plan in the future include a new component in the
> official
> >>>>> set,
> >>>>> and that will need to work on the themes we already
> >>>>> have to include the new one.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Regarding colors, it looks like Material is parameterized around a
> >>>>>> couple
> >>>>>> of colors. So if we did our skins to work against parameterized
> >>>> colors
> >>>>>> then would it really matter what color we choose?
> >>>>>>
> >>>>>
> >>>>> That's completly right. I could make wireframe based on two or three
> >>>>> colors
> >>>>> and as you change it in CSS all controls should tint
> >>>>> consistently.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Regarding Basic components, right now Checkbox is a <label><input
> >>>>>> type="check"/>caption</label>. AIUI, you cannot style the <input>
> on
> >>>>>> many
> >>>>>> browsers, so I think we have to have a different set of elements in
> a
> >>>>>> checkbox. It looks like Bootstrap uses:
> >>>>>>
> >>>>>> <label><input type="check"/><span />Caption</label>
> >>>>>>
> >>>>>> Where the span uses a special symbol font with checked and unchecked
> >>>>>> boxes.
> >>>>>>
> >>>>>
> >>>>> That's what we need to figure. Should we make themes available in
> >>>> Basic?
> >>>>> if
> >>>>> so, has basic the right implementation?
> >>>>> If not, and if we don't want to change the actual very basic
> >>>>> implementation, we need to put some "skin" implementation
> >>>>> that at least in JS implementation I figure that will change one face
> >>>> (the
> >>>>> actual basic) with the theme face.
> >>>>>
> >>>>> I'm thinking loud, since this is something we should explorer all
> >>>> together
> >>>>> mixing the best ideas of people involved
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Alex
> >>>>>>
> >>>>>> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos
> >>>>>> Rovira"
> >>>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> >> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I want to expose my initial work (very very initial) on two styles
> >>>> for
> >>>>>>> Royale
> >>>>>>>
> >>>>>>>
> >>>>>>> Wireframe:
> >>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>> https%3A%2F%2Fsnag.gy%2
> >>>>>>> FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>> 0f48%7Cfa7b1b5a7
> >>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>> sdata=%2Fk8YQxC5bDOaC
> >>>>>>> D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
> >>>>>>>
> >>>>>>> (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://na01.safelinks.protection.outlook.com/?url=
> >>>>>> https%3A%2F%2Fsnag.gy%2
> >>>>>>> FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>> 0f48%7Cfa7b1b5a7
> >>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>> sdata=kxYE7ylOsXPUEeE
> >>>>>>> r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
> >>>>>>>
> >>>>>>> (*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 <carlosrovira@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 <ha...@gmail.com>:
> >>>>>>>>
> >>>>>>>>> BTW, the kind of thing we should be striving for in theme-able
> >>>>>>>>> components
> >>>>>>>>> is something like this:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>> https%3A%2F%2Fvcalend
> >>>>>>>>> ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>> 0f48%7Cf
> >>>>>>
> >>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636452649612378558&sdata=
> >>>>>> b3VtV
> >>>>>>>>> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
> >>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>>>> https%3A%2F%2Fvcalen
> >>>>>>>>> dar.netlify.com%2F&data=02%7C01%7C%
> 7C203485b5b9c744aed92608d52250
> >>>>>> 0f48%7C
> >>>>>>
> >>>>>>> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636452649612378558&sdata=
> >>>>>> b3Vt
> >>>>>>>>> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
> >>>>>>>>>
> >>>>>>>>>> On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
> >>>>>> https%3A%2F%2Fpaste.a
> >>>>>>>>> pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>> 0f48%7Cfa
> >>>>>>>>> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>> sdata=bRWKxm
> >>>>>>>>> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
> >>>>>>
> >>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>> https%3A%2F%2Fpast
> >>>>>>>>> e
> >>>>>> .
> >>>>>>>>> apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>> 0f48%7Cf
> >>>>>>
> >>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636452649612378558&sdata=
> >>>>>> bRWKx
> >>>>>>>>> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
> >>>>>>>>>>
> >>>>>>>>>> (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
> >>>>>> <carlosrovira@apache.org
> >>>>>>>>> <ma...@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.lists@gmail.com
> >>>> <mailto:
> >>>>>>>>> harbs.lists@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
> >>>>>> <aharui@adobe.com.INVALID
> >>>>>>>>> <ma...@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
> >>>>>>>>
> >>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>> http%3A%2F%2Fabout.me%
> >>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>> 0f48%7Cfa7b1
> >>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>> sdata=C7a72gwfH2
> >>>>>>>> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Carlos Rovira
> >>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>> http%3A%2F%2Fabout.me%2
> >>>>>>> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >>>>>> 0f48%7Cfa7b1b5
> >>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >>>>>> sdata=C7a72gwfH264w
> >>>>>>> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>> http%3A%2F%2Fwww.codeo
> >>>>> scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
> >>>> d8cf%7Cfa7b1b5a7b
> >>>>> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> >>>> sdata=Hm%2B6WIcqQTOHs0
> >>>>> UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> >>>> d8cf%7Cfa7b1b5a7b3
> >>>>> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> >>>> sdata=Hm%2B6WIcqQTOHs0U
> >>>>> ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> >>>> d8cf%7Cfa7b1b5a
> >>>>> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> >>>> sdata=b%2FFMr1Ajit94
> >>>>> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Carlos Rovira
> >>> https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%2
> >>> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
> >> 82e0%7Cfa7b1b5
> >>> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
> >> sdata=wYPMWW1wpTbtm
> >>> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
> >>
> >>
> >
> >
> > --
> >
> > <http://www.codeoscopic.com>
> >
> > Carlos Rovira
> >
> > Director General
> >
> > M: +34 607 22 60 05
> >
> > http://www.codeoscopic.com
> >
> >
> > Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
> >
> >
> > 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.
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
I would suggest starting a new component set with a fresh slate called Themed (or something like that).
The Themed component set should give priority to style-ablitity and ease of use over just about every other consideration. I think of Express as more of a middle-of the road approach to make things easier. A Themed set would be more of a replacement for mx and spark.
Yes. Definitely make a clear list of supported components. It’s probably more important to have quality of components rather than quantity. A few well constructed components is better than a lot of half-baked ones. More components could always be added.
I’m very glad to hear that Angelo is working with you. That’s great news!
Harbs
> On Nov 5, 2017, at 12:12 PM, Carlos Rovira <ca...@codeoscopic.com> wrote:
>
> ok Alex,
>
> so if I understand correctly, you mean that we create our own set, with
> Basic as base right?
> but we should go with Express? It's great that we could create many sets in
> Royale, and I think the Basic use
> you commented is very licit and didn't think about that. But we must think
> in some *main* set, maybe is Express
> and that I want to focus this effort for that concrete set.
>
> I mean, one important thing here is that we all agree in support a concrete
> list of UI controls and components
> I plan to make a discuss thread for this, since the theme feature will
> affect only to that controls, and if we want to include a new one
> we should vote to include it, since it implies to include in design,
> implementation and all themes that we want to support.
>
> I think I'll create a discuss thread with this an other things we talked
> about since this is a huge effort and is important for all the
> people that will be involved to work around things discussed, voted and
> approved by all.
> We need to be synced here or we'll end working too much for somehitng that
> does not get to be useful in the end. I want to ensure this before
> to start investing a huge amount of time.
>
> As well I was contacted by Angelo and talk about all this. He's very
> passionate as well on this and we'll seeing how we can combine our efforts
> and if someone
> more wants to join us.
>
> I'll be writing the discussion thread in order to plan the effort in short.
> Stay tuned :)
>
> 2017-11-05 8:29 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> Hi Carlos,
>>
>> I think we're pretty much in agreement. Regarding Basic, for me, I have
>> created plenty of web pages with non-styleable checkboxes. I don't care
>> that the checkbox looks different on different browsers. I just want the
>> smallest simplest output. Just like taking an HTML editor and slapping in
>> a few tags and calling it done. Would that be production? Sure, if I'm
>> just want someone to check a box before enabling a download button. IOW,
>> it would be for internal customers only.
>>
>> So, IMO, a Skinnable/Themeable component set would be something else. I
>> think you will need that extra Span for a Checkbox. IMO, we should just
>> go and build these new components. And when we get it mostly working, we
>> can compare against Basic and see if we want to parameterize the views in
>> the low-level Basic components or not.
>>
>> My 2 cents,
>> -Alex
>>
>> On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>
>>> HI Alex,
>>>
>>>
>>> 2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>
>>>> Hi Carlos,
>>>>
>>>> I skimmed through
>>>> https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fmaterial
>>>> .io%2Fguidelines%2F%23&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
>> 82e0
>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636454056000808812&sdata=g5
>>>> M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last night.
>>>>
>>>> My impression is that there were two parts to it. First was the
>>>> environment/principles section which talked about physical objects and
>>>> light (and motion), and then there were choices of widgets. For
>>>> example,
>>>> I didn't see anything in the first part that said that a text input had
>>>> to
>>>> be a single line and couldn't be a box.
>>>>
>>>
>>> Material guidelines could be a great way to start, but trying to give
>>> something different.
>>> I think that we need to get something that looks great while be clearly
>>> different to google material,
>>> bootstrap, and others so people could see us as an alternative. That could
>>> make people copying us
>>> or adopting the whole Apache Royale SDK that is what we want in the end
>>>
>>>
>>>
>>>>
>>>> That made me think that we could use our widget set and apply Material
>>>> environment and principles to it. If we decide not to, I would think
>>>> you
>>>> would want to have some sort of similar environment/principles document
>>>> which seems like a fair amount of work. I think we'd end up looking
>>>> different because we have different widgets and maybe some different
>>>> colors. I'm pretty sure that we don't want to be different so much that
>>>> we don't create things that folks want to use. The priority to me is
>>>> just
>>>> to prove that you can alter every pixel in every widget we have so that
>>>> others can provide custom skins as well. So starting with Material
>>>> principles seems like it would save us time, we can get something
>>>> released, and can innovate more later.
>>>>
>>>
>>> I think as you that we need a way to make the "presentation" of each
>>> component highly customizable.
>>> And we need to be different in visualization (art, colors, ...) but not in
>>> usability that is what people
>>> needs to be consistently
>>>
>>>
>>>
>>>>
>>>> Maybe a good question for our users is: How many of you used the
>>>> default
>>>> Flex skins vs a whole new set of skins? If most folks completely
>>>> re-skinned to match their corporate branding, it matters less what our
>>>> default is, and more that we can allow folks to customize every pixel.
>>>>
>>>>
>>> We need both: a skin that will be highly customizable and to change skins
>>> to look very very different.
>>> People with lees money or time in their Apps will choose the first. People
>>> that has more resources will go with the second.
>>> Apache Royale needs to support both
>>>
>>>
>>>> The wireframe can be black and white, IMO. I was thinking that "vivid"
>>>> would have parameterized colors.
>>>>
>>>>
>>> I started to think that wireframe could end having lots of customization
>>> controls. For example:
>>>
>>> -2-3 main colors as we talked , and the same MDL does
>>> -possibilitiy to be solid colors, or gradients
>>> -possibility to have backgrounds more or less opaque
>>>
>>> if we see a concrete component like button:
>>>
>>> - configurable corners, square to round corners
>>> - more blocky (relief) or more flat
>>> ...
>>>
>>> So wireframe could be a concrete configuration of the main theme
>>>
>>>
>>>
>>>> Since Bootstrap was mentioned, I want to point out that the Flat.swc is
>>>> a
>>>> rough approximation of the Flat theme which is a Bootstrap theme. It
>>>> is a
>>>> rough approximation because I could not use the Flat CSS file directly
>>>> since it contains much more advanced CSS than we currently support on
>>>> the
>>>> SWF side. But it presumed that the Checkbox was a Label with a Span
>>>> that
>>>> hides in front of or behind the <input type="check" /> in order to allow
>>>> customizing every pixel. Looks like MDL uses the same Span trick but
>>>> maybe without a symbol font.
>>>>
>>>> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
>>>> should
>>>> not have that extra Span. But it looks to me that a SkinnableCheckbox
>>>> can
>>>> add that extra Span and you either give it the same class name that
>>>> BootStrap or MDL uses or create our own set of classnames and the CSS
>>>> that
>>>> goes with it.
>>>>
>>>>
>>> The problem with Basic could be that if is very very basic and looks with
>>> a
>>> very basic look (as it is very poorly stylizable), I think
>>> People will not use it at all, in this case, I'll don't understand the
>>> goal
>>> with basic. It's intend ended as a base
>>> but to not use in production? For this reason is what I want to know if
>>> you
>>> think this theme feature could be plugged in basic or not.
>>>
>>>
>>>
>>>
>>>> Of course, I could be wrong. This is not my area of expertise at all.
>>>>
>>>
>>> Hi Alex, maybe UX is not your expertise area, but your help here is very
>>> needed since we can get to great ideas in this field, but
>>> maybe don't know how to bring it to implementation in Apache Royale. I
>>> think that you, Peter, Harbs,... are needed in order to
>>> make this happen in the pure arquitecture side or this feature.
>>>
>>> Thanks
>>>
>>> -Alex
>>>>
>>>>
>>>> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>>> Rovira"
>>>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>>>> wrote:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>> 2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>>
>>>>>> Hi Carlos,
>>>>>>
>>>>>> Looks good to me. Thanks for doing this.
>>>>>>
>>>>>
>>>>> Thanks :)
>>>>>
>>>>>>
>>>>>> I'm not sure I understand all of the aspects of this effort. My
>>>> current
>>>>>> understanding is that Google Material is under the Apache License and
>>>>>> thus
>>>>>> we can use it if we want to. Am I correct that MaterialDesignLite is
>>>>>> one
>>>>>> implementation of Google Material and we could create our own
>>>>>> implementation and it could be visually different?
>>>>>>
>>>>>
>>>>> We can implement our own material in Royale, but I'm afraid that doing
>>>>> that
>>>>> will not make us
>>>>> highlight our solution against the rest of competitors. Another point
>>>> is
>>>>> something I said various times:
>>>>> When I did MDL, I notice a huge problem: MDL has its own set of
>>>>> components,
>>>>> some are in all sets (Button)
>>>>> but others not (Card), and they has it's own implementation, what make
>>>> it
>>>>> almost impossible generalize
>>>>> a theme. For this reason I always point that we need our own set and
>>>> there
>>>>> we can implement themes. But other
>>>>> *externa* sets will never get this since they have its own
>>>> implementation
>>>>> and most important once you start to develop
>>>>> with MDL you can't go back and change for other. So MDL is for me
>>>>> something
>>>>> we have until our own set are robust and
>>>>> highly configurable in both the things we can do and how can it could
>>>> be
>>>>> represented, and switch between style should be
>>>>> really easy to change the global look of an App without much hassle.
>>>>>
>>>>>
>>>>>>
>>>>>> Also, IIRC, Material has different components than Flex did so we'd
>>>> have
>>>>>> to invent some new looks anyway. So having a TextInput with borders
>>>> all
>>>>>> around would just be our flavor of Material.
>>>>>>
>>>>>
>>>>> That's what I point above. We must to *freeze* the list of components
>>>> at
>>>>> some time work over a concrete set
>>>>> We can then plan in the future include a new component in the official
>>>>> set,
>>>>> and that will need to work on the themes we already
>>>>> have to include the new one.
>>>>>
>>>>>
>>>>>>
>>>>>> Regarding colors, it looks like Material is parameterized around a
>>>>>> couple
>>>>>> of colors. So if we did our skins to work against parameterized
>>>> colors
>>>>>> then would it really matter what color we choose?
>>>>>>
>>>>>
>>>>> That's completly right. I could make wireframe based on two or three
>>>>> colors
>>>>> and as you change it in CSS all controls should tint
>>>>> consistently.
>>>>>
>>>>>
>>>>>>
>>>>>> Regarding Basic components, right now Checkbox is a <label><input
>>>>>> type="check"/>caption</label>. AIUI, you cannot style the <input> on
>>>>>> many
>>>>>> browsers, so I think we have to have a different set of elements in a
>>>>>> checkbox. It looks like Bootstrap uses:
>>>>>>
>>>>>> <label><input type="check"/><span />Caption</label>
>>>>>>
>>>>>> Where the span uses a special symbol font with checked and unchecked
>>>>>> boxes.
>>>>>>
>>>>>
>>>>> That's what we need to figure. Should we make themes available in
>>>> Basic?
>>>>> if
>>>>> so, has basic the right implementation?
>>>>> If not, and if we don't want to change the actual very basic
>>>>> implementation, we need to put some "skin" implementation
>>>>> that at least in JS implementation I figure that will change one face
>>>> (the
>>>>> actual basic) with the theme face.
>>>>>
>>>>> I'm thinking loud, since this is something we should explorer all
>>>> together
>>>>> mixing the best ideas of people involved
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Alex
>>>>>>
>>>>>> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos
>>>>>> Rovira"
>>>>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I want to expose my initial work (very very initial) on two styles
>>>> for
>>>>>>> Royale
>>>>>>>
>>>>>>>
>>>>>>> Wireframe:
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>> https%3A%2F%2Fsnag.gy%2
>>>>>>> FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>> 0f48%7Cfa7b1b5a7
>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>> sdata=%2Fk8YQxC5bDOaC
>>>>>>> D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
>>>>>>>
>>>>>>> (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://na01.safelinks.protection.outlook.com/?url=
>>>>>> https%3A%2F%2Fsnag.gy%2
>>>>>>> FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>> 0f48%7Cfa7b1b5a7
>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>> sdata=kxYE7ylOsXPUEeE
>>>>>>> r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
>>>>>>>
>>>>>>> (*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 <ca...@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 <ha...@gmail.com>:
>>>>>>>>
>>>>>>>>> BTW, the kind of thing we should be striving for in theme-able
>>>>>>>>> components
>>>>>>>>> is something like this:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>> https%3A%2F%2Fvcalend
>>>>>>>>> ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>> 0f48%7Cf
>>>>>>
>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
>>>>>> b3VtV
>>>>>>>>> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>> https%3A%2F%2Fvcalen
>>>>>>>>> dar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>> 0f48%7C
>>>>>>
>>>>>>> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
>>>>>> b3Vt
>>>>>>>>> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
>>>>>>>>>
>>>>>>>>>> On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
>>>>>> https%3A%2F%2Fpaste.a
>>>>>>>>> pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>> 0f48%7Cfa
>>>>>>>>> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>> sdata=bRWKxm
>>>>>>>>> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
>>>>>>
>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>> https%3A%2F%2Fpast
>>>>>>>>> e
>>>>>> .
>>>>>>>>> apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>> 0f48%7Cf
>>>>>>
>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
>>>>>> bRWKx
>>>>>>>>> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
>>>>>>>>>>
>>>>>>>>>> (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
>>>>>> <carlosrovira@apache.org
>>>>>>>>> <ma...@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.lists@gmail.com
>>>> <mailto:
>>>>>>>>> harbs.lists@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
>>>>>> <aharui@adobe.com.INVALID
>>>>>>>>> <ma...@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
>>>>>>>>
>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>> http%3A%2F%2Fabout.me%
>>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>> 0f48%7Cfa7b1
>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>> sdata=C7a72gwfH2
>>>>>>>> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carlos Rovira
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>> http%3A%2F%2Fabout.me%2
>>>>>>> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>>>>>> 0f48%7Cfa7b1b5
>>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>>>>>> sdata=C7a72gwfH264w
>>>>>>> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>> http%3A%2F%2Fwww.codeo
>>>>> scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
>>>> d8cf%7Cfa7b1b5a7b
>>>>> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>> sdata=Hm%2B6WIcqQTOHs0
>>>>> UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>>>> d8cf%7Cfa7b1b5a7b3
>>>>> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>> sdata=Hm%2B6WIcqQTOHs0U
>>>>> ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>>>> d8cf%7Cfa7b1b5a
>>>>> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>>>> sdata=b%2FFMr1Ajit94
>>>>> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
>>>>
>>>>
>>>
>>>
>>> --
>>> Carlos Rovira
>>> https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>>> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
>> 82e0%7Cfa7b1b5
>>> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
>> sdata=wYPMWW1wpTbtm
>>> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
>>
>>
>
>
> --
>
> <http://www.codeoscopic.com>
>
> Carlos Rovira
>
> Director General
>
> M: +34 607 22 60 05
>
> http://www.codeoscopic.com
>
>
> Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
>
>
> 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: Working on UI Controls styling
Posted by Carlos Rovira <ca...@codeoscopic.com>.
ok Alex,
so if I understand correctly, you mean that we create our own set, with
Basic as base right?
but we should go with Express? It's great that we could create many sets in
Royale, and I think the Basic use
you commented is very licit and didn't think about that. But we must think
in some *main* set, maybe is Express
and that I want to focus this effort for that concrete set.
I mean, one important thing here is that we all agree in support a concrete
list of UI controls and components
I plan to make a discuss thread for this, since the theme feature will
affect only to that controls, and if we want to include a new one
we should vote to include it, since it implies to include in design,
implementation and all themes that we want to support.
I think I'll create a discuss thread with this an other things we talked
about since this is a huge effort and is important for all the
people that will be involved to work around things discussed, voted and
approved by all.
We need to be synced here or we'll end working too much for somehitng that
does not get to be useful in the end. I want to ensure this before
to start investing a huge amount of time.
As well I was contacted by Angelo and talk about all this. He's very
passionate as well on this and we'll seeing how we can combine our efforts
and if someone
more wants to join us.
I'll be writing the discussion thread in order to plan the effort in short.
Stay tuned :)
2017-11-05 8:29 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> Hi Carlos,
>
> I think we're pretty much in agreement. Regarding Basic, for me, I have
> created plenty of web pages with non-styleable checkboxes. I don't care
> that the checkbox looks different on different browsers. I just want the
> smallest simplest output. Just like taking an HTML editor and slapping in
> a few tags and calling it done. Would that be production? Sure, if I'm
> just want someone to check a box before enabling a download button. IOW,
> it would be for internal customers only.
>
> So, IMO, a Skinnable/Themeable component set would be something else. I
> think you will need that extra Span for a Checkbox. IMO, we should just
> go and build these new components. And when we get it mostly working, we
> can compare against Basic and see if we want to parameterize the views in
> the low-level Basic components or not.
>
> My 2 cents,
> -Alex
>
> On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >HI Alex,
> >
> >
> >2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >
> >> Hi Carlos,
> >>
> >> I skimmed through
> >>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fmaterial
> >>.io%2Fguidelines%2F%23&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
> 82e0
> >>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636454056000808812&sdata=g5
> >>M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last night.
> >>
> >> My impression is that there were two parts to it. First was the
> >> environment/principles section which talked about physical objects and
> >> light (and motion), and then there were choices of widgets. For
> >>example,
> >> I didn't see anything in the first part that said that a text input had
> >>to
> >> be a single line and couldn't be a box.
> >>
> >
> >Material guidelines could be a great way to start, but trying to give
> >something different.
> >I think that we need to get something that looks great while be clearly
> >different to google material,
> >bootstrap, and others so people could see us as an alternative. That could
> >make people copying us
> >or adopting the whole Apache Royale SDK that is what we want in the end
> >
> >
> >
> >>
> >> That made me think that we could use our widget set and apply Material
> >> environment and principles to it. If we decide not to, I would think
> >>you
> >> would want to have some sort of similar environment/principles document
> >> which seems like a fair amount of work. I think we'd end up looking
> >> different because we have different widgets and maybe some different
> >> colors. I'm pretty sure that we don't want to be different so much that
> >> we don't create things that folks want to use. The priority to me is
> >>just
> >> to prove that you can alter every pixel in every widget we have so that
> >> others can provide custom skins as well. So starting with Material
> >> principles seems like it would save us time, we can get something
> >> released, and can innovate more later.
> >>
> >
> >I think as you that we need a way to make the "presentation" of each
> >component highly customizable.
> >And we need to be different in visualization (art, colors, ...) but not in
> >usability that is what people
> >needs to be consistently
> >
> >
> >
> >>
> >> Maybe a good question for our users is: How many of you used the
> >>default
> >> Flex skins vs a whole new set of skins? If most folks completely
> >> re-skinned to match their corporate branding, it matters less what our
> >> default is, and more that we can allow folks to customize every pixel.
> >>
> >>
> >We need both: a skin that will be highly customizable and to change skins
> >to look very very different.
> >People with lees money or time in their Apps will choose the first. People
> >that has more resources will go with the second.
> >Apache Royale needs to support both
> >
> >
> >> The wireframe can be black and white, IMO. I was thinking that "vivid"
> >> would have parameterized colors.
> >>
> >>
> >I started to think that wireframe could end having lots of customization
> >controls. For example:
> >
> >-2-3 main colors as we talked , and the same MDL does
> >-possibilitiy to be solid colors, or gradients
> >-possibility to have backgrounds more or less opaque
> >
> >if we see a concrete component like button:
> >
> >- configurable corners, square to round corners
> >- more blocky (relief) or more flat
> >...
> >
> >So wireframe could be a concrete configuration of the main theme
> >
> >
> >
> >> Since Bootstrap was mentioned, I want to point out that the Flat.swc is
> >>a
> >> rough approximation of the Flat theme which is a Bootstrap theme. It
> >>is a
> >> rough approximation because I could not use the Flat CSS file directly
> >> since it contains much more advanced CSS than we currently support on
> >>the
> >> SWF side. But it presumed that the Checkbox was a Label with a Span
> >>that
> >> hides in front of or behind the <input type="check" /> in order to allow
> >> customizing every pixel. Looks like MDL uses the same Span trick but
> >> maybe without a symbol font.
> >>
> >> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
> >>should
> >> not have that extra Span. But it looks to me that a SkinnableCheckbox
> >>can
> >> add that extra Span and you either give it the same class name that
> >> BootStrap or MDL uses or create our own set of classnames and the CSS
> >>that
> >> goes with it.
> >>
> >>
> >The problem with Basic could be that if is very very basic and looks with
> >a
> >very basic look (as it is very poorly stylizable), I think
> >People will not use it at all, in this case, I'll don't understand the
> >goal
> >with basic. It's intend ended as a base
> >but to not use in production? For this reason is what I want to know if
> >you
> >think this theme feature could be plugged in basic or not.
> >
> >
> >
> >
> >> Of course, I could be wrong. This is not my area of expertise at all.
> >>
> >
> >Hi Alex, maybe UX is not your expertise area, but your help here is very
> >needed since we can get to great ideas in this field, but
> >maybe don't know how to bring it to implementation in Apache Royale. I
> >think that you, Peter, Harbs,... are needed in order to
> >make this happen in the pure arquitecture side or this feature.
> >
> >Thanks
> >
> >-Alex
> >>
> >>
> >> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
> >>Rovira"
> >> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> >> wrote:
> >>
> >> >Hi Alex,
> >> >
> >> >2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >> >
> >> >> Hi Carlos,
> >> >>
> >> >> Looks good to me. Thanks for doing this.
> >> >>
> >> >
> >> >Thanks :)
> >> >
> >> >>
> >> >> I'm not sure I understand all of the aspects of this effort. My
> >>current
> >> >> understanding is that Google Material is under the Apache License and
> >> >>thus
> >> >> we can use it if we want to. Am I correct that MaterialDesignLite is
> >> >>one
> >> >> implementation of Google Material and we could create our own
> >> >> implementation and it could be visually different?
> >> >>
> >> >
> >> >We can implement our own material in Royale, but I'm afraid that doing
> >> >that
> >> >will not make us
> >> >highlight our solution against the rest of competitors. Another point
> >>is
> >> >something I said various times:
> >> >When I did MDL, I notice a huge problem: MDL has its own set of
> >> >components,
> >> >some are in all sets (Button)
> >> >but others not (Card), and they has it's own implementation, what make
> >>it
> >> >almost impossible generalize
> >> >a theme. For this reason I always point that we need our own set and
> >>there
> >> >we can implement themes. But other
> >> >*externa* sets will never get this since they have its own
> >>implementation
> >> >and most important once you start to develop
> >> >with MDL you can't go back and change for other. So MDL is for me
> >> >something
> >> >we have until our own set are robust and
> >> >highly configurable in both the things we can do and how can it could
> >>be
> >> >represented, and switch between style should be
> >> >really easy to change the global look of an App without much hassle.
> >> >
> >> >
> >> >>
> >> >> Also, IIRC, Material has different components than Flex did so we'd
> >>have
> >> >> to invent some new looks anyway. So having a TextInput with borders
> >>all
> >> >> around would just be our flavor of Material.
> >> >>
> >> >
> >> >That's what I point above. We must to *freeze* the list of components
> >>at
> >> >some time work over a concrete set
> >> >We can then plan in the future include a new component in the official
> >> >set,
> >> >and that will need to work on the themes we already
> >> >have to include the new one.
> >> >
> >> >
> >> >>
> >> >> Regarding colors, it looks like Material is parameterized around a
> >> >>couple
> >> >> of colors. So if we did our skins to work against parameterized
> >>colors
> >> >> then would it really matter what color we choose?
> >> >>
> >> >
> >> >That's completly right. I could make wireframe based on two or three
> >> >colors
> >> >and as you change it in CSS all controls should tint
> >> >consistently.
> >> >
> >> >
> >> >>
> >> >> Regarding Basic components, right now Checkbox is a <label><input
> >> >> type="check"/>caption</label>. AIUI, you cannot style the <input> on
> >> >>many
> >> >> browsers, so I think we have to have a different set of elements in a
> >> >> checkbox. It looks like Bootstrap uses:
> >> >>
> >> >> <label><input type="check"/><span />Caption</label>
> >> >>
> >> >> Where the span uses a special symbol font with checked and unchecked
> >> >>boxes.
> >> >>
> >> >
> >> >That's what we need to figure. Should we make themes available in
> >>Basic?
> >> >if
> >> >so, has basic the right implementation?
> >> >If not, and if we don't want to change the actual very basic
> >> >implementation, we need to put some "skin" implementation
> >> >that at least in JS implementation I figure that will change one face
> >>(the
> >> >actual basic) with the theme face.
> >> >
> >> >I'm thinking loud, since this is something we should explorer all
> >>together
> >> >mixing the best ideas of people involved
> >> >
> >> >Thanks
> >> >
> >> >
> >> >
> >> >>
> >> >> Thanks,
> >> >> Alex
> >> >>
> >> >> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos
> >> >>Rovira"
> >> >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> wrote:
> >> >>
> >> >> >Hi,
> >> >> >
> >> >> >I want to expose my initial work (very very initial) on two styles
> >>for
> >> >> >Royale
> >> >> >
> >> >> >
> >> >> >Wireframe:
> >> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> >> https%3A%2F%2Fsnag.gy%2
> >> >> >FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> >> 0f48%7Cfa7b1b5a7
> >> >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> >> sdata=%2Fk8YQxC5bDOaC
> >> >> >D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
> >> >> >
> >> >> >(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://na01.safelinks.protection.outlook.com/?url=
> >> >> https%3A%2F%2Fsnag.gy%2
> >> >> >FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> >> 0f48%7Cfa7b1b5a7
> >> >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> >> sdata=kxYE7ylOsXPUEeE
> >> >> >r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
> >> >> >
> >> >> >(*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 <ca...@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 <ha...@gmail.com>:
> >> >> >>
> >> >> >>> BTW, the kind of thing we should be striving for in theme-able
> >> >> >>>components
> >> >> >>> is something like this:
> >> >> >>>
> >> >> >>>
> >> >> >>>https://na01.safelinks.protection.outlook.com/?url=
> >> >> https%3A%2F%2Fvcalend
> >> >> >>>ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> >> 0f48%7Cf
> >> >>
> >>>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
> >> >> b3VtV
> >> >> >>>VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
> >> >> >>><https://na01.safelinks.protection.outlook.com/?url=
> >> >> https%3A%2F%2Fvcalen
> >> >> >>>dar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> >> 0f48%7C
> >> >>
> >>>>>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
> >> >> b3Vt
> >> >> >>>VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
> >> >> >>>
> >> >> >>> > On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
> >> >> https%3A%2F%2Fpaste.a
> >> >> >>>pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> >> 0f48%7Cfa
> >> >> >>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> >> sdata=bRWKxm
> >> >> >>>LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
> >> >>
> >> >>>>><https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fpast
> >> >>>>>e
> >> >> .
> >> >> >>>apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> >> 0f48%7Cf
> >> >>
> >>>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
> >> >> bRWKx
> >> >> >>>mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
> >> >> >>> >
> >> >> >>> > (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
> >> >><carlosrovira@apache.org
> >> >> >>> <ma...@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.lists@gmail.com
> >><mailto:
> >> >> >>> harbs.lists@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
> >> >><aharui@adobe.com.INVALID
> >> >> >>> <ma...@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
> >> >> >>
> >> >> >>https://na01.safelinks.protection.outlook.com/?url=
> >> >> http%3A%2F%2Fabout.me%
> >> >> >>2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> >> 0f48%7Cfa7b1
> >> >> >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> >> sdata=C7a72gwfH2
> >> >> >>64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >--
> >> >> >Carlos Rovira
> >> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> >> http%3A%2F%2Fabout.me%2
> >> >> >Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> >> 0f48%7Cfa7b1b5
> >> >> >a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> >> sdata=C7a72gwfH264w
> >> >> >Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >
> >> ><https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fwww.codeo
> >> >scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
> >> d8cf%7Cfa7b1b5a7b
> >> >34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> >> sdata=Hm%2B6WIcqQTOHs0
> >> >UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> >> d8cf%7Cfa7b1b5a7b3
> >> >4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> >> sdata=Hm%2B6WIcqQTOHs0U
> >> >ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> >> d8cf%7Cfa7b1b5a
> >> >7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> >> sdata=b%2FFMr1Ajit94
> >> >TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
> 82e0%7Cfa7b1b5
> >a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
> sdata=wYPMWW1wpTbtm
> >pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
>
>
--
<http://www.codeoscopic.com>
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
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: Working on UI Controls styling
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
I think we're pretty much in agreement. Regarding Basic, for me, I have
created plenty of web pages with non-styleable checkboxes. I don't care
that the checkbox looks different on different browsers. I just want the
smallest simplest output. Just like taking an HTML editor and slapping in
a few tags and calling it done. Would that be production? Sure, if I'm
just want someone to check a box before enabling a download button. IOW,
it would be for internal customers only.
So, IMO, a Skinnable/Themeable component set would be something else. I
think you will need that extra Span for a Checkbox. IMO, we should just
go and build these new components. And when we get it mostly working, we
can compare against Basic and see if we want to parameterize the views in
the low-level Basic components or not.
My 2 cents,
-Alex
On 11/4/17, 8:19 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>HI Alex,
>
>
>2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> Hi Carlos,
>>
>> I skimmed through
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaterial
>>.io%2Fguidelines%2F%23&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d5239782e0
>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&sdata=g5
>>M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last night.
>>
>> My impression is that there were two parts to it. First was the
>> environment/principles section which talked about physical objects and
>> light (and motion), and then there were choices of widgets. For
>>example,
>> I didn't see anything in the first part that said that a text input had
>>to
>> be a single line and couldn't be a box.
>>
>
>Material guidelines could be a great way to start, but trying to give
>something different.
>I think that we need to get something that looks great while be clearly
>different to google material,
>bootstrap, and others so people could see us as an alternative. That could
>make people copying us
>or adopting the whole Apache Royale SDK that is what we want in the end
>
>
>
>>
>> That made me think that we could use our widget set and apply Material
>> environment and principles to it. If we decide not to, I would think
>>you
>> would want to have some sort of similar environment/principles document
>> which seems like a fair amount of work. I think we'd end up looking
>> different because we have different widgets and maybe some different
>> colors. I'm pretty sure that we don't want to be different so much that
>> we don't create things that folks want to use. The priority to me is
>>just
>> to prove that you can alter every pixel in every widget we have so that
>> others can provide custom skins as well. So starting with Material
>> principles seems like it would save us time, we can get something
>> released, and can innovate more later.
>>
>
>I think as you that we need a way to make the "presentation" of each
>component highly customizable.
>And we need to be different in visualization (art, colors, ...) but not in
>usability that is what people
>needs to be consistently
>
>
>
>>
>> Maybe a good question for our users is: How many of you used the
>>default
>> Flex skins vs a whole new set of skins? If most folks completely
>> re-skinned to match their corporate branding, it matters less what our
>> default is, and more that we can allow folks to customize every pixel.
>>
>>
>We need both: a skin that will be highly customizable and to change skins
>to look very very different.
>People with lees money or time in their Apps will choose the first. People
>that has more resources will go with the second.
>Apache Royale needs to support both
>
>
>> The wireframe can be black and white, IMO. I was thinking that "vivid"
>> would have parameterized colors.
>>
>>
>I started to think that wireframe could end having lots of customization
>controls. For example:
>
>-2-3 main colors as we talked , and the same MDL does
>-possibilitiy to be solid colors, or gradients
>-possibility to have backgrounds more or less opaque
>
>if we see a concrete component like button:
>
>- configurable corners, square to round corners
>- more blocky (relief) or more flat
>...
>
>So wireframe could be a concrete configuration of the main theme
>
>
>
>> Since Bootstrap was mentioned, I want to point out that the Flat.swc is
>>a
>> rough approximation of the Flat theme which is a Bootstrap theme. It
>>is a
>> rough approximation because I could not use the Flat CSS file directly
>> since it contains much more advanced CSS than we currently support on
>>the
>> SWF side. But it presumed that the Checkbox was a Label with a Span
>>that
>> hides in front of or behind the <input type="check" /> in order to allow
>> customizing every pixel. Looks like MDL uses the same Span trick but
>> maybe without a symbol font.
>>
>> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox
>>should
>> not have that extra Span. But it looks to me that a SkinnableCheckbox
>>can
>> add that extra Span and you either give it the same class name that
>> BootStrap or MDL uses or create our own set of classnames and the CSS
>>that
>> goes with it.
>>
>>
>The problem with Basic could be that if is very very basic and looks with
>a
>very basic look (as it is very poorly stylizable), I think
>People will not use it at all, in this case, I'll don't understand the
>goal
>with basic. It's intend ended as a base
>but to not use in production? For this reason is what I want to know if
>you
>think this theme feature could be plugged in basic or not.
>
>
>
>
>> Of course, I could be wrong. This is not my area of expertise at all.
>>
>
>Hi Alex, maybe UX is not your expertise area, but your help here is very
>needed since we can get to great ideas in this field, but
>maybe don't know how to bring it to implementation in Apache Royale. I
>think that you, Peter, Harbs,... are needed in order to
>make this happen in the pure arquitecture side or this feature.
>
>Thanks
>
>-Alex
>>
>>
>> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>> wrote:
>>
>> >Hi Alex,
>> >
>> >2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>> >
>> >> Hi Carlos,
>> >>
>> >> Looks good to me. Thanks for doing this.
>> >>
>> >
>> >Thanks :)
>> >
>> >>
>> >> I'm not sure I understand all of the aspects of this effort. My
>>current
>> >> understanding is that Google Material is under the Apache License and
>> >>thus
>> >> we can use it if we want to. Am I correct that MaterialDesignLite is
>> >>one
>> >> implementation of Google Material and we could create our own
>> >> implementation and it could be visually different?
>> >>
>> >
>> >We can implement our own material in Royale, but I'm afraid that doing
>> >that
>> >will not make us
>> >highlight our solution against the rest of competitors. Another point
>>is
>> >something I said various times:
>> >When I did MDL, I notice a huge problem: MDL has its own set of
>> >components,
>> >some are in all sets (Button)
>> >but others not (Card), and they has it's own implementation, what make
>>it
>> >almost impossible generalize
>> >a theme. For this reason I always point that we need our own set and
>>there
>> >we can implement themes. But other
>> >*externa* sets will never get this since they have its own
>>implementation
>> >and most important once you start to develop
>> >with MDL you can't go back and change for other. So MDL is for me
>> >something
>> >we have until our own set are robust and
>> >highly configurable in both the things we can do and how can it could
>>be
>> >represented, and switch between style should be
>> >really easy to change the global look of an App without much hassle.
>> >
>> >
>> >>
>> >> Also, IIRC, Material has different components than Flex did so we'd
>>have
>> >> to invent some new looks anyway. So having a TextInput with borders
>>all
>> >> around would just be our flavor of Material.
>> >>
>> >
>> >That's what I point above. We must to *freeze* the list of components
>>at
>> >some time work over a concrete set
>> >We can then plan in the future include a new component in the official
>> >set,
>> >and that will need to work on the themes we already
>> >have to include the new one.
>> >
>> >
>> >>
>> >> Regarding colors, it looks like Material is parameterized around a
>> >>couple
>> >> of colors. So if we did our skins to work against parameterized
>>colors
>> >> then would it really matter what color we choose?
>> >>
>> >
>> >That's completly right. I could make wireframe based on two or three
>> >colors
>> >and as you change it in CSS all controls should tint
>> >consistently.
>> >
>> >
>> >>
>> >> Regarding Basic components, right now Checkbox is a <label><input
>> >> type="check"/>caption</label>. AIUI, you cannot style the <input> on
>> >>many
>> >> browsers, so I think we have to have a different set of elements in a
>> >> checkbox. It looks like Bootstrap uses:
>> >>
>> >> <label><input type="check"/><span />Caption</label>
>> >>
>> >> Where the span uses a special symbol font with checked and unchecked
>> >>boxes.
>> >>
>> >
>> >That's what we need to figure. Should we make themes available in
>>Basic?
>> >if
>> >so, has basic the right implementation?
>> >If not, and if we don't want to change the actual very basic
>> >implementation, we need to put some "skin" implementation
>> >that at least in JS implementation I figure that will change one face
>>(the
>> >actual basic) with the theme face.
>> >
>> >I'm thinking loud, since this is something we should explorer all
>>together
>> >mixing the best ideas of people involved
>> >
>> >Thanks
>> >
>> >
>> >
>> >>
>> >> Thanks,
>> >> Alex
>> >>
>> >> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos
>> >>Rovira"
>> >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>> >>
>> >> >Hi,
>> >> >
>> >> >I want to expose my initial work (very very initial) on two styles
>>for
>> >> >Royale
>> >> >
>> >> >
>> >> >Wireframe:
>> >> >https://na01.safelinks.protection.outlook.com/?url=
>> >> https%3A%2F%2Fsnag.gy%2
>> >> >FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >> 0f48%7Cfa7b1b5a7
>> >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >> sdata=%2Fk8YQxC5bDOaC
>> >> >D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
>> >> >
>> >> >(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://na01.safelinks.protection.outlook.com/?url=
>> >> https%3A%2F%2Fsnag.gy%2
>> >> >FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >> 0f48%7Cfa7b1b5a7
>> >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >> sdata=kxYE7ylOsXPUEeE
>> >> >r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
>> >> >
>> >> >(*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 <ca...@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 <ha...@gmail.com>:
>> >> >>
>> >> >>> BTW, the kind of thing we should be striving for in theme-able
>> >> >>>components
>> >> >>> is something like this:
>> >> >>>
>> >> >>>
>> >> >>>https://na01.safelinks.protection.outlook.com/?url=
>> >> https%3A%2F%2Fvcalend
>> >> >>>ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >> 0f48%7Cf
>> >>
>>>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
>> >> b3VtV
>> >> >>>VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
>> >> >>><https://na01.safelinks.protection.outlook.com/?url=
>> >> https%3A%2F%2Fvcalen
>> >> >>>dar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >> 0f48%7C
>> >>
>>>>>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
>> >> b3Vt
>> >> >>>VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
>> >> >>>
>> >> >>> > On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
>> >> https%3A%2F%2Fpaste.a
>> >> >>>pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >> 0f48%7Cfa
>> >> >>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >> sdata=bRWKxm
>> >> >>>LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
>> >>
>> >>>>><https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fpast
>> >>>>>e
>> >> .
>> >> >>>apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >> 0f48%7Cf
>> >>
>>>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
>> >> bRWKx
>> >> >>>mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
>> >> >>> >
>> >> >>> > (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
>> >><carlosrovira@apache.org
>> >> >>> <ma...@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.lists@gmail.com
>><mailto:
>> >> >>> harbs.lists@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
>> >><aharui@adobe.com.INVALID
>> >> >>> <ma...@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
>> >> >>
>> >> >>https://na01.safelinks.protection.outlook.com/?url=
>> >> http%3A%2F%2Fabout.me%
>> >> >>2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >> 0f48%7Cfa7b1
>> >> >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >> sdata=C7a72gwfH2
>> >> >>64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >--
>> >> >Carlos Rovira
>> >> >https://na01.safelinks.protection.outlook.com/?url=
>> >> http%3A%2F%2Fabout.me%2
>> >> >Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >> 0f48%7Cfa7b1b5
>> >> >a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >> sdata=C7a72gwfH264w
>> >> >Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>> >>
>> >>
>> >
>> >
>> >--
>> >
>> ><https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fwww.codeo
>> >scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
>> d8cf%7Cfa7b1b5a7b
>> >34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>> sdata=Hm%2B6WIcqQTOHs0
>> >UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>> d8cf%7Cfa7b1b5a7b3
>> >4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>> sdata=Hm%2B6WIcqQTOHs0U
>> >ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
>> d8cf%7Cfa7b1b5a
>> >7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>> sdata=b%2FFMr1Ajit94
>> >TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
>>
>>
>
>
>--
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d5239782e0%7Cfa7b1b5
>a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&sdata=wYPMWW1wpTbtm
>pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
Re: Working on UI Controls styling
Posted by Carlos Rovira <ca...@apache.org>.
HI Alex,
2017-11-03 17:52 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> Hi Carlos,
>
> I skimmed through https://material.io/guidelines/# last night.
>
> My impression is that there were two parts to it. First was the
> environment/principles section which talked about physical objects and
> light (and motion), and then there were choices of widgets. For example,
> I didn't see anything in the first part that said that a text input had to
> be a single line and couldn't be a box.
>
Material guidelines could be a great way to start, but trying to give
something different.
I think that we need to get something that looks great while be clearly
different to google material,
bootstrap, and others so people could see us as an alternative. That could
make people copying us
or adopting the whole Apache Royale SDK that is what we want in the end
>
> That made me think that we could use our widget set and apply Material
> environment and principles to it. If we decide not to, I would think you
> would want to have some sort of similar environment/principles document
> which seems like a fair amount of work. I think we'd end up looking
> different because we have different widgets and maybe some different
> colors. I'm pretty sure that we don't want to be different so much that
> we don't create things that folks want to use. The priority to me is just
> to prove that you can alter every pixel in every widget we have so that
> others can provide custom skins as well. So starting with Material
> principles seems like it would save us time, we can get something
> released, and can innovate more later.
>
I think as you that we need a way to make the "presentation" of each
component highly customizable.
And we need to be different in visualization (art, colors, ...) but not in
usability that is what people
needs to be consistently
>
> Maybe a good question for our users is: How many of you used the default
> Flex skins vs a whole new set of skins? If most folks completely
> re-skinned to match their corporate branding, it matters less what our
> default is, and more that we can allow folks to customize every pixel.
>
>
We need both: a skin that will be highly customizable and to change skins
to look very very different.
People with lees money or time in their Apps will choose the first. People
that has more resources will go with the second.
Apache Royale needs to support both
> The wireframe can be black and white, IMO. I was thinking that "vivid"
> would have parameterized colors.
>
>
I started to think that wireframe could end having lots of customization
controls. For example:
-2-3 main colors as we talked , and the same MDL does
-possibilitiy to be solid colors, or gradients
-possibility to have backgrounds more or less opaque
if we see a concrete component like button:
- configurable corners, square to round corners
- more blocky (relief) or more flat
...
So wireframe could be a concrete configuration of the main theme
> Since Bootstrap was mentioned, I want to point out that the Flat.swc is a
> rough approximation of the Flat theme which is a Bootstrap theme. It is a
> rough approximation because I could not use the Flat CSS file directly
> since it contains much more advanced CSS than we currently support on the
> SWF side. But it presumed that the Checkbox was a Label with a Span that
> hides in front of or behind the <input type="check" /> in order to allow
> customizing every pixel. Looks like MDL uses the same Span trick but
> maybe without a symbol font.
>
> Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox should
> not have that extra Span. But it looks to me that a SkinnableCheckbox can
> add that extra Span and you either give it the same class name that
> BootStrap or MDL uses or create our own set of classnames and the CSS that
> goes with it.
>
>
The problem with Basic could be that if is very very basic and looks with a
very basic look (as it is very poorly stylizable), I think
People will not use it at all, in this case, I'll don't understand the goal
with basic. It's intend ended as a base
but to not use in production? For this reason is what I want to know if you
think this theme feature could be plugged in basic or not.
> Of course, I could be wrong. This is not my area of expertise at all.
>
Hi Alex, maybe UX is not your expertise area, but your help here is very
needed since we can get to great ideas in this field, but
maybe don't know how to bring it to implementation in Apache Royale. I
think that you, Peter, Harbs,... are needed in order to
make this happen in the pure arquitecture side or this feature.
Thanks
-Alex
>
>
> On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> wrote:
>
> >Hi Alex,
> >
> >2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >
> >> Hi Carlos,
> >>
> >> Looks good to me. Thanks for doing this.
> >>
> >
> >Thanks :)
> >
> >>
> >> I'm not sure I understand all of the aspects of this effort. My current
> >> understanding is that Google Material is under the Apache License and
> >>thus
> >> we can use it if we want to. Am I correct that MaterialDesignLite is
> >>one
> >> implementation of Google Material and we could create our own
> >> implementation and it could be visually different?
> >>
> >
> >We can implement our own material in Royale, but I'm afraid that doing
> >that
> >will not make us
> >highlight our solution against the rest of competitors. Another point is
> >something I said various times:
> >When I did MDL, I notice a huge problem: MDL has its own set of
> >components,
> >some are in all sets (Button)
> >but others not (Card), and they has it's own implementation, what make it
> >almost impossible generalize
> >a theme. For this reason I always point that we need our own set and there
> >we can implement themes. But other
> >*externa* sets will never get this since they have its own implementation
> >and most important once you start to develop
> >with MDL you can't go back and change for other. So MDL is for me
> >something
> >we have until our own set are robust and
> >highly configurable in both the things we can do and how can it could be
> >represented, and switch between style should be
> >really easy to change the global look of an App without much hassle.
> >
> >
> >>
> >> Also, IIRC, Material has different components than Flex did so we'd have
> >> to invent some new looks anyway. So having a TextInput with borders all
> >> around would just be our flavor of Material.
> >>
> >
> >That's what I point above. We must to *freeze* the list of components at
> >some time work over a concrete set
> >We can then plan in the future include a new component in the official
> >set,
> >and that will need to work on the themes we already
> >have to include the new one.
> >
> >
> >>
> >> Regarding colors, it looks like Material is parameterized around a
> >>couple
> >> of colors. So if we did our skins to work against parameterized colors
> >> then would it really matter what color we choose?
> >>
> >
> >That's completly right. I could make wireframe based on two or three
> >colors
> >and as you change it in CSS all controls should tint
> >consistently.
> >
> >
> >>
> >> Regarding Basic components, right now Checkbox is a <label><input
> >> type="check"/>caption</label>. AIUI, you cannot style the <input> on
> >>many
> >> browsers, so I think we have to have a different set of elements in a
> >> checkbox. It looks like Bootstrap uses:
> >>
> >> <label><input type="check"/><span />Caption</label>
> >>
> >> Where the span uses a special symbol font with checked and unchecked
> >>boxes.
> >>
> >
> >That's what we need to figure. Should we make themes available in Basic?
> >if
> >so, has basic the right implementation?
> >If not, and if we don't want to change the actual very basic
> >implementation, we need to put some "skin" implementation
> >that at least in JS implementation I figure that will change one face (the
> >actual basic) with the theme face.
> >
> >I'm thinking loud, since this is something we should explorer all together
> >mixing the best ideas of people involved
> >
> >Thanks
> >
> >
> >
> >>
> >> Thanks,
> >> Alex
> >>
> >> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos
> >>Rovira"
> >> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
> >>
> >> >Hi,
> >> >
> >> >I want to expose my initial work (very very initial) on two styles for
> >> >Royale
> >> >
> >> >
> >> >Wireframe:
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fsnag.gy%2
> >> >FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa7b1b5a7
> >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=%2Fk8YQxC5bDOaC
> >> >D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
> >> >
> >> >(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://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fsnag.gy%2
> >> >FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa7b1b5a7
> >> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=kxYE7ylOsXPUEeE
> >> >r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
> >> >
> >> >(*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 <ca...@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 <ha...@gmail.com>:
> >> >>
> >> >>> BTW, the kind of thing we should be striving for in theme-able
> >> >>>components
> >> >>> is something like this:
> >> >>>
> >> >>>
> >> >>>https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fvcalend
> >> >>>ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cf
> >> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
> >> b3VtV
> >> >>>VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
> >> >>><https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fvcalen
> >> >>>dar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7C
> >> >>>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
> >> b3Vt
> >> >>>VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
> >> >>>
> >> >>> > On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fpaste.a
> >> >>>pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa
> >> >>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=bRWKxm
> >> >>>LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
> >>
> >>>>><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpast
> >>>>>e
> >> .
> >> >>>apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cf
> >> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
> >> bRWKx
> >> >>>mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
> >> >>> >
> >> >>> > (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
> >><carlosrovira@apache.org
> >> >>> <ma...@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.lists@gmail.com <mailto:
> >> >>> harbs.lists@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
> >><aharui@adobe.com.INVALID
> >> >>> <ma...@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
> >> >>
> >> >>https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%
> >> >>2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa7b1
> >> >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=C7a72gwfH2
> >> >>64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >Carlos Rovira
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%2
> >> >Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> >> 0f48%7Cfa7b1b5
> >> >a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> >> sdata=C7a72gwfH264w
> >> >Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >>
> >>
> >
> >
> >--
> >
> ><https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.codeo
> >scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
> d8cf%7Cfa7b1b5a7b
> >34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> sdata=Hm%2B6WIcqQTOHs0
> >UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> d8cf%7Cfa7b1b5a7b3
> >4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> sdata=Hm%2B6WIcqQTOHs0U
> >ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295
> d8cf%7Cfa7b1b5a
> >7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
> sdata=b%2FFMr1Ajit94
> >TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Working on UI Controls styling
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
I skimmed through https://material.io/guidelines/# last night.
My impression is that there were two parts to it. First was the
environment/principles section which talked about physical objects and
light (and motion), and then there were choices of widgets. For example,
I didn't see anything in the first part that said that a text input had to
be a single line and couldn't be a box.
That made me think that we could use our widget set and apply Material
environment and principles to it. If we decide not to, I would think you
would want to have some sort of similar environment/principles document
which seems like a fair amount of work. I think we'd end up looking
different because we have different widgets and maybe some different
colors. I'm pretty sure that we don't want to be different so much that
we don't create things that folks want to use. The priority to me is just
to prove that you can alter every pixel in every widget we have so that
others can provide custom skins as well. So starting with Material
principles seems like it would save us time, we can get something
released, and can innovate more later.
Maybe a good question for our users is: How many of you used the default
Flex skins vs a whole new set of skins? If most folks completely
re-skinned to match their corporate branding, it matters less what our
default is, and more that we can allow folks to customize every pixel.
The wireframe can be black and white, IMO. I was thinking that "vivid"
would have parameterized colors.
Since Bootstrap was mentioned, I want to point out that the Flat.swc is a
rough approximation of the Flat theme which is a Bootstrap theme. It is a
rough approximation because I could not use the Flat CSS file directly
since it contains much more advanced CSS than we currently support on the
SWF side. But it presumed that the Checkbox was a Label with a Span that
hides in front of or behind the <input type="check" /> in order to allow
customizing every pixel. Looks like MDL uses the same Span trick but
maybe without a symbol font.
Basic is, IMO, truly meant to be Basic. I think the Basic Checkbox should
not have that extra Span. But it looks to me that a SkinnableCheckbox can
add that extra Span and you either give it the same class name that
BootStrap or MDL uses or create our own set of classnames and the CSS that
goes with it.
Of course, I could be wrong. This is not my area of expertise at all.
-Alex
On 11/3/17, 1:35 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:
>Hi Alex,
>
>2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> Hi Carlos,
>>
>> Looks good to me. Thanks for doing this.
>>
>
>Thanks :)
>
>>
>> I'm not sure I understand all of the aspects of this effort. My current
>> understanding is that Google Material is under the Apache License and
>>thus
>> we can use it if we want to. Am I correct that MaterialDesignLite is
>>one
>> implementation of Google Material and we could create our own
>> implementation and it could be visually different?
>>
>
>We can implement our own material in Royale, but I'm afraid that doing
>that
>will not make us
>highlight our solution against the rest of competitors. Another point is
>something I said various times:
>When I did MDL, I notice a huge problem: MDL has its own set of
>components,
>some are in all sets (Button)
>but others not (Card), and they has it's own implementation, what make it
>almost impossible generalize
>a theme. For this reason I always point that we need our own set and there
>we can implement themes. But other
>*externa* sets will never get this since they have its own implementation
>and most important once you start to develop
>with MDL you can't go back and change for other. So MDL is for me
>something
>we have until our own set are robust and
>highly configurable in both the things we can do and how can it could be
>represented, and switch between style should be
>really easy to change the global look of an App without much hassle.
>
>
>>
>> Also, IIRC, Material has different components than Flex did so we'd have
>> to invent some new looks anyway. So having a TextInput with borders all
>> around would just be our flavor of Material.
>>
>
>That's what I point above. We must to *freeze* the list of components at
>some time work over a concrete set
>We can then plan in the future include a new component in the official
>set,
>and that will need to work on the themes we already
>have to include the new one.
>
>
>>
>> Regarding colors, it looks like Material is parameterized around a
>>couple
>> of colors. So if we did our skins to work against parameterized colors
>> then would it really matter what color we choose?
>>
>
>That's completly right. I could make wireframe based on two or three
>colors
>and as you change it in CSS all controls should tint
>consistently.
>
>
>>
>> Regarding Basic components, right now Checkbox is a <label><input
>> type="check"/>caption</label>. AIUI, you cannot style the <input> on
>>many
>> browsers, so I think we have to have a different set of elements in a
>> checkbox. It looks like Bootstrap uses:
>>
>> <label><input type="check"/><span />Caption</label>
>>
>> Where the span uses a special symbol font with checked and unchecked
>>boxes.
>>
>
>That's what we need to figure. Should we make themes available in Basic?
>if
>so, has basic the right implementation?
>If not, and if we don't want to change the actual very basic
>implementation, we need to put some "skin" implementation
>that at least in JS implementation I figure that will change one face (the
>actual basic) with the theme face.
>
>I'm thinking loud, since this is something we should explorer all together
>mixing the best ideas of people involved
>
>Thanks
>
>
>
>>
>> Thanks,
>> Alex
>>
>> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>
>> >Hi,
>> >
>> >I want to expose my initial work (very very initial) on two styles for
>> >Royale
>> >
>> >
>> >Wireframe:
>> >https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fsnag.gy%2
>> >FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cfa7b1b5a7
>> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> sdata=%2Fk8YQxC5bDOaC
>> >D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
>> >
>> >(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://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fsnag.gy%2
>> >FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cfa7b1b5a7
>> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> sdata=kxYE7ylOsXPUEeE
>> >r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
>> >
>> >(*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 <ca...@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 <ha...@gmail.com>:
>> >>
>> >>> BTW, the kind of thing we should be striving for in theme-able
>> >>>components
>> >>> is something like this:
>> >>>
>> >>>
>> >>>https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fvcalend
>> >>>ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cf
>> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
>> b3VtV
>> >>>VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
>> >>><https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fvcalen
>> >>>dar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7C
>> >>>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
>> b3Vt
>> >>>VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
>> >>>
>> >>> > On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fpaste.a
>> >>>pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cfa
>> >>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> sdata=bRWKxm
>> >>>LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
>>
>>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpast
>>>>>e
>> .
>> >>>apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cf
>> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
>> bRWKx
>> >>>mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
>> >>> >
>> >>> > (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
>><carlosrovira@apache.org
>> >>> <ma...@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.lists@gmail.com <mailto:
>> >>> harbs.lists@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
>><aharui@adobe.com.INVALID
>> >>> <ma...@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
>> >>
>> >>https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%
>> >>2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cfa7b1
>> >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> sdata=C7a72gwfH2
>> >>64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>> >>
>> >>
>> >
>> >
>> >--
>> >Carlos Rovira
>> >https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>> >Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> 0f48%7Cfa7b1b5
>> >a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> sdata=C7a72gwfH264w
>> >Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>>
>>
>
>
>--
>
><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeo
>scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b1b5a7b
>34438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=Hm%2B6WIcqQTOHs0
>UppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b1b5a7b3
>4438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=Hm%2B6WIcqQTOHs0U
>ppUdckW%2FhhyzErprotQUOZNtUtXU%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%7C6422929d95d1406eaa1c08d52295d8cf%7Cfa7b1b5a
>7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&sdata=b%2FFMr1Ajit94
>TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%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.
Re: Working on UI Controls styling
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Alex,
2017-11-03 7:39 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> Hi Carlos,
>
> Looks good to me. Thanks for doing this.
>
Thanks :)
>
> I'm not sure I understand all of the aspects of this effort. My current
> understanding is that Google Material is under the Apache License and thus
> we can use it if we want to. Am I correct that MaterialDesignLite is one
> implementation of Google Material and we could create our own
> implementation and it could be visually different?
>
We can implement our own material in Royale, but I'm afraid that doing that
will not make us
highlight our solution against the rest of competitors. Another point is
something I said various times:
When I did MDL, I notice a huge problem: MDL has its own set of components,
some are in all sets (Button)
but others not (Card), and they has it's own implementation, what make it
almost impossible generalize
a theme. For this reason I always point that we need our own set and there
we can implement themes. But other
*externa* sets will never get this since they have its own implementation
and most important once you start to develop
with MDL you can't go back and change for other. So MDL is for me something
we have until our own set are robust and
highly configurable in both the things we can do and how can it could be
represented, and switch between style should be
really easy to change the global look of an App without much hassle.
>
> Also, IIRC, Material has different components than Flex did so we'd have
> to invent some new looks anyway. So having a TextInput with borders all
> around would just be our flavor of Material.
>
That's what I point above. We must to *freeze* the list of components at
some time work over a concrete set
We can then plan in the future include a new component in the official set,
and that will need to work on the themes we already
have to include the new one.
>
> Regarding colors, it looks like Material is parameterized around a couple
> of colors. So if we did our skins to work against parameterized colors
> then would it really matter what color we choose?
>
That's completly right. I could make wireframe based on two or three colors
and as you change it in CSS all controls should tint
consistently.
>
> Regarding Basic components, right now Checkbox is a <label><input
> type="check"/>caption</label>. AIUI, you cannot style the <input> on many
> browsers, so I think we have to have a different set of elements in a
> checkbox. It looks like Bootstrap uses:
>
> <label><input type="check"/><span />Caption</label>
>
> Where the span uses a special symbol font with checked and unchecked boxes.
>
That's what we need to figure. Should we make themes available in Basic? if
so, has basic the right implementation?
If not, and if we don't want to change the actual very basic
implementation, we need to put some "skin" implementation
that at least in JS implementation I figure that will change one face (the
actual basic) with the theme face.
I'm thinking loud, since this is something we should explorer all together
mixing the best ideas of people involved
Thanks
>
> Thanks,
> Alex
>
> On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Hi,
> >
> >I want to expose my initial work (very very initial) on two styles for
> >Royale
> >
> >
> >Wireframe:
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fsnag.gy%2
> >FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1b5a7
> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=%2Fk8YQxC5bDOaC
> >D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
> >
> >(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://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fsnag.gy%2
> >FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1b5a7
> >b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=kxYE7ylOsXPUEeE
> >r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
> >
> >(*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 <ca...@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 <ha...@gmail.com>:
> >>
> >>> BTW, the kind of thing we should be striving for in theme-able
> >>>components
> >>> is something like this:
> >>>
> >>>
> >>>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fvcalend
> >>>ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cf
> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
> b3VtV
> >>>VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
> >>><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fvcalen
> >>>dar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7C
> >>>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
> b3Vt
> >>>VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
> >>>
> >>> > On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.a
> >>>pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa
> >>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=bRWKxm
> >>>LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
> >>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste
> .
> >>>apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cf
> >>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=
> bRWKx
> >>>mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
> >>> >
> >>> > (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 <carlosrovira@apache.org
> >>> <ma...@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.lists@gmail.com <mailto:
> >>> harbs.lists@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 <aharui@adobe.com.INVALID
> >>> <ma...@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
> >>
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%
> >>2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1
> >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=C7a72gwfH2
> >>64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
> 0f48%7Cfa7b1b5
> >a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
> sdata=C7a72gwfH264w
> >Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>
>
--
<http://www.codeoscopic.com>
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
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: Working on UI Controls styling
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
Looks good to me. Thanks for doing this.
I'm not sure I understand all of the aspects of this effort. My current
understanding is that Google Material is under the Apache License and thus
we can use it if we want to. Am I correct that MaterialDesignLite is one
implementation of Google Material and we could create our own
implementation and it could be visually different?
Also, IIRC, Material has different components than Flex did so we'd have
to invent some new looks anyway. So having a TextInput with borders all
around would just be our flavor of Material.
Regarding colors, it looks like Material is parameterized around a couple
of colors. So if we did our skins to work against parameterized colors
then would it really matter what color we choose?
Regarding Basic components, right now Checkbox is a <label><input
type="check"/>caption</label>. AIUI, you cannot style the <input> on many
browsers, so I think we have to have a different set of elements in a
checkbox. It looks like Bootstrap uses:
<label><input type="check"/><span />Caption</label>
Where the span uses a special symbol font with checked and unchecked boxes.
Thanks,
Alex
On 11/2/17, 5:15 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>Hi,
>
>I want to expose my initial work (very very initial) on two styles for
>Royale
>
>
>Wireframe:
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsnag.gy%2
>FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d522500f48%7Cfa7b1b5a7
>b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=%2Fk8YQxC5bDOaC
>D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
>
>(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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsnag.gy%2
>FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d522500f48%7Cfa7b1b5a7
>b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=kxYE7ylOsXPUEeE
>r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
>
>(*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 <ca...@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 <ha...@gmail.com>:
>>
>>> BTW, the kind of thing we should be striving for in theme-able
>>>components
>>> is something like this:
>>>
>>>
>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvcalend
>>>ar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d522500f48%7Cf
>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=b3VtV
>>>VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvcalen
>>>dar.netlify.com%2F&data=02%7C01%7C%7C203485b5b9c744aed92608d522500f48%7C
>>>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=b3Vt
>>>VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
>>>
>>> > On Nov 2, 2017, at 12:01 PM, Harbs <ha...@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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.a
>>>pache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d522500f48%7Cfa
>>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=bRWKxm
>>>LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.
>>>apache.org%2FcOBC&data=02%7C01%7C%7C203485b5b9c744aed92608d522500f48%7Cf
>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=bRWKx
>>>mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
>>> >
>>> > (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 <carlosrovira@apache.org
>>> <ma...@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.lists@gmail.com <mailto:
>>> harbs.lists@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 <aharui@adobe.com.INVALID
>>> <ma...@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
>>
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d522500f48%7Cfa7b1
>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=C7a72gwfH2
>>64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>>
>>
>
>
>--
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d522500f48%7Cfa7b1b5
>a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&sdata=C7a72gwfH264w
>Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
Re: Working on UI Controls styling
Posted by Carlos Rovira <ca...@codeoscopic.com>.
ok Piotr,
thanks! :)
2017-11-03 11:23 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
> Carlos, Harbs,
>
> I was speaking with Angelo some time ago off list. Let me ask him and bring
> this thread to the attention.
>
> Piotr
>
>
> 2017-11-03 11:19 GMT+01:00 Harbs <ha...@gmail.com>:
>
> > Maybe you want to email them off-list and ask if they are still
> interested
> > in helping?
> >
> > Harbs
> >
> > > On Nov 3, 2017, at 10:55 AM, Carlos Rovira <ca...@apache.org>
> > wrote:
> > >
> > > The problem with Trevor and Angelo is that are not very active here.
> >
> >
>
>
> --
>
> Piotr Zarzycki
>
> mobile: +48 880 859 557
> skype: zarzycki10
>
> LinkedIn: http://www.linkedin.com/piotrzarzycki
> <https://pl.linkedin.com/in/piotr-zarzycki-92a53552>
>
> GitHub: https://github.com/piotrzarzycki21
>
--
<http://www.codeoscopic.com>
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
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: Working on UI Controls styling
Posted by Piotr Zarzycki <pi...@gmail.com>.
Carlos, Harbs,
I was speaking with Angelo some time ago off list. Let me ask him and bring
this thread to the attention.
Piotr
2017-11-03 11:19 GMT+01:00 Harbs <ha...@gmail.com>:
> Maybe you want to email them off-list and ask if they are still interested
> in helping?
>
> Harbs
>
> > On Nov 3, 2017, at 10:55 AM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > The problem with Trevor and Angelo is that are not very active here.
>
>
--
Piotr Zarzycki
mobile: +48 880 859 557
skype: zarzycki10
LinkedIn: http://www.linkedin.com/piotrzarzycki
<https://pl.linkedin.com/in/piotr-zarzycki-92a53552>
GitHub: https://github.com/piotrzarzycki21
Re: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
Maybe you want to email them off-list and ask if they are still interested in helping?
Harbs
> On Nov 3, 2017, at 10:55 AM, Carlos Rovira <ca...@apache.org> wrote:
>
> The problem with Trevor and Angelo is that are not very active here.
Re: Working on UI Controls styling
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
2017-11-03 8:57 GMT+01:00 Harbs <ha...@gmail.com>:
> Great start!
>
>
Glad you liked it! :)
> 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'm with you about something 80% flat and maybe something more. It would be
great to get something that could be heavily CSS configurable. For example,
if people
wants solid bg colors, it's ok, but others wanting gradient backgrounds,
should have the option to do this easily , as we did in Flex basic themes.
> > * 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.
>
Once we have this two themes (and due to our conversations, maybe it could
be really only one), we could take over Material and try to implement
something based on that guidelines.
I think it would be great too having that, others could as well implement
bootstrap and other looks. But to make this happen is important to have two
basic things:
1.- a concrete set of UI controls and components that will be included in
this effort
2.- a basic template that will be the foundation in with all themes are
done. The CSS classes and all the wiring must be the same to work
consistently. We could have a basic project template that bundle all css
and assets implied and people will change themes swaping swcs and config
easily.
>
> > * 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?
>
The problem with Trevor and Angelo is that are not very active here. We
even don't know if they are following this mailing list, if they are
working in this or not, and that's a huge problem to make this happen since
it needs some work constantly done and try to get to some milestone to
continue to the next one..
>
> > * 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).
>
that's where you and others could help more. You could contribute to this
effort with tiny things like this as we reach to them, since each one of us
has their own strong and weak points, we must to work as a team, and that
implies to know where each one could contribute, maybe this concrete point
is a tiny effort but can't be done until we have more things in place and
is one or two months in the future....
Thanks
>
> Harbs
>
> > On Nov 3, 2017, at 2:15 AM, Carlos Rovira <ca...@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 <ca...@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 <ha...@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 <ha...@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 <carlosrovira@apache.org
> >>> <ma...@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.lists@gmail.com <mailto:
> >>> harbs.lists@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 <aharui@adobe.com.INVALID
> >>> <ma...@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
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
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 <ca...@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 <ca...@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 <ha...@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 <ha...@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 <carlosrovira@apache.org
>>> <ma...@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.lists@gmail.com <mailto:
>>> harbs.lists@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 <aharui@adobe.com.INVALID
>>> <ma...@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
Re: Working on UI Controls styling
Posted by Carlos Rovira <ca...@apache.org>.
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 <ca...@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 <ha...@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 <ha...@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 <carlosrovira@apache.org
>> <ma...@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.lists@gmail.com <mailto:
>> harbs.lists@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 <aharui@adobe.com.INVALID
>> <ma...@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
Re: Working on UI Controls styling
Posted by Carlos Rovira <ca...@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 <ha...@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 <ha...@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 <carlosrovira@apache.org
> <ma...@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.lists@gmail.com <mailto:
> harbs.lists@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 <aharui@adobe.com.INVALID
> <ma...@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
Re: Working on UI Controls styling
Posted by Harbs <ha...@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 <ha...@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 <carlosrovira@apache.org <ma...@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.lists@gmail.com <ma...@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 <aharui@adobe.com.INVALID <ma...@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
>>>>
>>>
>>>
>
Re: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
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 <ca...@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 <ha...@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 <ah...@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
>>>
>>
>>
Re: Working on UI Controls styling
Posted by Carlos Rovira <ca...@apache.org>.
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 <ha...@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 <ah...@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
> >
>
>
Re: Working on UI Controls styling
Posted by Harbs <ha...@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 <ah...@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
>
> On 11/1/17, 6:18 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
>> JFYI: the svg classes have been tested very well despite there being very
>> few test cases in Royale. 90% of the rendering in my app is using these
>> SVG classes.
>>
>> Our current SVG support is pretty solid.
>>
>> Harbs
>>
>>> On Nov 1, 2017, at 3:12 PM, Harbs <ha...@gmail.com> wrote:
>>>
>>> We also have an SVG package. Look in Basic org/apache/royale/svg.
>>>
>>> It might make sense to pull the SVG classes out into its own project.
>>>
>>> The current implementation of SVG wraps each element in a separate svh
>>> element, so you get lots of nested SVG elements. We considered adding
>>> raw non-wrapped SVG elements, but that has not happened yet.
>>>
>>> There are drawing commands similar to the Flash Graphics APIs. The
>>> drawing APIs work a bit different though. There is a PathBuilder class
>>> which abstracts a lot of things, but some classes have similar APIs like
>>> drawRect, drawRoundedRect, etc.
>>>
>>> Check out CompoundGraphic and PathBuilder. PathBuilder has APIs that
>>> mimic Flash Graphic very closely and can be used with SVG and
>>> theoretically Canvas.
>>>
>>> HTH,
>>> Harbs
>>>
>>>> On Nov 1, 2017, at 3:00 PM, Harbs <ha...@gmail.com> wrote:
>>>>
>>>> <js:ImageButton click="flipHorizontally()"
>>>> src="assets/images/icons/0896-flip-horizontal2.svg"/>
>>>> <js:ImageButton click="flipVertically()"
>>>> src="assets/images/icons/0897-flip-vertical2.svg"/>
>>>>
>>>>
>>>>> On Nov 1, 2017, at 2:45 PM, Carlos Rovira
>>>>> <ca...@codeoscopic.com> wrote:
>>>>>
>>>>> Hi Harbs,
>>>>>
>>>>> could you post some basic snippet for this to look at your approach?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> 2017-11-01 13:42 GMT+01:00 Harbs <ha...@gmail.com>:
>>>>>
>>>>>> You can use SVG files instead of PNG files. I’m doing that
>>>>>> extensively in
>>>>>> my app, but that will only work for components which have src or
>>>>>> background-image.
>>>>>>
>>>>>>> On Nov 1, 2017, at 2:14 PM, Carlos Rovira <ca...@apache.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I started a new project as Piotr suggested. After setup I only put
>>>>>>> one
>>>>>>> single button to start figuring how to do this.
>>>>>>>
>>>>>>> I'm starting for now with Basic, but as we discussed, don't know if
>>>>>>> this
>>>>>>> should go directly to express or not...it seems like something we
>>>>>>> could
>>>>>>> plug into Basic at any time as we can plug beads, and Express will
>>>>>>> come
>>>>>>> with some theme bundled. That seem the most natural for me right now
>>>>>>>
>>>>>>> Setting up a CSS-only theme seems pretty straight forward for me,
>>>>>>> and I
>>>>>>> could go with it for now.
>>>>>>>
>>>>>>> Regarding SVG, right now I don't see the way to add SVG in Royale.
>>>>>>> As
>>>>>> Alex
>>>>>>> suggested, I think we need to be able to add SVG in MXML.
>>>>>>> I was looking at this topic and seems very powerful since it can be
>>>>>>> integrated with CSS as well and in HTML
>>>>>>>
>>>>>>> For Example we have:
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcss- <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcss->
>>>>>>> tricks.com <http://tricks.com/>%2Fusing-svg%2F&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d408d52
>>>>>>> 12b2186%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364513914828032
>>>>>>> 19&sdata=iiUxSDh%2Be%2F3Zt37Lo2IdRYxgA8tIeyYTTawRO2WSNOI%3D&reserved=
>>>>>>> 0
>>>>>>>
>>>>>>> Maybe I could start with only CSS and see how far I can go, making
>>>>>>> wireframe and royale themes, as well trying with PNG images to
>>>>>> complement,
>>>>>>> but I suppose I'll get stuck soon, so maybe we should talk about SVG
>>>>>>> support as well and how hard it would be to make it happen in
>>>>>>> Royale. As
>>>>>>> well if you know other ways to integrate SVG right now please let
>>>>>>> me know
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2017-10-31 21:31 GMT+01:00 Piotr Zarzycki
>>>>>>> <piotrzarzycki21@gmail.com <ma...@gmail.com>>:
>>>>>>>
>>>>>>>> I can say at this point that I really like idea with swappable
>>>>>>>> view. In
>>>>>>>> most cases view is an ActionScript class where we may have more
>>>>>> possibility
>>>>>>>> to do things. When I was looking last time into the checkbox it
>>>>>>>> for sure
>>>>>>>> need to more love, some part of the logic should be moved to the
>>>>>>>> View.
>>>>>>>>
>>>>>>>> Piotr
>>>>>>>>
>>>>>>>> 2017-10-31 20:50 GMT+01:00 Alex Harui <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>:
>>>>>>>>
>>>>>>>>> Ugh, Something has gone bad in the Basic components. Things like
>>>>>>>>> CheckBox and RadioButton should be creating simple <input
>>>>>> type="check"/>
>>>>>>>>> and <input type='radio' /> elements.
>>>>>>>>>
>>>>>>>>> The ability to style everything belongs in a different set of
>>>>>> components.
>>>>>>>>> Basic is supposed to generate the simplest tree of HTMLElements
>>>>>>>>> even if
>>>>>>>>> they can't be fully styles. That's so someone can do the
>>>>>>>>> equivalent of
>>>>>>>>> just using bare bones <input> elements.
>>>>>>>>>
>>>>>>>>> What is currently in Basic CheckBox and RadioButton might be
>>>>>>>>> right for
>>>>>>>>> creating fully styleable components, or some other composition of
>>>>>>>>> HTMLElements might be better. Carlos, I think that's up to you to
>>>>>>>> decide.
>>>>>>>>>
>>>>>>>>> An alternative approach is to have the JS implementations of
>>>>>>>>> CheckBox
>>>>>> and
>>>>>>>>> RadioButton have views and the views could create the
>>>>>>>>> HTMLElements.
>>>>>> That
>>>>>>>>> seems a bit heavy for the simple case of someone who just wants
>>>>>>>>> to use
>>>>>>>>> <input type="check" in an app, but that is a possibility.
>>>>>>>>>
>>>>>>>>> It sounds like you are looking for a way to manipulate SVG at
>>>>>>>>> runtime.
>>>>>>>> It
>>>>>>>>> is fine to have "static SVG" which is a block of SVG with that
>>>>>>>>> cannot
>>>>>> be
>>>>>>>>> modified and thus uses percentages and absolute values as best it
>>>>>>>>> can.
>>>>>>>>> Then we probably want to have a way to create "dynamic" skins
>>>>>>>>> with run
>>>>>>>>> code to generate or manipulate SVG. Those will be heavier, but
>>>>>>>>> that's
>>>>>>>>> PAYG. Should we try to allow SVG tags in MXML files? Then you
>>>>>>>>> could
>>>>>>>>> write code in an fx:Script block around your SVG tags and
>>>>>>>>> manipulate
>>>>>> the
>>>>>>>>> SVG?
>>>>>>>>>
>>>>>>>>> So IMO first, we should look into reverting Basic back to single
>>>>>>>>> simple
>>>>>>>>> HTMLElements where possible, then decide whether we want to have
>>>>>>>> swappable
>>>>>>>>> views or a new skinnable component set, then build out that
>>>>>>>>> component
>>>>>> set
>>>>>>>>> and see what code it takes to get it to look the way we want it.
>>>>>>>>> And
>>>>>>>> then
>>>>>>>>> we'll know what code is needed and can plan out how to
>>>>>>>>> encapsulate and
>>>>>>>>> re-use that code.
>>>>>>>>>
>>>>>>>>> My 2 cents,
>>>>>>>>> -Alex
>>>>>>>>>
>>>>>>>>> On 10/31/17, 11:23 AM, "Piotr Zarzycki"
>>>>>>>>> <piotrzarzycki21@gmail.com <ma...@gmail.com>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Carlos,
>>>>>>>>>>
>>>>>>>>>> I think you should start looking into the Basic module and later
>>>>>>>>>> make
>>>>>> an
>>>>>>>>>> upgrades to Express once you have all components visually
>>>>>>>>>> created. I
>>>>>>>> would
>>>>>>>>>> not think on that stage about how we implement them rather look
>>>>>>>>>> how
>>>>>> they
>>>>>>>>>> look like currently.
>>>>>>>>>>
>>>>>>>>>> 1) Create small app or run example with that component from our
>>>>>>>>>> repository.
>>>>>>>>>> 2) Make it visually with theme
>>>>>>>>>> 3) Show on the dev list - once we agree on all of them we can
>>>>>>>>>> decide
>>>>>> how
>>>>>>>>>> to
>>>>>>>>>> apply those styles.
>>>>>>>>>>
>>>>>>>>>> My 2 cents. :) Piotr
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2017-10-31 19:12 GMT+01:00 Carlos Rovira
>>>>>>>>>> <carlosrovira@apache.org <ma...@apache.org>>:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I'm trying to find a valid workflow to start working in two
>>>>>>>>>>> initial
>>>>>>>>>>> faces
>>>>>>>>>>> for Royale components.
>>>>>>>>>>>
>>>>>>>>>>> I'm talking about to generate some kind of UI sheet with all
>>>>>>>>>>> controls
>>>>>>>>>>> and a
>>>>>>>>>>> basic wireframe style and another one that would be what more
>>>>>>>>>>> people
>>>>>>>>>>> will
>>>>>>>>>>> be using as default in Royale. From here, will be more easy to
>>>>>>>>>>> other
>>>>>>>>>>> guys
>>>>>>>>>>> to change styles. We could event create a Royale Theme editor
>>>>>>>>>>> in a
>>>>>>>> near
>>>>>>>>>>> future.
>>>>>>>>>>>
>>>>>>>>>>> So, to start working on this I need a design tool, and in this
>>>>>>>>>>> case,
>>>>>> I
>>>>>>>>>>> think that one is Sketch App.
>>>>>>>>>>>
>>>>>>>>>>> So I can create a design in Sketch with all controls (Button,
>>>>>>>> TextInput,
>>>>>>>>>>> CheckBox, Panel,...)
>>>>>>>>>>>
>>>>>>>>>>> From here, I can generate CSS and SVG code
>>>>>>>>>>>
>>>>>>>>>>> For example the code of this simple button
>>>>>>>>>>> (https://na01.safelinks.protection.outlook.com/?url= <https://na01.safelinks.protection.outlook.com/?url=>
>>>>>>>>> https%3A%2F%2Fsnag.gy
>>>>>>>>>>> %2FAm2fRX.jpg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>>>> 8494%7Cfa7b1b
>>>>>>>>>>> 5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>>>>> sdata=Z4b6dMq%2Br
>>>>>>>>>>> UmSSxpGYNjgKl0nkRkIlV%2FbQIDLVUIvo6E%3D&reserved=0)
>>>>>>>>>>> that
>>>>>>>>>>> I did quickly is:
>>>>>>>>>>>
>>>>>>>>>>> CSS
>>>>>>>>>>>
>>>>>>>>>>> /* Background: */
>>>>>>>>>>> background: #D8D8D8;
>>>>>>>>>>> border: 1px solid #979797;
>>>>>>>>>>> border-radius: 3px;
>>>>>>>>>>>
>>>>>>>>>>> /* TextField: */
>>>>>>>>>>> font-family: HelveticaNeue;
>>>>>>>>>>> font-size: 12px;
>>>>>>>>>>> color: #646D7A;
>>>>>>>>>>>
>>>>>>>>>>> (CSS is almost all usable)
>>>>>>>>>>>
>>>>>>>>>>> And SVG
>>>>>>>>>>>
>>>>>>>>>>> <svg width="150px" height="40px" viewBox="0 0 150 40"
>>>>>>>>>>> version="1.1"
>>>>>>>>>>> xmlns="
>>>>>>>>>>>
>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url= <https://na01.safelinks.protection.outlook.com/?url=>
>>>>>>>>> http%3A%2F%2Fwww.w3.or
>>>>>>>>>>> g%2F2000%2Fsvg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>>>> 8494%7Cfa7b1
>>>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>>>>> sdata=cWLJ2jj9Ih
>>>>>>>>>>> cGnjAB8GEtEIdc3ZZO2OSAsgzPNEVrUzE%3D&reserved=0"
>>>>>>>>>>>
>>>>>>>>>>> xmlns:xlink="https://na01.safelinks.protection.outlook.com/?url=h <https://na01.safelinks.protection.outlook.com/?url=h>
>>>>>>>>>>> ttps%3A%2F%2Fna01.safelinks.protection.outlook&data=02%7C01%7C%7C
>>>>>>>>>>> b9d4d9d3a67f4966e3d408d5212b2186%7Cfa7b1b5a7b34438794aed2c178dece
>>>>>>>>>>> e1%7C0%7C0%7C636451391482803219&sdata=ktDZs9Vj6Xaj54l6mSCBB%2F4il
>>>>>>>>>>> MnVzVejNCdYJFBVjQc%3D&reserved=0.
>>>>>>>>> com/?url=http%3A%2
>>>>>>>>>>> F%2Fwww.w3.org <http://2fwww.w3.org/>%2F1999%2Fxlink&data=02%7C01%7C%
>>>>>>>>> 7Cc23665e118fc4a7fed4c08d52
>>>>>>>>>>> 08c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>>>>> 7C636450710247213906&s
>>>>>>>>>>>
>>>>>>>>>>> data=sgNtytSumzad%2BraDA6NoITbm6XqJJx6yHQudjzhpm6Y%3D&reserved=0"
>>>>>>>>>>>>
>>>>>>>>>>> <!-- Generator: Sketch 47.1 (45422) -
>>>>>>>>>>>
>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url= <https://na01.safelinks.protection.outlook.com/?url=>
>>>>>>>>> http%3A%2F%2Fwww.bohem
>>>>>>>>>>> iancoding.com <http://iancoding.com/>%2Fsketch&data=02%7C01%7C%
>>>>>> 7Cc23665e118fc4a7fed4c08d5208c
>>>>>>>>> 8494
>>>>>>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>>>>> 7C636450710247213906&sdata=dE
>>>>>>>>>>> oGVBONBD6Z1XMTjYcpEc7gq5UqtS8BziB0I3f9qSs%3D&reserved=0 -->
>>>>>>>>>>> <desc>Created with Sketch.</desc>
>>>>>>>>>>> <defs>
>>>>>>>>>>> <rect id="path-1" x="0" y="0" width="150" height="40"
>>>>>>>>>>> rx="3"></rect>
>>>>>>>>>>> </defs>
>>>>>>>>>>> <g id="Page-1" stroke="none" stroke-width="1" fill="none"
>>>>>>>>>>> fill-rule="evenodd">
>>>>>>>>>>> <g id="Royale" transform="translate(-58.000000,
>>>>>>>>>>> -49.000000)">
>>>>>>>>>>> <g id="Button" transform="translate(58.000000,
>>>>>>>> 49.000000)">
>>>>>>>>>>> <g id="Background">
>>>>>>>>>>> <use fill="#D8D8D8" fill-rule="evenodd"
>>>>>>>>>>> xlink:href="#path-1"></use>
>>>>>>>>>>> <rect stroke="#979797" stroke-width="1" x="0.5"
>>>>>>>>>>> y="0.5"
>>>>>>>>>>> width="149" height="39" rx="3"></rect>
>>>>>>>>>>> </g>
>>>>>>>>>>> <text id="TextField" font-family="HelveticaNeue,
>>>>>>>>>>> Helvetica
>>>>>>>>>>> Neue" font-size="12" font-weight="normal" fill="#646D7A">
>>>>>>>>>>> <tspan x="57" y="25">Button</tspan>
>>>>>>>>>>> </text>
>>>>>>>>>>> </g>
>>>>>>>>>>> </g>
>>>>>>>>>>> </g>
>>>>>>>>>>> </svg>
>>>>>>>>>>>
>>>>>>>>>>> (SVG could be a base, but it needs to be removed absolute
>>>>>>>>>>> values and
>>>>>>>>>>> even
>>>>>>>>>>> some static parts to be usable)
>>>>>>>>>>>
>>>>>>>>>>> I'd like to create a Button "playground" app with a button and
>>>>>>>>>>> some
>>>>>>>>>>> controls that allow us to change how the button looks (colors,
>>>>>>>> strokes,
>>>>>>>>>>> round corners, font face, font weight,....)
>>>>>>>>>>>
>>>>>>>>>>> In the end this would be the starting point of a playground app
>>>>>>>>>>> for
>>>>>>>> all
>>>>>>>>>>> Royale controls
>>>>>>>>>>>
>>>>>>>>>>> Finaly this would be very useful if we can get the generated
>>>>>>>>>>> code for
>>>>>>>>>>> that
>>>>>>>>>>> particular styles and we could apply easily to any app, so
>>>>>>>>>>> change a
>>>>>>>>>>> "theme"
>>>>>>>>>>> will be quick and easy. Important: This will only work with our
>>>>>> Royale
>>>>>>>>>>> components (Express mainly, and maybe Basic?, but not MDL,
>>>>>>>>>>> CreateJS,
>>>>>>>> or
>>>>>>>>>>> others)
>>>>>>>>>>>
>>>>>>>>>>> I'm as well interested in how we could integrate that "view" in
>>>>>>>>>>> some
>>>>>>>>>>> component in order to easy replace visuals for a concrete
>>>>>>>>>>> component.
>>>>>>>> For
>>>>>>>>>>> example, in the button above will be
>>>>>>>>>>>
>>>>>>>>>>> * we'll be making a skin part with SVG code, so we could pass
>>>>>>>>>>> values
>>>>>>>> to
>>>>>>>>>>> the
>>>>>>>>>>> skin (for example colors, text button, width,...)
>>>>>>>>>>> * if not using skins, how can we pass data from the component
>>>>>>>>>>> to the
>>>>>>>> svg
>>>>>>>>>>> part? (for example colors, text button, width,...)
>>>>>>>>>>>
>>>>>>>>>>> To progress with this effort, I think I could start doing only
>>>>>>>>>>> two
>>>>>>>>>>> controls, and then as we have all considerations in place
>>>>>>>>>>> progress
>>>>>>>>>>> through
>>>>>>>>>>> the rest.
>>>>>>>>>>>
>>>>>>>>>>> Thoughts?
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Carlos Rovira
>>>>>>>>>>>
>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url= <https://na01.safelinks.protection.outlook.com/?url=>
>>>>>>>>> http%3A%2F%2Fabout.me <http://2fabout.me/>%
>>>>>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>>>> 8494%7Cfa7b1
>>>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>>>>> sdata=auPeQ0ub4B
>>>>>>>>>>> Iq%2FTscLQWJ0Xxb9XdM2eegav2v1LXcuYY%3D&reserved=0
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Piotr Zarzycki
>>>>>>>>>>
>>>>>>>>>> mobile: +48 880 859 557
>>>>>>>>>> skype: zarzycki10
>>>>>>>>>>
>>>>>>>>>> LinkedIn:
>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url= <https://na01.safelinks.protection.outlook.com/?url=>
>>>>>>>>> http%3A%2F%2Fwww.linked
>>>>>>>>>>
>>>>>>>>>> in.com <http://in.com/>%2Fpiotrzarzycki&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d52
>>>>>>>>>> 08c
>>>>>>>>> 8494%
>>>>>>>>>> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>> 7C636450710247213906&sdata=
>>>>>>>>> xZ56
>>>>>>>>>> se7Z6gcWKcC7PuWDPW0E6F9wQjEZkuYZO4zvwnY%3D&reserved=0
>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url= <https://na01.safelinks.protection.outlook.com/?url=>
>>>>>>>>> https%3A%2F%2Fpl.linke
>>>>>>>>>> din.com <http://din.com/>%2Fin%2Fpiotr-zarzycki-92a53552&data=02%
>>>>>>>>> 7C01%7C%7Cc23665e118fc4a7fe
>>>>>>>>>> d4c08d5208c8494%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>>> cee1%7C0%7C0%7C6364507102472
>>>>>>>>>> 13906&sdata=1pwc5Fz1vKM2YCp6yUSe6x1Zdh9Au2
>>>>>> xqb28Duy2Tqac%3D&reserved=0>
>>>>>>>>>>
>>>>>>>>>> GitHub:
>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url= <https://na01.safelinks.protection.outlook.com/?url=>
>>>>>>>>> https%3A%2F%2Fgithub.co <http://2fgithub.co/>
>>>>>>>>>>
>>>>>>>>>> m%2Fpiotrzarzycki21&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>>>> 8494%7Cf
>>>>>>>>>>
>>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata
>>>>>>>>>> =
>>>>>>>>> Lr7JdnU
>>>>>>>>>> fF%2F4xHJbXVZlZN%2Fw7t4Tz5R5KbZFwdVnZFww%3D&reserved=0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Piotr Zarzycki
>>>>>>>>
>>>>>>>> mobile: +48 880 859 557
>>>>>>>> skype: zarzycki10
>>>>>>>>
>>>>>>>> LinkedIn:
>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww>.
>>>>>>>> linkedin.com <http://linkedin.com/>%2Fpiotrzarzycki&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d40
>>>>>>>> 8d5212b2186%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63645139148
>>>>>>>> 2803219&sdata=tyzNuWZuxf31LlC5KYeawLoK%2FbKdUNY8qUYPZoQIjHY%3D&reser
>>>>>>>> ved=0
>>>>>>>>
>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpl <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpl>
>>>>>>>> .linkedin.com <http://linkedin.com/>%2Fin%2Fpiotr-zarzycki-92a53552&data=02%7C01%7C%7Cb9d4d
>>>>>>>> 9d3a67f4966e3d408d5212b2186%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7
>>>>>>>> C0%7C636451391482803219&sdata=5qGiI2snl1w7pAEBXHq5lZVEv341VP3N4ayOUh
>>>>>>>> m7hAQ%3D&reserved=0>
>>>>>>>>
>>>>>>>> GitHub:
>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit>
>>>>>>>> hub.com <http://hub.com/>%2Fpiotrzarzycki21&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d408d5
>>>>>>>> 212b2186%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63645139148280
>>>>>>>> 3219&sdata=dlDT6IuVl8iOnXgsDeIpp7DuYh9i%2BWtt075Oo9tPvVE%3D&reserved
>>>>>>>> =0
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carlos Rovira
>>>>>>>
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout>
>>>>>>> .me%2Fcarlosrovira&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d408d5212b2186
>>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636451391482803219&sdat
>>>>>>> a=4N0ssWJeZzwb5z4%2B6SsNa7SiL5X6SCLM9XhuIWLvvrg%3D&reserved=0
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.co <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.co>
>>>>> deoscopic.com <http://deoscopic.com/>&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d408d5212b2186%7Cfa7b
>>>>> 1b5a7b34438794aed2c178decee1%7C0%7C0%7C636451391482803219&sdata=ksmohCa
>>>>> Xf0%2BKodKBLwMI%2BBsDlG9Ssg6Ii0yvUBJ8OLo%3D&reserved=0>
>>>>>
>>>>> Carlos Rovira
>>>>>
>>>>> Director General
>>>>>
>>>>> M: +34 607 22 60 05
>>>>>
>>>>>
>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cod <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cod>
>>>>> eoscopic.com <http://eoscopic.com/>&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d408d5212b2186%7Cfa7b1
>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636451391482803219&sdata=ksmohCaX
>>>>> f0%2BKodKBLwMI%2BBsDlG9Ssg6Ii0yvUBJ8OLo%3D&reserved=0
>>>>>
>>>>>
>>>>> Conocenos Avant2 en 1 minuto!
>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant>
>>>>> 2.es <http://2.es/>%2F%23video&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d408d5212b2186%7Cfa
>>>>> 7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636451391482803219&sdata=vYnCV
>>>>> HrCos92rLTAJ5TACC9cggLfQkda9qJz4mxSf%2Bo%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.
Re: Working on UI Controls styling
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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
On 11/1/17, 6:18 AM, "Harbs" <ha...@gmail.com> wrote:
>JFYI: the svg classes have been tested very well despite there being very
>few test cases in Royale. 90% of the rendering in my app is using these
>SVG classes.
>
>Our current SVG support is pretty solid.
>
>Harbs
>
>> On Nov 1, 2017, at 3:12 PM, Harbs <ha...@gmail.com> wrote:
>>
>> We also have an SVG package. Look in Basic org/apache/royale/svg.
>>
>> It might make sense to pull the SVG classes out into its own project.
>>
>> The current implementation of SVG wraps each element in a separate svh
>>element, so you get lots of nested SVG elements. We considered adding
>>raw non-wrapped SVG elements, but that has not happened yet.
>>
>> There are drawing commands similar to the Flash Graphics APIs. The
>>drawing APIs work a bit different though. There is a PathBuilder class
>>which abstracts a lot of things, but some classes have similar APIs like
>>drawRect, drawRoundedRect, etc.
>>
>> Check out CompoundGraphic and PathBuilder. PathBuilder has APIs that
>>mimic Flash Graphic very closely and can be used with SVG and
>>theoretically Canvas.
>>
>> HTH,
>> Harbs
>>
>>> On Nov 1, 2017, at 3:00 PM, Harbs <ha...@gmail.com> wrote:
>>>
>>> <js:ImageButton click="flipHorizontally()"
>>>src="assets/images/icons/0896-flip-horizontal2.svg"/>
>>> <js:ImageButton click="flipVertically()"
>>>src="assets/images/icons/0897-flip-vertical2.svg"/>
>>>
>>>
>>>> On Nov 1, 2017, at 2:45 PM, Carlos Rovira
>>>><ca...@codeoscopic.com> wrote:
>>>>
>>>> Hi Harbs,
>>>>
>>>> could you post some basic snippet for this to look at your approach?
>>>>
>>>> Thanks!
>>>>
>>>> 2017-11-01 13:42 GMT+01:00 Harbs <ha...@gmail.com>:
>>>>
>>>>> You can use SVG files instead of PNG files. I’m doing that
>>>>>extensively in
>>>>> my app, but that will only work for components which have src or
>>>>> background-image.
>>>>>
>>>>>> On Nov 1, 2017, at 2:14 PM, Carlos Rovira <ca...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I started a new project as Piotr suggested. After setup I only put
>>>>>>one
>>>>>> single button to start figuring how to do this.
>>>>>>
>>>>>> I'm starting for now with Basic, but as we discussed, don't know if
>>>>>>this
>>>>>> should go directly to express or not...it seems like something we
>>>>>>could
>>>>>> plug into Basic at any time as we can plug beads, and Express will
>>>>>>come
>>>>>> with some theme bundled. That seem the most natural for me right now
>>>>>>
>>>>>> Setting up a CSS-only theme seems pretty straight forward for me,
>>>>>>and I
>>>>>> could go with it for now.
>>>>>>
>>>>>> Regarding SVG, right now I don't see the way to add SVG in Royale.
>>>>>>As
>>>>> Alex
>>>>>> suggested, I think we need to be able to add SVG in MXML.
>>>>>> I was looking at this topic and seems very powerful since it can be
>>>>>> integrated with CSS as well and in HTML
>>>>>>
>>>>>> For Example we have:
>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcss-
>>>>>>tricks.com%2Fusing-svg%2F&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d408d52
>>>>>>12b2186%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364513914828032
>>>>>>19&sdata=iiUxSDh%2Be%2F3Zt37Lo2IdRYxgA8tIeyYTTawRO2WSNOI%3D&reserved=
>>>>>>0
>>>>>>
>>>>>> Maybe I could start with only CSS and see how far I can go, making
>>>>>> wireframe and royale themes, as well trying with PNG images to
>>>>> complement,
>>>>>> but I suppose I'll get stuck soon, so maybe we should talk about SVG
>>>>>> support as well and how hard it would be to make it happen in
>>>>>>Royale. As
>>>>>> well if you know other ways to integrate SVG right now please let
>>>>>>me know
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2017-10-31 21:31 GMT+01:00 Piotr Zarzycki
>>>>>><pi...@gmail.com>:
>>>>>>
>>>>>>> I can say at this point that I really like idea with swappable
>>>>>>>view. In
>>>>>>> most cases view is an ActionScript class where we may have more
>>>>> possibility
>>>>>>> to do things. When I was looking last time into the checkbox it
>>>>>>>for sure
>>>>>>> need to more love, some part of the logic should be moved to the
>>>>>>>View.
>>>>>>>
>>>>>>> Piotr
>>>>>>>
>>>>>>> 2017-10-31 20:50 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>>>>
>>>>>>>> Ugh, Something has gone bad in the Basic components. Things like
>>>>>>>> CheckBox and RadioButton should be creating simple <input
>>>>> type="check"/>
>>>>>>>> and <input type='radio' /> elements.
>>>>>>>>
>>>>>>>> The ability to style everything belongs in a different set of
>>>>> components.
>>>>>>>> Basic is supposed to generate the simplest tree of HTMLElements
>>>>>>>>even if
>>>>>>>> they can't be fully styles. That's so someone can do the
>>>>>>>>equivalent of
>>>>>>>> just using bare bones <input> elements.
>>>>>>>>
>>>>>>>> What is currently in Basic CheckBox and RadioButton might be
>>>>>>>>right for
>>>>>>>> creating fully styleable components, or some other composition of
>>>>>>>> HTMLElements might be better. Carlos, I think that's up to you to
>>>>>>> decide.
>>>>>>>>
>>>>>>>> An alternative approach is to have the JS implementations of
>>>>>>>>CheckBox
>>>>> and
>>>>>>>> RadioButton have views and the views could create the
>>>>>>>>HTMLElements.
>>>>> That
>>>>>>>> seems a bit heavy for the simple case of someone who just wants
>>>>>>>>to use
>>>>>>>> <input type="check" in an app, but that is a possibility.
>>>>>>>>
>>>>>>>> It sounds like you are looking for a way to manipulate SVG at
>>>>>>>>runtime.
>>>>>>> It
>>>>>>>> is fine to have "static SVG" which is a block of SVG with that
>>>>>>>>cannot
>>>>> be
>>>>>>>> modified and thus uses percentages and absolute values as best it
>>>>>>>>can.
>>>>>>>> Then we probably want to have a way to create "dynamic" skins
>>>>>>>>with run
>>>>>>>> code to generate or manipulate SVG. Those will be heavier, but
>>>>>>>>that's
>>>>>>>> PAYG. Should we try to allow SVG tags in MXML files? Then you
>>>>>>>>could
>>>>>>>> write code in an fx:Script block around your SVG tags and
>>>>>>>>manipulate
>>>>> the
>>>>>>>> SVG?
>>>>>>>>
>>>>>>>> So IMO first, we should look into reverting Basic back to single
>>>>>>>>simple
>>>>>>>> HTMLElements where possible, then decide whether we want to have
>>>>>>> swappable
>>>>>>>> views or a new skinnable component set, then build out that
>>>>>>>>component
>>>>> set
>>>>>>>> and see what code it takes to get it to look the way we want it.
>>>>>>>>And
>>>>>>> then
>>>>>>>> we'll know what code is needed and can plan out how to
>>>>>>>>encapsulate and
>>>>>>>> re-use that code.
>>>>>>>>
>>>>>>>> My 2 cents,
>>>>>>>> -Alex
>>>>>>>>
>>>>>>>> On 10/31/17, 11:23 AM, "Piotr Zarzycki"
>>>>>>>><pi...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Carlos,
>>>>>>>>>
>>>>>>>>> I think you should start looking into the Basic module and later
>>>>>>>>>make
>>>>> an
>>>>>>>>> upgrades to Express once you have all components visually
>>>>>>>>>created. I
>>>>>>> would
>>>>>>>>> not think on that stage about how we implement them rather look
>>>>>>>>>how
>>>>> they
>>>>>>>>> look like currently.
>>>>>>>>>
>>>>>>>>> 1) Create small app or run example with that component from our
>>>>>>>>> repository.
>>>>>>>>> 2) Make it visually with theme
>>>>>>>>> 3) Show on the dev list - once we agree on all of them we can
>>>>>>>>>decide
>>>>> how
>>>>>>>>> to
>>>>>>>>> apply those styles.
>>>>>>>>>
>>>>>>>>> My 2 cents. :) Piotr
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017-10-31 19:12 GMT+01:00 Carlos Rovira
>>>>>>>>><ca...@apache.org>:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'm trying to find a valid workflow to start working in two
>>>>>>>>>>initial
>>>>>>>>>> faces
>>>>>>>>>> for Royale components.
>>>>>>>>>>
>>>>>>>>>> I'm talking about to generate some kind of UI sheet with all
>>>>>>>>>>controls
>>>>>>>>>> and a
>>>>>>>>>> basic wireframe style and another one that would be what more
>>>>>>>>>>people
>>>>>>>>>> will
>>>>>>>>>> be using as default in Royale. From here, will be more easy to
>>>>>>>>>>other
>>>>>>>>>> guys
>>>>>>>>>> to change styles. We could event create a Royale Theme editor
>>>>>>>>>>in a
>>>>>>> near
>>>>>>>>>> future.
>>>>>>>>>>
>>>>>>>>>> So, to start working on this I need a design tool, and in this
>>>>>>>>>>case,
>>>>> I
>>>>>>>>>> think that one is Sketch App.
>>>>>>>>>>
>>>>>>>>>> So I can create a design in Sketch with all controls (Button,
>>>>>>> TextInput,
>>>>>>>>>> CheckBox, Panel,...)
>>>>>>>>>>
>>>>>>>>>> From here, I can generate CSS and SVG code
>>>>>>>>>>
>>>>>>>>>> For example the code of this simple button
>>>>>>>>>> (https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> https%3A%2F%2Fsnag.gy
>>>>>>>>>> %2FAm2fRX.jpg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>>> 8494%7Cfa7b1b
>>>>>>>>>> 5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>>>> sdata=Z4b6dMq%2Br
>>>>>>>>>> UmSSxpGYNjgKl0nkRkIlV%2FbQIDLVUIvo6E%3D&reserved=0)
>>>>>>>>>> that
>>>>>>>>>> I did quickly is:
>>>>>>>>>>
>>>>>>>>>> CSS
>>>>>>>>>>
>>>>>>>>>> /* Background: */
>>>>>>>>>> background: #D8D8D8;
>>>>>>>>>> border: 1px solid #979797;
>>>>>>>>>> border-radius: 3px;
>>>>>>>>>>
>>>>>>>>>> /* TextField: */
>>>>>>>>>> font-family: HelveticaNeue;
>>>>>>>>>> font-size: 12px;
>>>>>>>>>> color: #646D7A;
>>>>>>>>>>
>>>>>>>>>> (CSS is almost all usable)
>>>>>>>>>>
>>>>>>>>>> And SVG
>>>>>>>>>>
>>>>>>>>>> <svg width="150px" height="40px" viewBox="0 0 150 40"
>>>>>>>>>>version="1.1"
>>>>>>>>>> xmlns="
>>>>>>>>>>
>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> http%3A%2F%2Fwww.w3.or
>>>>>>>>>> g%2F2000%2Fsvg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>>> 8494%7Cfa7b1
>>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>>>> sdata=cWLJ2jj9Ih
>>>>>>>>>> cGnjAB8GEtEIdc3ZZO2OSAsgzPNEVrUzE%3D&reserved=0"
>>>>>>>>>>
>>>>>>>>>>xmlns:xlink="https://na01.safelinks.protection.outlook.com/?url=h
>>>>>>>>>>ttps%3A%2F%2Fna01.safelinks.protection.outlook&data=02%7C01%7C%7C
>>>>>>>>>>b9d4d9d3a67f4966e3d408d5212b2186%7Cfa7b1b5a7b34438794aed2c178dece
>>>>>>>>>>e1%7C0%7C0%7C636451391482803219&sdata=ktDZs9Vj6Xaj54l6mSCBB%2F4il
>>>>>>>>>>MnVzVejNCdYJFBVjQc%3D&reserved=0.
>>>>>>>> com/?url=http%3A%2
>>>>>>>>>> F%2Fwww.w3.org%2F1999%2Fxlink&data=02%7C01%7C%
>>>>>>>> 7Cc23665e118fc4a7fed4c08d52
>>>>>>>>>> 08c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>>>> 7C636450710247213906&s
>>>>>>>>>>
>>>>>>>>>>data=sgNtytSumzad%2BraDA6NoITbm6XqJJx6yHQudjzhpm6Y%3D&reserved=0"
>>>>>>>>>>>
>>>>>>>>>> <!-- Generator: Sketch 47.1 (45422) -
>>>>>>>>>>
>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> http%3A%2F%2Fwww.bohem
>>>>>>>>>> iancoding.com%2Fsketch&data=02%7C01%7C%
>>>>> 7Cc23665e118fc4a7fed4c08d5208c
>>>>>>>> 8494
>>>>>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>>>> 7C636450710247213906&sdata=dE
>>>>>>>>>> oGVBONBD6Z1XMTjYcpEc7gq5UqtS8BziB0I3f9qSs%3D&reserved=0 -->
>>>>>>>>>> <desc>Created with Sketch.</desc>
>>>>>>>>>> <defs>
>>>>>>>>>> <rect id="path-1" x="0" y="0" width="150" height="40"
>>>>>>>>>> rx="3"></rect>
>>>>>>>>>> </defs>
>>>>>>>>>> <g id="Page-1" stroke="none" stroke-width="1" fill="none"
>>>>>>>>>> fill-rule="evenodd">
>>>>>>>>>> <g id="Royale" transform="translate(-58.000000,
>>>>>>>>>>-49.000000)">
>>>>>>>>>> <g id="Button" transform="translate(58.000000,
>>>>>>> 49.000000)">
>>>>>>>>>> <g id="Background">
>>>>>>>>>> <use fill="#D8D8D8" fill-rule="evenodd"
>>>>>>>>>> xlink:href="#path-1"></use>
>>>>>>>>>> <rect stroke="#979797" stroke-width="1" x="0.5"
>>>>>>>>>> y="0.5"
>>>>>>>>>> width="149" height="39" rx="3"></rect>
>>>>>>>>>> </g>
>>>>>>>>>> <text id="TextField" font-family="HelveticaNeue,
>>>>>>>>>> Helvetica
>>>>>>>>>> Neue" font-size="12" font-weight="normal" fill="#646D7A">
>>>>>>>>>> <tspan x="57" y="25">Button</tspan>
>>>>>>>>>> </text>
>>>>>>>>>> </g>
>>>>>>>>>> </g>
>>>>>>>>>> </g>
>>>>>>>>>> </svg>
>>>>>>>>>>
>>>>>>>>>> (SVG could be a base, but it needs to be removed absolute
>>>>>>>>>>values and
>>>>>>>>>> even
>>>>>>>>>> some static parts to be usable)
>>>>>>>>>>
>>>>>>>>>> I'd like to create a Button "playground" app with a button and
>>>>>>>>>>some
>>>>>>>>>> controls that allow us to change how the button looks (colors,
>>>>>>> strokes,
>>>>>>>>>> round corners, font face, font weight,....)
>>>>>>>>>>
>>>>>>>>>> In the end this would be the starting point of a playground app
>>>>>>>>>>for
>>>>>>> all
>>>>>>>>>> Royale controls
>>>>>>>>>>
>>>>>>>>>> Finaly this would be very useful if we can get the generated
>>>>>>>>>>code for
>>>>>>>>>> that
>>>>>>>>>> particular styles and we could apply easily to any app, so
>>>>>>>>>>change a
>>>>>>>>>> "theme"
>>>>>>>>>> will be quick and easy. Important: This will only work with our
>>>>> Royale
>>>>>>>>>> components (Express mainly, and maybe Basic?, but not MDL,
>>>>>>>>>>CreateJS,
>>>>>>> or
>>>>>>>>>> others)
>>>>>>>>>>
>>>>>>>>>> I'm as well interested in how we could integrate that "view" in
>>>>>>>>>>some
>>>>>>>>>> component in order to easy replace visuals for a concrete
>>>>>>>>>>component.
>>>>>>> For
>>>>>>>>>> example, in the button above will be
>>>>>>>>>>
>>>>>>>>>> * we'll be making a skin part with SVG code, so we could pass
>>>>>>>>>>values
>>>>>>> to
>>>>>>>>>> the
>>>>>>>>>> skin (for example colors, text button, width,...)
>>>>>>>>>> * if not using skins, how can we pass data from the component
>>>>>>>>>>to the
>>>>>>> svg
>>>>>>>>>> part? (for example colors, text button, width,...)
>>>>>>>>>>
>>>>>>>>>> To progress with this effort, I think I could start doing only
>>>>>>>>>>two
>>>>>>>>>> controls, and then as we have all considerations in place
>>>>>>>>>>progress
>>>>>>>>>> through
>>>>>>>>>> the rest.
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Carlos Rovira
>>>>>>>>>>
>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> http%3A%2F%2Fabout.me%
>>>>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>>> 8494%7Cfa7b1
>>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>>>> sdata=auPeQ0ub4B
>>>>>>>>>> Iq%2FTscLQWJ0Xxb9XdM2eegav2v1LXcuYY%3D&reserved=0
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Piotr Zarzycki
>>>>>>>>>
>>>>>>>>> mobile: +48 880 859 557
>>>>>>>>> skype: zarzycki10
>>>>>>>>>
>>>>>>>>> LinkedIn:
>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> http%3A%2F%2Fwww.linked
>>>>>>>>>
>>>>>>>>>in.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d52
>>>>>>>>>08c
>>>>>>>> 8494%
>>>>>>>>> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>> 7C636450710247213906&sdata=
>>>>>>>> xZ56
>>>>>>>>> se7Z6gcWKcC7PuWDPW0E6F9wQjEZkuYZO4zvwnY%3D&reserved=0
>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> https%3A%2F%2Fpl.linke
>>>>>>>>> din.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%
>>>>>>>> 7C01%7C%7Cc23665e118fc4a7fe
>>>>>>>>> d4c08d5208c8494%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>> cee1%7C0%7C0%7C6364507102472
>>>>>>>>> 13906&sdata=1pwc5Fz1vKM2YCp6yUSe6x1Zdh9Au2
>>>>> xqb28Duy2Tqac%3D&reserved=0>
>>>>>>>>>
>>>>>>>>> GitHub:
>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> https%3A%2F%2Fgithub.co
>>>>>>>>>
>>>>>>>>>m%2Fpiotrzarzycki21&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>>> 8494%7Cf
>>>>>>>>>
>>>>>>>>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata
>>>>>>>>>=
>>>>>>>> Lr7JdnU
>>>>>>>>> fF%2F4xHJbXVZlZN%2Fw7t4Tz5R5KbZFwdVnZFww%3D&reserved=0
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Piotr Zarzycki
>>>>>>>
>>>>>>> mobile: +48 880 859 557
>>>>>>> skype: zarzycki10
>>>>>>>
>>>>>>> LinkedIn:
>>>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
>>>>>>>linkedin.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d40
>>>>>>>8d5212b2186%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63645139148
>>>>>>>2803219&sdata=tyzNuWZuxf31LlC5KYeawLoK%2FbKdUNY8qUYPZoQIjHY%3D&reser
>>>>>>>ved=0
>>>>>>>
>>>>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpl
>>>>>>>.linkedin.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%7C01%7C%7Cb9d4d
>>>>>>>9d3a67f4966e3d408d5212b2186%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7
>>>>>>>C0%7C636451391482803219&sdata=5qGiI2snl1w7pAEBXHq5lZVEv341VP3N4ayOUh
>>>>>>>m7hAQ%3D&reserved=0>
>>>>>>>
>>>>>>> GitHub:
>>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>>>>>>>hub.com%2Fpiotrzarzycki21&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d408d5
>>>>>>>212b2186%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63645139148280
>>>>>>>3219&sdata=dlDT6IuVl8iOnXgsDeIpp7DuYh9i%2BWtt075Oo9tPvVE%3D&reserved
>>>>>>>=0
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Carlos Rovira
>>>>>>
>>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout
>>>>>>.me%2Fcarlosrovira&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d408d5212b2186
>>>>>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636451391482803219&sdat
>>>>>>a=4N0ssWJeZzwb5z4%2B6SsNa7SiL5X6SCLM9XhuIWLvvrg%3D&reserved=0
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.co
>>>>deoscopic.com&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d408d5212b2186%7Cfa7b
>>>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636451391482803219&sdata=ksmohCa
>>>>Xf0%2BKodKBLwMI%2BBsDlG9Ssg6Ii0yvUBJ8OLo%3D&reserved=0>
>>>>
>>>> Carlos Rovira
>>>>
>>>> Director General
>>>>
>>>> M: +34 607 22 60 05
>>>>
>>>>
>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cod
>>>>eoscopic.com&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d408d5212b2186%7Cfa7b1
>>>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636451391482803219&sdata=ksmohCaX
>>>>f0%2BKodKBLwMI%2BBsDlG9Ssg6Ii0yvUBJ8OLo%3D&reserved=0
>>>>
>>>>
>>>> Conocenos Avant2 en 1 minuto!
>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant
>>>>2.es%2F%23video&data=02%7C01%7C%7Cb9d4d9d3a67f4966e3d408d5212b2186%7Cfa
>>>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636451391482803219&sdata=vYnCV
>>>>HrCos92rLTAJ5TACC9cggLfQkda9qJz4mxSf%2Bo%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.
>>>
>>
>
Re: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
JFYI: the svg classes have been tested very well despite there being very few test cases in Royale. 90% of the rendering in my app is using these SVG classes.
Our current SVG support is pretty solid.
Harbs
> On Nov 1, 2017, at 3:12 PM, Harbs <ha...@gmail.com> wrote:
>
> We also have an SVG package. Look in Basic org/apache/royale/svg.
>
> It might make sense to pull the SVG classes out into its own project.
>
> The current implementation of SVG wraps each element in a separate svh element, so you get lots of nested SVG elements. We considered adding raw non-wrapped SVG elements, but that has not happened yet.
>
> There are drawing commands similar to the Flash Graphics APIs. The drawing APIs work a bit different though. There is a PathBuilder class which abstracts a lot of things, but some classes have similar APIs like drawRect, drawRoundedRect, etc.
>
> Check out CompoundGraphic and PathBuilder. PathBuilder has APIs that mimic Flash Graphic very closely and can be used with SVG and theoretically Canvas.
>
> HTH,
> Harbs
>
>> On Nov 1, 2017, at 3:00 PM, Harbs <ha...@gmail.com> wrote:
>>
>> <js:ImageButton click="flipHorizontally()" src="assets/images/icons/0896-flip-horizontal2.svg"/>
>> <js:ImageButton click="flipVertically()" src="assets/images/icons/0897-flip-vertical2.svg"/>
>>
>>
>>> On Nov 1, 2017, at 2:45 PM, Carlos Rovira <ca...@codeoscopic.com> wrote:
>>>
>>> Hi Harbs,
>>>
>>> could you post some basic snippet for this to look at your approach?
>>>
>>> Thanks!
>>>
>>> 2017-11-01 13:42 GMT+01:00 Harbs <ha...@gmail.com>:
>>>
>>>> You can use SVG files instead of PNG files. I’m doing that extensively in
>>>> my app, but that will only work for components which have src or
>>>> background-image.
>>>>
>>>>> On Nov 1, 2017, at 2:14 PM, Carlos Rovira <ca...@apache.org>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I started a new project as Piotr suggested. After setup I only put one
>>>>> single button to start figuring how to do this.
>>>>>
>>>>> I'm starting for now with Basic, but as we discussed, don't know if this
>>>>> should go directly to express or not...it seems like something we could
>>>>> plug into Basic at any time as we can plug beads, and Express will come
>>>>> with some theme bundled. That seem the most natural for me right now
>>>>>
>>>>> Setting up a CSS-only theme seems pretty straight forward for me, and I
>>>>> could go with it for now.
>>>>>
>>>>> Regarding SVG, right now I don't see the way to add SVG in Royale. As
>>>> Alex
>>>>> suggested, I think we need to be able to add SVG in MXML.
>>>>> I was looking at this topic and seems very powerful since it can be
>>>>> integrated with CSS as well and in HTML
>>>>>
>>>>> For Example we have: https://css-tricks.com/using-svg/
>>>>>
>>>>> Maybe I could start with only CSS and see how far I can go, making
>>>>> wireframe and royale themes, as well trying with PNG images to
>>>> complement,
>>>>> but I suppose I'll get stuck soon, so maybe we should talk about SVG
>>>>> support as well and how hard it would be to make it happen in Royale. As
>>>>> well if you know other ways to integrate SVG right now please let me know
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2017-10-31 21:31 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
>>>>>
>>>>>> I can say at this point that I really like idea with swappable view. In
>>>>>> most cases view is an ActionScript class where we may have more
>>>> possibility
>>>>>> to do things. When I was looking last time into the checkbox it for sure
>>>>>> need to more love, some part of the logic should be moved to the View.
>>>>>>
>>>>>> Piotr
>>>>>>
>>>>>> 2017-10-31 20:50 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>>>
>>>>>>> Ugh, Something has gone bad in the Basic components. Things like
>>>>>>> CheckBox and RadioButton should be creating simple <input
>>>> type="check"/>
>>>>>>> and <input type='radio' /> elements.
>>>>>>>
>>>>>>> The ability to style everything belongs in a different set of
>>>> components.
>>>>>>> Basic is supposed to generate the simplest tree of HTMLElements even if
>>>>>>> they can't be fully styles. That's so someone can do the equivalent of
>>>>>>> just using bare bones <input> elements.
>>>>>>>
>>>>>>> What is currently in Basic CheckBox and RadioButton might be right for
>>>>>>> creating fully styleable components, or some other composition of
>>>>>>> HTMLElements might be better. Carlos, I think that's up to you to
>>>>>> decide.
>>>>>>>
>>>>>>> An alternative approach is to have the JS implementations of CheckBox
>>>> and
>>>>>>> RadioButton have views and the views could create the HTMLElements.
>>>> That
>>>>>>> seems a bit heavy for the simple case of someone who just wants to use
>>>>>>> <input type="check" in an app, but that is a possibility.
>>>>>>>
>>>>>>> It sounds like you are looking for a way to manipulate SVG at runtime.
>>>>>> It
>>>>>>> is fine to have "static SVG" which is a block of SVG with that cannot
>>>> be
>>>>>>> modified and thus uses percentages and absolute values as best it can.
>>>>>>> Then we probably want to have a way to create "dynamic" skins with run
>>>>>>> code to generate or manipulate SVG. Those will be heavier, but that's
>>>>>>> PAYG. Should we try to allow SVG tags in MXML files? Then you could
>>>>>>> write code in an fx:Script block around your SVG tags and manipulate
>>>> the
>>>>>>> SVG?
>>>>>>>
>>>>>>> So IMO first, we should look into reverting Basic back to single simple
>>>>>>> HTMLElements where possible, then decide whether we want to have
>>>>>> swappable
>>>>>>> views or a new skinnable component set, then build out that component
>>>> set
>>>>>>> and see what code it takes to get it to look the way we want it. And
>>>>>> then
>>>>>>> we'll know what code is needed and can plan out how to encapsulate and
>>>>>>> re-use that code.
>>>>>>>
>>>>>>> My 2 cents,
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 10/31/17, 11:23 AM, "Piotr Zarzycki" <pi...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Carlos,
>>>>>>>>
>>>>>>>> I think you should start looking into the Basic module and later make
>>>> an
>>>>>>>> upgrades to Express once you have all components visually created. I
>>>>>> would
>>>>>>>> not think on that stage about how we implement them rather look how
>>>> they
>>>>>>>> look like currently.
>>>>>>>>
>>>>>>>> 1) Create small app or run example with that component from our
>>>>>>>> repository.
>>>>>>>> 2) Make it visually with theme
>>>>>>>> 3) Show on the dev list - once we agree on all of them we can decide
>>>> how
>>>>>>>> to
>>>>>>>> apply those styles.
>>>>>>>>
>>>>>>>> My 2 cents. :) Piotr
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017-10-31 19:12 GMT+01:00 Carlos Rovira <ca...@apache.org>:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm trying to find a valid workflow to start working in two initial
>>>>>>>>> faces
>>>>>>>>> for Royale components.
>>>>>>>>>
>>>>>>>>> I'm talking about to generate some kind of UI sheet with all controls
>>>>>>>>> and a
>>>>>>>>> basic wireframe style and another one that would be what more people
>>>>>>>>> will
>>>>>>>>> be using as default in Royale. From here, will be more easy to other
>>>>>>>>> guys
>>>>>>>>> to change styles. We could event create a Royale Theme editor in a
>>>>>> near
>>>>>>>>> future.
>>>>>>>>>
>>>>>>>>> So, to start working on this I need a design tool, and in this case,
>>>> I
>>>>>>>>> think that one is Sketch App.
>>>>>>>>>
>>>>>>>>> So I can create a design in Sketch with all controls (Button,
>>>>>> TextInput,
>>>>>>>>> CheckBox, Panel,...)
>>>>>>>>>
>>>>>>>>> From here, I can generate CSS and SVG code
>>>>>>>>>
>>>>>>>>> For example the code of this simple button
>>>>>>>>> (https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> https%3A%2F%2Fsnag.gy
>>>>>>>>> %2FAm2fRX.jpg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>> 8494%7Cfa7b1b
>>>>>>>>> 5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>>> sdata=Z4b6dMq%2Br
>>>>>>>>> UmSSxpGYNjgKl0nkRkIlV%2FbQIDLVUIvo6E%3D&reserved=0)
>>>>>>>>> that
>>>>>>>>> I did quickly is:
>>>>>>>>>
>>>>>>>>> CSS
>>>>>>>>>
>>>>>>>>> /* Background: */
>>>>>>>>> background: #D8D8D8;
>>>>>>>>> border: 1px solid #979797;
>>>>>>>>> border-radius: 3px;
>>>>>>>>>
>>>>>>>>> /* TextField: */
>>>>>>>>> font-family: HelveticaNeue;
>>>>>>>>> font-size: 12px;
>>>>>>>>> color: #646D7A;
>>>>>>>>>
>>>>>>>>> (CSS is almost all usable)
>>>>>>>>>
>>>>>>>>> And SVG
>>>>>>>>>
>>>>>>>>> <svg width="150px" height="40px" viewBox="0 0 150 40" version="1.1"
>>>>>>>>> xmlns="
>>>>>>>>>
>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> http%3A%2F%2Fwww.w3.or
>>>>>>>>> g%2F2000%2Fsvg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>> 8494%7Cfa7b1
>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>>> sdata=cWLJ2jj9Ih
>>>>>>>>> cGnjAB8GEtEIdc3ZZO2OSAsgzPNEVrUzE%3D&reserved=0"
>>>>>>>>> xmlns:xlink="https://na01.safelinks.protection.outlook.
>>>>>>> com/?url=http%3A%2
>>>>>>>>> F%2Fwww.w3.org%2F1999%2Fxlink&data=02%7C01%7C%
>>>>>>> 7Cc23665e118fc4a7fed4c08d52
>>>>>>>>> 08c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>>> 7C636450710247213906&s
>>>>>>>>> data=sgNtytSumzad%2BraDA6NoITbm6XqJJx6yHQudjzhpm6Y%3D&reserved=0">
>>>>>>>>> <!-- Generator: Sketch 47.1 (45422) -
>>>>>>>>>
>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> http%3A%2F%2Fwww.bohem
>>>>>>>>> iancoding.com%2Fsketch&data=02%7C01%7C%
>>>> 7Cc23665e118fc4a7fed4c08d5208c
>>>>>>> 8494
>>>>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>>> 7C636450710247213906&sdata=dE
>>>>>>>>> oGVBONBD6Z1XMTjYcpEc7gq5UqtS8BziB0I3f9qSs%3D&reserved=0 -->
>>>>>>>>> <desc>Created with Sketch.</desc>
>>>>>>>>> <defs>
>>>>>>>>> <rect id="path-1" x="0" y="0" width="150" height="40"
>>>>>>>>> rx="3"></rect>
>>>>>>>>> </defs>
>>>>>>>>> <g id="Page-1" stroke="none" stroke-width="1" fill="none"
>>>>>>>>> fill-rule="evenodd">
>>>>>>>>> <g id="Royale" transform="translate(-58.000000, -49.000000)">
>>>>>>>>> <g id="Button" transform="translate(58.000000,
>>>>>> 49.000000)">
>>>>>>>>> <g id="Background">
>>>>>>>>> <use fill="#D8D8D8" fill-rule="evenodd"
>>>>>>>>> xlink:href="#path-1"></use>
>>>>>>>>> <rect stroke="#979797" stroke-width="1" x="0.5"
>>>>>>>>> y="0.5"
>>>>>>>>> width="149" height="39" rx="3"></rect>
>>>>>>>>> </g>
>>>>>>>>> <text id="TextField" font-family="HelveticaNeue,
>>>>>>>>> Helvetica
>>>>>>>>> Neue" font-size="12" font-weight="normal" fill="#646D7A">
>>>>>>>>> <tspan x="57" y="25">Button</tspan>
>>>>>>>>> </text>
>>>>>>>>> </g>
>>>>>>>>> </g>
>>>>>>>>> </g>
>>>>>>>>> </svg>
>>>>>>>>>
>>>>>>>>> (SVG could be a base, but it needs to be removed absolute values and
>>>>>>>>> even
>>>>>>>>> some static parts to be usable)
>>>>>>>>>
>>>>>>>>> I'd like to create a Button "playground" app with a button and some
>>>>>>>>> controls that allow us to change how the button looks (colors,
>>>>>> strokes,
>>>>>>>>> round corners, font face, font weight,....)
>>>>>>>>>
>>>>>>>>> In the end this would be the starting point of a playground app for
>>>>>> all
>>>>>>>>> Royale controls
>>>>>>>>>
>>>>>>>>> Finaly this would be very useful if we can get the generated code for
>>>>>>>>> that
>>>>>>>>> particular styles and we could apply easily to any app, so change a
>>>>>>>>> "theme"
>>>>>>>>> will be quick and easy. Important: This will only work with our
>>>> Royale
>>>>>>>>> components (Express mainly, and maybe Basic?, but not MDL, CreateJS,
>>>>>> or
>>>>>>>>> others)
>>>>>>>>>
>>>>>>>>> I'm as well interested in how we could integrate that "view" in some
>>>>>>>>> component in order to easy replace visuals for a concrete component.
>>>>>> For
>>>>>>>>> example, in the button above will be
>>>>>>>>>
>>>>>>>>> * we'll be making a skin part with SVG code, so we could pass values
>>>>>> to
>>>>>>>>> the
>>>>>>>>> skin (for example colors, text button, width,...)
>>>>>>>>> * if not using skins, how can we pass data from the component to the
>>>>>> svg
>>>>>>>>> part? (for example colors, text button, width,...)
>>>>>>>>>
>>>>>>>>> To progress with this effort, I think I could start doing only two
>>>>>>>>> controls, and then as we have all considerations in place progress
>>>>>>>>> through
>>>>>>>>> the rest.
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Carlos Rovira
>>>>>>>>>
>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> http%3A%2F%2Fabout.me%
>>>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>> 8494%7Cfa7b1
>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>>> sdata=auPeQ0ub4B
>>>>>>>>> Iq%2FTscLQWJ0Xxb9XdM2eegav2v1LXcuYY%3D&reserved=0
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Piotr Zarzycki
>>>>>>>>
>>>>>>>> mobile: +48 880 859 557
>>>>>>>> skype: zarzycki10
>>>>>>>>
>>>>>>>> LinkedIn:
>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> http%3A%2F%2Fwww.linked
>>>>>>>> in.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>> 8494%
>>>>>>>> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>> 7C636450710247213906&sdata=
>>>>>>> xZ56
>>>>>>>> se7Z6gcWKcC7PuWDPW0E6F9wQjEZkuYZO4zvwnY%3D&reserved=0
>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> https%3A%2F%2Fpl.linke
>>>>>>>> din.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%
>>>>>>> 7C01%7C%7Cc23665e118fc4a7fe
>>>>>>>> d4c08d5208c8494%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>> cee1%7C0%7C0%7C6364507102472
>>>>>>>> 13906&sdata=1pwc5Fz1vKM2YCp6yUSe6x1Zdh9Au2
>>>> xqb28Duy2Tqac%3D&reserved=0>
>>>>>>>>
>>>>>>>> GitHub:
>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>> https%3A%2F%2Fgithub.co
>>>>>>>> m%2Fpiotrzarzycki21&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>>> 8494%7Cf
>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=
>>>>>>> Lr7JdnU
>>>>>>>> fF%2F4xHJbXVZlZN%2Fw7t4Tz5R5KbZFwdVnZFww%3D&reserved=0
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Piotr Zarzycki
>>>>>>
>>>>>> mobile: +48 880 859 557
>>>>>> skype: zarzycki10
>>>>>>
>>>>>> LinkedIn: http://www.linkedin.com/piotrzarzycki
>>>>>> <https://pl.linkedin.com/in/piotr-zarzycki-92a53552>
>>>>>>
>>>>>> GitHub: https://github.com/piotrzarzycki21
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>> http://about.me/carlosrovira
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> <http://www.codeoscopic.com>
>>>
>>> Carlos Rovira
>>>
>>> Director General
>>>
>>> M: +34 607 22 60 05
>>>
>>> http://www.codeoscopic.com
>>>
>>>
>>> Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
>>>
>>>
>>> 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: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
We also have an SVG package. Look in Basic org/apache/royale/svg.
It might make sense to pull the SVG classes out into its own project.
The current implementation of SVG wraps each element in a separate svh element, so you get lots of nested SVG elements. We considered adding raw non-wrapped SVG elements, but that has not happened yet.
There are drawing commands similar to the Flash Graphics APIs. The drawing APIs work a bit different though. There is a PathBuilder class which abstracts a lot of things, but some classes have similar APIs like drawRect, drawRoundedRect, etc.
Check out CompoundGraphic and PathBuilder. PathBuilder has APIs that mimic Flash Graphic very closely and can be used with SVG and theoretically Canvas.
HTH,
Harbs
> On Nov 1, 2017, at 3:00 PM, Harbs <ha...@gmail.com> wrote:
>
> <js:ImageButton click="flipHorizontally()" src="assets/images/icons/0896-flip-horizontal2.svg"/>
> <js:ImageButton click="flipVertically()" src="assets/images/icons/0897-flip-vertical2.svg"/>
>
>
>> On Nov 1, 2017, at 2:45 PM, Carlos Rovira <ca...@codeoscopic.com> wrote:
>>
>> Hi Harbs,
>>
>> could you post some basic snippet for this to look at your approach?
>>
>> Thanks!
>>
>> 2017-11-01 13:42 GMT+01:00 Harbs <ha...@gmail.com>:
>>
>>> You can use SVG files instead of PNG files. I’m doing that extensively in
>>> my app, but that will only work for components which have src or
>>> background-image.
>>>
>>>> On Nov 1, 2017, at 2:14 PM, Carlos Rovira <ca...@apache.org>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I started a new project as Piotr suggested. After setup I only put one
>>>> single button to start figuring how to do this.
>>>>
>>>> I'm starting for now with Basic, but as we discussed, don't know if this
>>>> should go directly to express or not...it seems like something we could
>>>> plug into Basic at any time as we can plug beads, and Express will come
>>>> with some theme bundled. That seem the most natural for me right now
>>>>
>>>> Setting up a CSS-only theme seems pretty straight forward for me, and I
>>>> could go with it for now.
>>>>
>>>> Regarding SVG, right now I don't see the way to add SVG in Royale. As
>>> Alex
>>>> suggested, I think we need to be able to add SVG in MXML.
>>>> I was looking at this topic and seems very powerful since it can be
>>>> integrated with CSS as well and in HTML
>>>>
>>>> For Example we have: https://css-tricks.com/using-svg/
>>>>
>>>> Maybe I could start with only CSS and see how far I can go, making
>>>> wireframe and royale themes, as well trying with PNG images to
>>> complement,
>>>> but I suppose I'll get stuck soon, so maybe we should talk about SVG
>>>> support as well and how hard it would be to make it happen in Royale. As
>>>> well if you know other ways to integrate SVG right now please let me know
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>>
>>>> 2017-10-31 21:31 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
>>>>
>>>>> I can say at this point that I really like idea with swappable view. In
>>>>> most cases view is an ActionScript class where we may have more
>>> possibility
>>>>> to do things. When I was looking last time into the checkbox it for sure
>>>>> need to more love, some part of the logic should be moved to the View.
>>>>>
>>>>> Piotr
>>>>>
>>>>> 2017-10-31 20:50 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>>
>>>>>> Ugh, Something has gone bad in the Basic components. Things like
>>>>>> CheckBox and RadioButton should be creating simple <input
>>> type="check"/>
>>>>>> and <input type='radio' /> elements.
>>>>>>
>>>>>> The ability to style everything belongs in a different set of
>>> components.
>>>>>> Basic is supposed to generate the simplest tree of HTMLElements even if
>>>>>> they can't be fully styles. That's so someone can do the equivalent of
>>>>>> just using bare bones <input> elements.
>>>>>>
>>>>>> What is currently in Basic CheckBox and RadioButton might be right for
>>>>>> creating fully styleable components, or some other composition of
>>>>>> HTMLElements might be better. Carlos, I think that's up to you to
>>>>> decide.
>>>>>>
>>>>>> An alternative approach is to have the JS implementations of CheckBox
>>> and
>>>>>> RadioButton have views and the views could create the HTMLElements.
>>> That
>>>>>> seems a bit heavy for the simple case of someone who just wants to use
>>>>>> <input type="check" in an app, but that is a possibility.
>>>>>>
>>>>>> It sounds like you are looking for a way to manipulate SVG at runtime.
>>>>> It
>>>>>> is fine to have "static SVG" which is a block of SVG with that cannot
>>> be
>>>>>> modified and thus uses percentages and absolute values as best it can.
>>>>>> Then we probably want to have a way to create "dynamic" skins with run
>>>>>> code to generate or manipulate SVG. Those will be heavier, but that's
>>>>>> PAYG. Should we try to allow SVG tags in MXML files? Then you could
>>>>>> write code in an fx:Script block around your SVG tags and manipulate
>>> the
>>>>>> SVG?
>>>>>>
>>>>>> So IMO first, we should look into reverting Basic back to single simple
>>>>>> HTMLElements where possible, then decide whether we want to have
>>>>> swappable
>>>>>> views or a new skinnable component set, then build out that component
>>> set
>>>>>> and see what code it takes to get it to look the way we want it. And
>>>>> then
>>>>>> we'll know what code is needed and can plan out how to encapsulate and
>>>>>> re-use that code.
>>>>>>
>>>>>> My 2 cents,
>>>>>> -Alex
>>>>>>
>>>>>> On 10/31/17, 11:23 AM, "Piotr Zarzycki" <pi...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>>> Hi Carlos,
>>>>>>>
>>>>>>> I think you should start looking into the Basic module and later make
>>> an
>>>>>>> upgrades to Express once you have all components visually created. I
>>>>> would
>>>>>>> not think on that stage about how we implement them rather look how
>>> they
>>>>>>> look like currently.
>>>>>>>
>>>>>>> 1) Create small app or run example with that component from our
>>>>>>> repository.
>>>>>>> 2) Make it visually with theme
>>>>>>> 3) Show on the dev list - once we agree on all of them we can decide
>>> how
>>>>>>> to
>>>>>>> apply those styles.
>>>>>>>
>>>>>>> My 2 cents. :) Piotr
>>>>>>>
>>>>>>>
>>>>>>> 2017-10-31 19:12 GMT+01:00 Carlos Rovira <ca...@apache.org>:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm trying to find a valid workflow to start working in two initial
>>>>>>>> faces
>>>>>>>> for Royale components.
>>>>>>>>
>>>>>>>> I'm talking about to generate some kind of UI sheet with all controls
>>>>>>>> and a
>>>>>>>> basic wireframe style and another one that would be what more people
>>>>>>>> will
>>>>>>>> be using as default in Royale. From here, will be more easy to other
>>>>>>>> guys
>>>>>>>> to change styles. We could event create a Royale Theme editor in a
>>>>> near
>>>>>>>> future.
>>>>>>>>
>>>>>>>> So, to start working on this I need a design tool, and in this case,
>>> I
>>>>>>>> think that one is Sketch App.
>>>>>>>>
>>>>>>>> So I can create a design in Sketch with all controls (Button,
>>>>> TextInput,
>>>>>>>> CheckBox, Panel,...)
>>>>>>>>
>>>>>>>> From here, I can generate CSS and SVG code
>>>>>>>>
>>>>>>>> For example the code of this simple button
>>>>>>>> (https://na01.safelinks.protection.outlook.com/?url=
>>>>>> https%3A%2F%2Fsnag.gy
>>>>>>>> %2FAm2fRX.jpg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>> 8494%7Cfa7b1b
>>>>>>>> 5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>> sdata=Z4b6dMq%2Br
>>>>>>>> UmSSxpGYNjgKl0nkRkIlV%2FbQIDLVUIvo6E%3D&reserved=0)
>>>>>>>> that
>>>>>>>> I did quickly is:
>>>>>>>>
>>>>>>>> CSS
>>>>>>>>
>>>>>>>> /* Background: */
>>>>>>>> background: #D8D8D8;
>>>>>>>> border: 1px solid #979797;
>>>>>>>> border-radius: 3px;
>>>>>>>>
>>>>>>>> /* TextField: */
>>>>>>>> font-family: HelveticaNeue;
>>>>>>>> font-size: 12px;
>>>>>>>> color: #646D7A;
>>>>>>>>
>>>>>>>> (CSS is almost all usable)
>>>>>>>>
>>>>>>>> And SVG
>>>>>>>>
>>>>>>>> <svg width="150px" height="40px" viewBox="0 0 150 40" version="1.1"
>>>>>>>> xmlns="
>>>>>>>>
>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>> http%3A%2F%2Fwww.w3.or
>>>>>>>> g%2F2000%2Fsvg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>> 8494%7Cfa7b1
>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>> sdata=cWLJ2jj9Ih
>>>>>>>> cGnjAB8GEtEIdc3ZZO2OSAsgzPNEVrUzE%3D&reserved=0"
>>>>>>>> xmlns:xlink="https://na01.safelinks.protection.outlook.
>>>>>> com/?url=http%3A%2
>>>>>>>> F%2Fwww.w3.org%2F1999%2Fxlink&data=02%7C01%7C%
>>>>>> 7Cc23665e118fc4a7fed4c08d52
>>>>>>>> 08c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>> 7C636450710247213906&s
>>>>>>>> data=sgNtytSumzad%2BraDA6NoITbm6XqJJx6yHQudjzhpm6Y%3D&reserved=0">
>>>>>>>> <!-- Generator: Sketch 47.1 (45422) -
>>>>>>>>
>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>> http%3A%2F%2Fwww.bohem
>>>>>>>> iancoding.com%2Fsketch&data=02%7C01%7C%
>>> 7Cc23665e118fc4a7fed4c08d5208c
>>>>>> 8494
>>>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>> 7C636450710247213906&sdata=dE
>>>>>>>> oGVBONBD6Z1XMTjYcpEc7gq5UqtS8BziB0I3f9qSs%3D&reserved=0 -->
>>>>>>>> <desc>Created with Sketch.</desc>
>>>>>>>> <defs>
>>>>>>>> <rect id="path-1" x="0" y="0" width="150" height="40"
>>>>>>>> rx="3"></rect>
>>>>>>>> </defs>
>>>>>>>> <g id="Page-1" stroke="none" stroke-width="1" fill="none"
>>>>>>>> fill-rule="evenodd">
>>>>>>>> <g id="Royale" transform="translate(-58.000000, -49.000000)">
>>>>>>>> <g id="Button" transform="translate(58.000000,
>>>>> 49.000000)">
>>>>>>>> <g id="Background">
>>>>>>>> <use fill="#D8D8D8" fill-rule="evenodd"
>>>>>>>> xlink:href="#path-1"></use>
>>>>>>>> <rect stroke="#979797" stroke-width="1" x="0.5"
>>>>>>>> y="0.5"
>>>>>>>> width="149" height="39" rx="3"></rect>
>>>>>>>> </g>
>>>>>>>> <text id="TextField" font-family="HelveticaNeue,
>>>>>>>> Helvetica
>>>>>>>> Neue" font-size="12" font-weight="normal" fill="#646D7A">
>>>>>>>> <tspan x="57" y="25">Button</tspan>
>>>>>>>> </text>
>>>>>>>> </g>
>>>>>>>> </g>
>>>>>>>> </g>
>>>>>>>> </svg>
>>>>>>>>
>>>>>>>> (SVG could be a base, but it needs to be removed absolute values and
>>>>>>>> even
>>>>>>>> some static parts to be usable)
>>>>>>>>
>>>>>>>> I'd like to create a Button "playground" app with a button and some
>>>>>>>> controls that allow us to change how the button looks (colors,
>>>>> strokes,
>>>>>>>> round corners, font face, font weight,....)
>>>>>>>>
>>>>>>>> In the end this would be the starting point of a playground app for
>>>>> all
>>>>>>>> Royale controls
>>>>>>>>
>>>>>>>> Finaly this would be very useful if we can get the generated code for
>>>>>>>> that
>>>>>>>> particular styles and we could apply easily to any app, so change a
>>>>>>>> "theme"
>>>>>>>> will be quick and easy. Important: This will only work with our
>>> Royale
>>>>>>>> components (Express mainly, and maybe Basic?, but not MDL, CreateJS,
>>>>> or
>>>>>>>> others)
>>>>>>>>
>>>>>>>> I'm as well interested in how we could integrate that "view" in some
>>>>>>>> component in order to easy replace visuals for a concrete component.
>>>>> For
>>>>>>>> example, in the button above will be
>>>>>>>>
>>>>>>>> * we'll be making a skin part with SVG code, so we could pass values
>>>>> to
>>>>>>>> the
>>>>>>>> skin (for example colors, text button, width,...)
>>>>>>>> * if not using skins, how can we pass data from the component to the
>>>>> svg
>>>>>>>> part? (for example colors, text button, width,...)
>>>>>>>>
>>>>>>>> To progress with this effort, I think I could start doing only two
>>>>>>>> controls, and then as we have all considerations in place progress
>>>>>>>> through
>>>>>>>> the rest.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Carlos Rovira
>>>>>>>>
>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>> http%3A%2F%2Fabout.me%
>>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>> 8494%7Cfa7b1
>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>>> sdata=auPeQ0ub4B
>>>>>>>> Iq%2FTscLQWJ0Xxb9XdM2eegav2v1LXcuYY%3D&reserved=0
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Piotr Zarzycki
>>>>>>>
>>>>>>> mobile: +48 880 859 557
>>>>>>> skype: zarzycki10
>>>>>>>
>>>>>>> LinkedIn:
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>> http%3A%2F%2Fwww.linked
>>>>>>> in.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>> 8494%
>>>>>>> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636450710247213906&sdata=
>>>>>> xZ56
>>>>>>> se7Z6gcWKcC7PuWDPW0E6F9wQjEZkuYZO4zvwnY%3D&reserved=0
>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>> https%3A%2F%2Fpl.linke
>>>>>>> din.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%
>>>>>> 7C01%7C%7Cc23665e118fc4a7fe
>>>>>>> d4c08d5208c8494%7Cfa7b1b5a7b34438794aed2c178de
>>>>>> cee1%7C0%7C0%7C6364507102472
>>>>>>> 13906&sdata=1pwc5Fz1vKM2YCp6yUSe6x1Zdh9Au2
>>> xqb28Duy2Tqac%3D&reserved=0>
>>>>>>>
>>>>>>> GitHub:
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>> https%3A%2F%2Fgithub.co
>>>>>>> m%2Fpiotrzarzycki21&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>>> 8494%7Cf
>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=
>>>>>> Lr7JdnU
>>>>>>> fF%2F4xHJbXVZlZN%2Fw7t4Tz5R5KbZFwdVnZFww%3D&reserved=0
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Piotr Zarzycki
>>>>>
>>>>> mobile: +48 880 859 557
>>>>> skype: zarzycki10
>>>>>
>>>>> LinkedIn: http://www.linkedin.com/piotrzarzycki
>>>>> <https://pl.linkedin.com/in/piotr-zarzycki-92a53552>
>>>>>
>>>>> GitHub: https://github.com/piotrzarzycki21
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>> http://about.me/carlosrovira
>>>
>>>
>>
>>
>> --
>>
>> <http://www.codeoscopic.com>
>>
>> Carlos Rovira
>>
>> Director General
>>
>> M: +34 607 22 60 05
>>
>> http://www.codeoscopic.com
>>
>>
>> Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
>>
>>
>> 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: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
<js:ImageButton click="flipHorizontally()" src="assets/images/icons/0896-flip-horizontal2.svg"/>
<js:ImageButton click="flipVertically()" src="assets/images/icons/0897-flip-vertical2.svg"/>
> On Nov 1, 2017, at 2:45 PM, Carlos Rovira <ca...@codeoscopic.com> wrote:
>
> Hi Harbs,
>
> could you post some basic snippet for this to look at your approach?
>
> Thanks!
>
> 2017-11-01 13:42 GMT+01:00 Harbs <ha...@gmail.com>:
>
>> You can use SVG files instead of PNG files. I’m doing that extensively in
>> my app, but that will only work for components which have src or
>> background-image.
>>
>>> On Nov 1, 2017, at 2:14 PM, Carlos Rovira <ca...@apache.org>
>> wrote:
>>>
>>> Hi,
>>>
>>> I started a new project as Piotr suggested. After setup I only put one
>>> single button to start figuring how to do this.
>>>
>>> I'm starting for now with Basic, but as we discussed, don't know if this
>>> should go directly to express or not...it seems like something we could
>>> plug into Basic at any time as we can plug beads, and Express will come
>>> with some theme bundled. That seem the most natural for me right now
>>>
>>> Setting up a CSS-only theme seems pretty straight forward for me, and I
>>> could go with it for now.
>>>
>>> Regarding SVG, right now I don't see the way to add SVG in Royale. As
>> Alex
>>> suggested, I think we need to be able to add SVG in MXML.
>>> I was looking at this topic and seems very powerful since it can be
>>> integrated with CSS as well and in HTML
>>>
>>> For Example we have: https://css-tricks.com/using-svg/
>>>
>>> Maybe I could start with only CSS and see how far I can go, making
>>> wireframe and royale themes, as well trying with PNG images to
>> complement,
>>> but I suppose I'll get stuck soon, so maybe we should talk about SVG
>>> support as well and how hard it would be to make it happen in Royale. As
>>> well if you know other ways to integrate SVG right now please let me know
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>> 2017-10-31 21:31 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
>>>
>>>> I can say at this point that I really like idea with swappable view. In
>>>> most cases view is an ActionScript class where we may have more
>> possibility
>>>> to do things. When I was looking last time into the checkbox it for sure
>>>> need to more love, some part of the logic should be moved to the View.
>>>>
>>>> Piotr
>>>>
>>>> 2017-10-31 20:50 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>>>
>>>>> Ugh, Something has gone bad in the Basic components. Things like
>>>>> CheckBox and RadioButton should be creating simple <input
>> type="check"/>
>>>>> and <input type='radio' /> elements.
>>>>>
>>>>> The ability to style everything belongs in a different set of
>> components.
>>>>> Basic is supposed to generate the simplest tree of HTMLElements even if
>>>>> they can't be fully styles. That's so someone can do the equivalent of
>>>>> just using bare bones <input> elements.
>>>>>
>>>>> What is currently in Basic CheckBox and RadioButton might be right for
>>>>> creating fully styleable components, or some other composition of
>>>>> HTMLElements might be better. Carlos, I think that's up to you to
>>>> decide.
>>>>>
>>>>> An alternative approach is to have the JS implementations of CheckBox
>> and
>>>>> RadioButton have views and the views could create the HTMLElements.
>> That
>>>>> seems a bit heavy for the simple case of someone who just wants to use
>>>>> <input type="check" in an app, but that is a possibility.
>>>>>
>>>>> It sounds like you are looking for a way to manipulate SVG at runtime.
>>>> It
>>>>> is fine to have "static SVG" which is a block of SVG with that cannot
>> be
>>>>> modified and thus uses percentages and absolute values as best it can.
>>>>> Then we probably want to have a way to create "dynamic" skins with run
>>>>> code to generate or manipulate SVG. Those will be heavier, but that's
>>>>> PAYG. Should we try to allow SVG tags in MXML files? Then you could
>>>>> write code in an fx:Script block around your SVG tags and manipulate
>> the
>>>>> SVG?
>>>>>
>>>>> So IMO first, we should look into reverting Basic back to single simple
>>>>> HTMLElements where possible, then decide whether we want to have
>>>> swappable
>>>>> views or a new skinnable component set, then build out that component
>> set
>>>>> and see what code it takes to get it to look the way we want it. And
>>>> then
>>>>> we'll know what code is needed and can plan out how to encapsulate and
>>>>> re-use that code.
>>>>>
>>>>> My 2 cents,
>>>>> -Alex
>>>>>
>>>>> On 10/31/17, 11:23 AM, "Piotr Zarzycki" <pi...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> Hi Carlos,
>>>>>>
>>>>>> I think you should start looking into the Basic module and later make
>> an
>>>>>> upgrades to Express once you have all components visually created. I
>>>> would
>>>>>> not think on that stage about how we implement them rather look how
>> they
>>>>>> look like currently.
>>>>>>
>>>>>> 1) Create small app or run example with that component from our
>>>>>> repository.
>>>>>> 2) Make it visually with theme
>>>>>> 3) Show on the dev list - once we agree on all of them we can decide
>> how
>>>>>> to
>>>>>> apply those styles.
>>>>>>
>>>>>> My 2 cents. :) Piotr
>>>>>>
>>>>>>
>>>>>> 2017-10-31 19:12 GMT+01:00 Carlos Rovira <ca...@apache.org>:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm trying to find a valid workflow to start working in two initial
>>>>>>> faces
>>>>>>> for Royale components.
>>>>>>>
>>>>>>> I'm talking about to generate some kind of UI sheet with all controls
>>>>>>> and a
>>>>>>> basic wireframe style and another one that would be what more people
>>>>>>> will
>>>>>>> be using as default in Royale. From here, will be more easy to other
>>>>>>> guys
>>>>>>> to change styles. We could event create a Royale Theme editor in a
>>>> near
>>>>>>> future.
>>>>>>>
>>>>>>> So, to start working on this I need a design tool, and in this case,
>> I
>>>>>>> think that one is Sketch App.
>>>>>>>
>>>>>>> So I can create a design in Sketch with all controls (Button,
>>>> TextInput,
>>>>>>> CheckBox, Panel,...)
>>>>>>>
>>>>>>> From here, I can generate CSS and SVG code
>>>>>>>
>>>>>>> For example the code of this simple button
>>>>>>> (https://na01.safelinks.protection.outlook.com/?url=
>>>>> https%3A%2F%2Fsnag.gy
>>>>>>> %2FAm2fRX.jpg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>> 8494%7Cfa7b1b
>>>>>>> 5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>> sdata=Z4b6dMq%2Br
>>>>>>> UmSSxpGYNjgKl0nkRkIlV%2FbQIDLVUIvo6E%3D&reserved=0)
>>>>>>> that
>>>>>>> I did quickly is:
>>>>>>>
>>>>>>> CSS
>>>>>>>
>>>>>>> /* Background: */
>>>>>>> background: #D8D8D8;
>>>>>>> border: 1px solid #979797;
>>>>>>> border-radius: 3px;
>>>>>>>
>>>>>>> /* TextField: */
>>>>>>> font-family: HelveticaNeue;
>>>>>>> font-size: 12px;
>>>>>>> color: #646D7A;
>>>>>>>
>>>>>>> (CSS is almost all usable)
>>>>>>>
>>>>>>> And SVG
>>>>>>>
>>>>>>> <svg width="150px" height="40px" viewBox="0 0 150 40" version="1.1"
>>>>>>> xmlns="
>>>>>>>
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>> http%3A%2F%2Fwww.w3.or
>>>>>>> g%2F2000%2Fsvg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>> 8494%7Cfa7b1
>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>> sdata=cWLJ2jj9Ih
>>>>>>> cGnjAB8GEtEIdc3ZZO2OSAsgzPNEVrUzE%3D&reserved=0"
>>>>>>> xmlns:xlink="https://na01.safelinks.protection.outlook.
>>>>> com/?url=http%3A%2
>>>>>>> F%2Fwww.w3.org%2F1999%2Fxlink&data=02%7C01%7C%
>>>>> 7Cc23665e118fc4a7fed4c08d52
>>>>>>> 08c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>> 7C636450710247213906&s
>>>>>>> data=sgNtytSumzad%2BraDA6NoITbm6XqJJx6yHQudjzhpm6Y%3D&reserved=0">
>>>>>>> <!-- Generator: Sketch 47.1 (45422) -
>>>>>>>
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>> http%3A%2F%2Fwww.bohem
>>>>>>> iancoding.com%2Fsketch&data=02%7C01%7C%
>> 7Cc23665e118fc4a7fed4c08d5208c
>>>>> 8494
>>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>> 7C636450710247213906&sdata=dE
>>>>>>> oGVBONBD6Z1XMTjYcpEc7gq5UqtS8BziB0I3f9qSs%3D&reserved=0 -->
>>>>>>> <desc>Created with Sketch.</desc>
>>>>>>> <defs>
>>>>>>> <rect id="path-1" x="0" y="0" width="150" height="40"
>>>>>>> rx="3"></rect>
>>>>>>> </defs>
>>>>>>> <g id="Page-1" stroke="none" stroke-width="1" fill="none"
>>>>>>> fill-rule="evenodd">
>>>>>>> <g id="Royale" transform="translate(-58.000000, -49.000000)">
>>>>>>> <g id="Button" transform="translate(58.000000,
>>>> 49.000000)">
>>>>>>> <g id="Background">
>>>>>>> <use fill="#D8D8D8" fill-rule="evenodd"
>>>>>>> xlink:href="#path-1"></use>
>>>>>>> <rect stroke="#979797" stroke-width="1" x="0.5"
>>>>>>> y="0.5"
>>>>>>> width="149" height="39" rx="3"></rect>
>>>>>>> </g>
>>>>>>> <text id="TextField" font-family="HelveticaNeue,
>>>>>>> Helvetica
>>>>>>> Neue" font-size="12" font-weight="normal" fill="#646D7A">
>>>>>>> <tspan x="57" y="25">Button</tspan>
>>>>>>> </text>
>>>>>>> </g>
>>>>>>> </g>
>>>>>>> </g>
>>>>>>> </svg>
>>>>>>>
>>>>>>> (SVG could be a base, but it needs to be removed absolute values and
>>>>>>> even
>>>>>>> some static parts to be usable)
>>>>>>>
>>>>>>> I'd like to create a Button "playground" app with a button and some
>>>>>>> controls that allow us to change how the button looks (colors,
>>>> strokes,
>>>>>>> round corners, font face, font weight,....)
>>>>>>>
>>>>>>> In the end this would be the starting point of a playground app for
>>>> all
>>>>>>> Royale controls
>>>>>>>
>>>>>>> Finaly this would be very useful if we can get the generated code for
>>>>>>> that
>>>>>>> particular styles and we could apply easily to any app, so change a
>>>>>>> "theme"
>>>>>>> will be quick and easy. Important: This will only work with our
>> Royale
>>>>>>> components (Express mainly, and maybe Basic?, but not MDL, CreateJS,
>>>> or
>>>>>>> others)
>>>>>>>
>>>>>>> I'm as well interested in how we could integrate that "view" in some
>>>>>>> component in order to easy replace visuals for a concrete component.
>>>> For
>>>>>>> example, in the button above will be
>>>>>>>
>>>>>>> * we'll be making a skin part with SVG code, so we could pass values
>>>> to
>>>>>>> the
>>>>>>> skin (for example colors, text button, width,...)
>>>>>>> * if not using skins, how can we pass data from the component to the
>>>> svg
>>>>>>> part? (for example colors, text button, width,...)
>>>>>>>
>>>>>>> To progress with this effort, I think I could start doing only two
>>>>>>> controls, and then as we have all considerations in place progress
>>>>>>> through
>>>>>>> the rest.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> --
>>>>>>> Carlos Rovira
>>>>>>>
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>> http%3A%2F%2Fabout.me%
>>>>>>> 2Fcarlosrovira&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>> 8494%7Cfa7b1
>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>>>> sdata=auPeQ0ub4B
>>>>>>> Iq%2FTscLQWJ0Xxb9XdM2eegav2v1LXcuYY%3D&reserved=0
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Piotr Zarzycki
>>>>>>
>>>>>> mobile: +48 880 859 557
>>>>>> skype: zarzycki10
>>>>>>
>>>>>> LinkedIn:
>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>> http%3A%2F%2Fwww.linked
>>>>>> in.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>> 8494%
>>>>>> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636450710247213906&sdata=
>>>>> xZ56
>>>>>> se7Z6gcWKcC7PuWDPW0E6F9wQjEZkuYZO4zvwnY%3D&reserved=0
>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>> https%3A%2F%2Fpl.linke
>>>>>> din.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%
>>>>> 7C01%7C%7Cc23665e118fc4a7fe
>>>>>> d4c08d5208c8494%7Cfa7b1b5a7b34438794aed2c178de
>>>>> cee1%7C0%7C0%7C6364507102472
>>>>>> 13906&sdata=1pwc5Fz1vKM2YCp6yUSe6x1Zdh9Au2
>> xqb28Duy2Tqac%3D&reserved=0>
>>>>>>
>>>>>> GitHub:
>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>> https%3A%2F%2Fgithub.co
>>>>>> m%2Fpiotrzarzycki21&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>>>> 8494%7Cf
>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=
>>>>> Lr7JdnU
>>>>>> fF%2F4xHJbXVZlZN%2Fw7t4Tz5R5KbZFwdVnZFww%3D&reserved=0
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Piotr Zarzycki
>>>>
>>>> mobile: +48 880 859 557
>>>> skype: zarzycki10
>>>>
>>>> LinkedIn: http://www.linkedin.com/piotrzarzycki
>>>> <https://pl.linkedin.com/in/piotr-zarzycki-92a53552>
>>>>
>>>> GitHub: https://github.com/piotrzarzycki21
>>>>
>>>
>>>
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>
>>
>
>
> --
>
> <http://www.codeoscopic.com>
>
> Carlos Rovira
>
> Director General
>
> M: +34 607 22 60 05
>
> http://www.codeoscopic.com
>
>
> Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
>
>
> 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: Working on UI Controls styling
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Harbs,
could you post some basic snippet for this to look at your approach?
Thanks!
2017-11-01 13:42 GMT+01:00 Harbs <ha...@gmail.com>:
> You can use SVG files instead of PNG files. I’m doing that extensively in
> my app, but that will only work for components which have src or
> background-image.
>
> > On Nov 1, 2017, at 2:14 PM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Hi,
> >
> > I started a new project as Piotr suggested. After setup I only put one
> > single button to start figuring how to do this.
> >
> > I'm starting for now with Basic, but as we discussed, don't know if this
> > should go directly to express or not...it seems like something we could
> > plug into Basic at any time as we can plug beads, and Express will come
> > with some theme bundled. That seem the most natural for me right now
> >
> > Setting up a CSS-only theme seems pretty straight forward for me, and I
> > could go with it for now.
> >
> > Regarding SVG, right now I don't see the way to add SVG in Royale. As
> Alex
> > suggested, I think we need to be able to add SVG in MXML.
> > I was looking at this topic and seems very powerful since it can be
> > integrated with CSS as well and in HTML
> >
> > For Example we have: https://css-tricks.com/using-svg/
> >
> > Maybe I could start with only CSS and see how far I can go, making
> > wireframe and royale themes, as well trying with PNG images to
> complement,
> > but I suppose I'll get stuck soon, so maybe we should talk about SVG
> > support as well and how hard it would be to make it happen in Royale. As
> > well if you know other ways to integrate SVG right now please let me know
> >
> > Thanks
> >
> >
> >
> >
> > 2017-10-31 21:31 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
> >
> >> I can say at this point that I really like idea with swappable view. In
> >> most cases view is an ActionScript class where we may have more
> possibility
> >> to do things. When I was looking last time into the checkbox it for sure
> >> need to more love, some part of the logic should be moved to the View.
> >>
> >> Piotr
> >>
> >> 2017-10-31 20:50 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >>
> >>> Ugh, Something has gone bad in the Basic components. Things like
> >>> CheckBox and RadioButton should be creating simple <input
> type="check"/>
> >>> and <input type='radio' /> elements.
> >>>
> >>> The ability to style everything belongs in a different set of
> components.
> >>> Basic is supposed to generate the simplest tree of HTMLElements even if
> >>> they can't be fully styles. That's so someone can do the equivalent of
> >>> just using bare bones <input> elements.
> >>>
> >>> What is currently in Basic CheckBox and RadioButton might be right for
> >>> creating fully styleable components, or some other composition of
> >>> HTMLElements might be better. Carlos, I think that's up to you to
> >> decide.
> >>>
> >>> An alternative approach is to have the JS implementations of CheckBox
> and
> >>> RadioButton have views and the views could create the HTMLElements.
> That
> >>> seems a bit heavy for the simple case of someone who just wants to use
> >>> <input type="check" in an app, but that is a possibility.
> >>>
> >>> It sounds like you are looking for a way to manipulate SVG at runtime.
> >> It
> >>> is fine to have "static SVG" which is a block of SVG with that cannot
> be
> >>> modified and thus uses percentages and absolute values as best it can.
> >>> Then we probably want to have a way to create "dynamic" skins with run
> >>> code to generate or manipulate SVG. Those will be heavier, but that's
> >>> PAYG. Should we try to allow SVG tags in MXML files? Then you could
> >>> write code in an fx:Script block around your SVG tags and manipulate
> the
> >>> SVG?
> >>>
> >>> So IMO first, we should look into reverting Basic back to single simple
> >>> HTMLElements where possible, then decide whether we want to have
> >> swappable
> >>> views or a new skinnable component set, then build out that component
> set
> >>> and see what code it takes to get it to look the way we want it. And
> >> then
> >>> we'll know what code is needed and can plan out how to encapsulate and
> >>> re-use that code.
> >>>
> >>> My 2 cents,
> >>> -Alex
> >>>
> >>> On 10/31/17, 11:23 AM, "Piotr Zarzycki" <pi...@gmail.com>
> >> wrote:
> >>>
> >>>> Hi Carlos,
> >>>>
> >>>> I think you should start looking into the Basic module and later make
> an
> >>>> upgrades to Express once you have all components visually created. I
> >> would
> >>>> not think on that stage about how we implement them rather look how
> they
> >>>> look like currently.
> >>>>
> >>>> 1) Create small app or run example with that component from our
> >>>> repository.
> >>>> 2) Make it visually with theme
> >>>> 3) Show on the dev list - once we agree on all of them we can decide
> how
> >>>> to
> >>>> apply those styles.
> >>>>
> >>>> My 2 cents. :) Piotr
> >>>>
> >>>>
> >>>> 2017-10-31 19:12 GMT+01:00 Carlos Rovira <ca...@apache.org>:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I'm trying to find a valid workflow to start working in two initial
> >>>>> faces
> >>>>> for Royale components.
> >>>>>
> >>>>> I'm talking about to generate some kind of UI sheet with all controls
> >>>>> and a
> >>>>> basic wireframe style and another one that would be what more people
> >>>>> will
> >>>>> be using as default in Royale. From here, will be more easy to other
> >>>>> guys
> >>>>> to change styles. We could event create a Royale Theme editor in a
> >> near
> >>>>> future.
> >>>>>
> >>>>> So, to start working on this I need a design tool, and in this case,
> I
> >>>>> think that one is Sketch App.
> >>>>>
> >>>>> So I can create a design in Sketch with all controls (Button,
> >> TextInput,
> >>>>> CheckBox, Panel,...)
> >>>>>
> >>>>> From here, I can generate CSS and SVG code
> >>>>>
> >>>>> For example the code of this simple button
> >>>>> (https://na01.safelinks.protection.outlook.com/?url=
> >>> https%3A%2F%2Fsnag.gy
> >>>>> %2FAm2fRX.jpg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> >>> 8494%7Cfa7b1b
> >>>>> 5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
> >>> sdata=Z4b6dMq%2Br
> >>>>> UmSSxpGYNjgKl0nkRkIlV%2FbQIDLVUIvo6E%3D&reserved=0)
> >>>>> that
> >>>>> I did quickly is:
> >>>>>
> >>>>> CSS
> >>>>>
> >>>>> /* Background: */
> >>>>> background: #D8D8D8;
> >>>>> border: 1px solid #979797;
> >>>>> border-radius: 3px;
> >>>>>
> >>>>> /* TextField: */
> >>>>> font-family: HelveticaNeue;
> >>>>> font-size: 12px;
> >>>>> color: #646D7A;
> >>>>>
> >>>>> (CSS is almost all usable)
> >>>>>
> >>>>> And SVG
> >>>>>
> >>>>> <svg width="150px" height="40px" viewBox="0 0 150 40" version="1.1"
> >>>>> xmlns="
> >>>>>
> >>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>> http%3A%2F%2Fwww.w3.or
> >>>>> g%2F2000%2Fsvg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> >>> 8494%7Cfa7b1
> >>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
> >>> sdata=cWLJ2jj9Ih
> >>>>> cGnjAB8GEtEIdc3ZZO2OSAsgzPNEVrUzE%3D&reserved=0"
> >>>>> xmlns:xlink="https://na01.safelinks.protection.outlook.
> >>> com/?url=http%3A%2
> >>>>> F%2Fwww.w3.org%2F1999%2Fxlink&data=02%7C01%7C%
> >>> 7Cc23665e118fc4a7fed4c08d52
> >>>>> 08c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>> 7C636450710247213906&s
> >>>>> data=sgNtytSumzad%2BraDA6NoITbm6XqJJx6yHQudjzhpm6Y%3D&reserved=0">
> >>>>> <!-- Generator: Sketch 47.1 (45422) -
> >>>>>
> >>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>> http%3A%2F%2Fwww.bohem
> >>>>> iancoding.com%2Fsketch&data=02%7C01%7C%
> 7Cc23665e118fc4a7fed4c08d5208c
> >>> 8494
> >>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>> 7C636450710247213906&sdata=dE
> >>>>> oGVBONBD6Z1XMTjYcpEc7gq5UqtS8BziB0I3f9qSs%3D&reserved=0 -->
> >>>>> <desc>Created with Sketch.</desc>
> >>>>> <defs>
> >>>>> <rect id="path-1" x="0" y="0" width="150" height="40"
> >>>>> rx="3"></rect>
> >>>>> </defs>
> >>>>> <g id="Page-1" stroke="none" stroke-width="1" fill="none"
> >>>>> fill-rule="evenodd">
> >>>>> <g id="Royale" transform="translate(-58.000000, -49.000000)">
> >>>>> <g id="Button" transform="translate(58.000000,
> >> 49.000000)">
> >>>>> <g id="Background">
> >>>>> <use fill="#D8D8D8" fill-rule="evenodd"
> >>>>> xlink:href="#path-1"></use>
> >>>>> <rect stroke="#979797" stroke-width="1" x="0.5"
> >>>>> y="0.5"
> >>>>> width="149" height="39" rx="3"></rect>
> >>>>> </g>
> >>>>> <text id="TextField" font-family="HelveticaNeue,
> >>>>> Helvetica
> >>>>> Neue" font-size="12" font-weight="normal" fill="#646D7A">
> >>>>> <tspan x="57" y="25">Button</tspan>
> >>>>> </text>
> >>>>> </g>
> >>>>> </g>
> >>>>> </g>
> >>>>> </svg>
> >>>>>
> >>>>> (SVG could be a base, but it needs to be removed absolute values and
> >>>>> even
> >>>>> some static parts to be usable)
> >>>>>
> >>>>> I'd like to create a Button "playground" app with a button and some
> >>>>> controls that allow us to change how the button looks (colors,
> >> strokes,
> >>>>> round corners, font face, font weight,....)
> >>>>>
> >>>>> In the end this would be the starting point of a playground app for
> >> all
> >>>>> Royale controls
> >>>>>
> >>>>> Finaly this would be very useful if we can get the generated code for
> >>>>> that
> >>>>> particular styles and we could apply easily to any app, so change a
> >>>>> "theme"
> >>>>> will be quick and easy. Important: This will only work with our
> Royale
> >>>>> components (Express mainly, and maybe Basic?, but not MDL, CreateJS,
> >> or
> >>>>> others)
> >>>>>
> >>>>> I'm as well interested in how we could integrate that "view" in some
> >>>>> component in order to easy replace visuals for a concrete component.
> >> For
> >>>>> example, in the button above will be
> >>>>>
> >>>>> * we'll be making a skin part with SVG code, so we could pass values
> >> to
> >>>>> the
> >>>>> skin (for example colors, text button, width,...)
> >>>>> * if not using skins, how can we pass data from the component to the
> >> svg
> >>>>> part? (for example colors, text button, width,...)
> >>>>>
> >>>>> To progress with this effort, I think I could start doing only two
> >>>>> controls, and then as we have all considerations in place progress
> >>>>> through
> >>>>> the rest.
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> --
> >>>>> Carlos Rovira
> >>>>>
> >>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>> http%3A%2F%2Fabout.me%
> >>>>> 2Fcarlosrovira&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> >>> 8494%7Cfa7b1
> >>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
> >>> sdata=auPeQ0ub4B
> >>>>> Iq%2FTscLQWJ0Xxb9XdM2eegav2v1LXcuYY%3D&reserved=0
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Piotr Zarzycki
> >>>>
> >>>> mobile: +48 880 859 557
> >>>> skype: zarzycki10
> >>>>
> >>>> LinkedIn:
> >>>> https://na01.safelinks.protection.outlook.com/?url=
> >>> http%3A%2F%2Fwww.linked
> >>>> in.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> >>> 8494%
> >>>> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636450710247213906&sdata=
> >>> xZ56
> >>>> se7Z6gcWKcC7PuWDPW0E6F9wQjEZkuYZO4zvwnY%3D&reserved=0
> >>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>> https%3A%2F%2Fpl.linke
> >>>> din.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%
> >>> 7C01%7C%7Cc23665e118fc4a7fe
> >>>> d4c08d5208c8494%7Cfa7b1b5a7b34438794aed2c178de
> >>> cee1%7C0%7C0%7C6364507102472
> >>>> 13906&sdata=1pwc5Fz1vKM2YCp6yUSe6x1Zdh9Au2
> xqb28Duy2Tqac%3D&reserved=0>
> >>>>
> >>>> GitHub:
> >>>> https://na01.safelinks.protection.outlook.com/?url=
> >>> https%3A%2F%2Fgithub.co
> >>>> m%2Fpiotrzarzycki21&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> >>> 8494%7Cf
> >>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=
> >>> Lr7JdnU
> >>>> fF%2F4xHJbXVZlZN%2Fw7t4Tz5R5KbZFwdVnZFww%3D&reserved=0
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> mobile: +48 880 859 557
> >> skype: zarzycki10
> >>
> >> LinkedIn: http://www.linkedin.com/piotrzarzycki
> >> <https://pl.linkedin.com/in/piotr-zarzycki-92a53552>
> >>
> >> GitHub: https://github.com/piotrzarzycki21
> >>
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>
--
<http://www.codeoscopic.com>
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
Conocenos Avant2 en 1 minuto! <https://avant2.es/#video>
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: Working on UI Controls styling
Posted by Harbs <ha...@gmail.com>.
You can use SVG files instead of PNG files. I’m doing that extensively in my app, but that will only work for components which have src or background-image.
> On Nov 1, 2017, at 2:14 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi,
>
> I started a new project as Piotr suggested. After setup I only put one
> single button to start figuring how to do this.
>
> I'm starting for now with Basic, but as we discussed, don't know if this
> should go directly to express or not...it seems like something we could
> plug into Basic at any time as we can plug beads, and Express will come
> with some theme bundled. That seem the most natural for me right now
>
> Setting up a CSS-only theme seems pretty straight forward for me, and I
> could go with it for now.
>
> Regarding SVG, right now I don't see the way to add SVG in Royale. As Alex
> suggested, I think we need to be able to add SVG in MXML.
> I was looking at this topic and seems very powerful since it can be
> integrated with CSS as well and in HTML
>
> For Example we have: https://css-tricks.com/using-svg/
>
> Maybe I could start with only CSS and see how far I can go, making
> wireframe and royale themes, as well trying with PNG images to complement,
> but I suppose I'll get stuck soon, so maybe we should talk about SVG
> support as well and how hard it would be to make it happen in Royale. As
> well if you know other ways to integrate SVG right now please let me know
>
> Thanks
>
>
>
>
> 2017-10-31 21:31 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
>
>> I can say at this point that I really like idea with swappable view. In
>> most cases view is an ActionScript class where we may have more possibility
>> to do things. When I was looking last time into the checkbox it for sure
>> need to more love, some part of the logic should be moved to the View.
>>
>> Piotr
>>
>> 2017-10-31 20:50 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>>
>>> Ugh, Something has gone bad in the Basic components. Things like
>>> CheckBox and RadioButton should be creating simple <input type="check"/>
>>> and <input type='radio' /> elements.
>>>
>>> The ability to style everything belongs in a different set of components.
>>> Basic is supposed to generate the simplest tree of HTMLElements even if
>>> they can't be fully styles. That's so someone can do the equivalent of
>>> just using bare bones <input> elements.
>>>
>>> What is currently in Basic CheckBox and RadioButton might be right for
>>> creating fully styleable components, or some other composition of
>>> HTMLElements might be better. Carlos, I think that's up to you to
>> decide.
>>>
>>> An alternative approach is to have the JS implementations of CheckBox and
>>> RadioButton have views and the views could create the HTMLElements. That
>>> seems a bit heavy for the simple case of someone who just wants to use
>>> <input type="check" in an app, but that is a possibility.
>>>
>>> It sounds like you are looking for a way to manipulate SVG at runtime.
>> It
>>> is fine to have "static SVG" which is a block of SVG with that cannot be
>>> modified and thus uses percentages and absolute values as best it can.
>>> Then we probably want to have a way to create "dynamic" skins with run
>>> code to generate or manipulate SVG. Those will be heavier, but that's
>>> PAYG. Should we try to allow SVG tags in MXML files? Then you could
>>> write code in an fx:Script block around your SVG tags and manipulate the
>>> SVG?
>>>
>>> So IMO first, we should look into reverting Basic back to single simple
>>> HTMLElements where possible, then decide whether we want to have
>> swappable
>>> views or a new skinnable component set, then build out that component set
>>> and see what code it takes to get it to look the way we want it. And
>> then
>>> we'll know what code is needed and can plan out how to encapsulate and
>>> re-use that code.
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 10/31/17, 11:23 AM, "Piotr Zarzycki" <pi...@gmail.com>
>> wrote:
>>>
>>>> Hi Carlos,
>>>>
>>>> I think you should start looking into the Basic module and later make an
>>>> upgrades to Express once you have all components visually created. I
>> would
>>>> not think on that stage about how we implement them rather look how they
>>>> look like currently.
>>>>
>>>> 1) Create small app or run example with that component from our
>>>> repository.
>>>> 2) Make it visually with theme
>>>> 3) Show on the dev list - once we agree on all of them we can decide how
>>>> to
>>>> apply those styles.
>>>>
>>>> My 2 cents. :) Piotr
>>>>
>>>>
>>>> 2017-10-31 19:12 GMT+01:00 Carlos Rovira <ca...@apache.org>:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm trying to find a valid workflow to start working in two initial
>>>>> faces
>>>>> for Royale components.
>>>>>
>>>>> I'm talking about to generate some kind of UI sheet with all controls
>>>>> and a
>>>>> basic wireframe style and another one that would be what more people
>>>>> will
>>>>> be using as default in Royale. From here, will be more easy to other
>>>>> guys
>>>>> to change styles. We could event create a Royale Theme editor in a
>> near
>>>>> future.
>>>>>
>>>>> So, to start working on this I need a design tool, and in this case, I
>>>>> think that one is Sketch App.
>>>>>
>>>>> So I can create a design in Sketch with all controls (Button,
>> TextInput,
>>>>> CheckBox, Panel,...)
>>>>>
>>>>> From here, I can generate CSS and SVG code
>>>>>
>>>>> For example the code of this simple button
>>>>> (https://na01.safelinks.protection.outlook.com/?url=
>>> https%3A%2F%2Fsnag.gy
>>>>> %2FAm2fRX.jpg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>> 8494%7Cfa7b1b
>>>>> 5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>> sdata=Z4b6dMq%2Br
>>>>> UmSSxpGYNjgKl0nkRkIlV%2FbQIDLVUIvo6E%3D&reserved=0)
>>>>> that
>>>>> I did quickly is:
>>>>>
>>>>> CSS
>>>>>
>>>>> /* Background: */
>>>>> background: #D8D8D8;
>>>>> border: 1px solid #979797;
>>>>> border-radius: 3px;
>>>>>
>>>>> /* TextField: */
>>>>> font-family: HelveticaNeue;
>>>>> font-size: 12px;
>>>>> color: #646D7A;
>>>>>
>>>>> (CSS is almost all usable)
>>>>>
>>>>> And SVG
>>>>>
>>>>> <svg width="150px" height="40px" viewBox="0 0 150 40" version="1.1"
>>>>> xmlns="
>>>>>
>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>> http%3A%2F%2Fwww.w3.or
>>>>> g%2F2000%2Fsvg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>> 8494%7Cfa7b1
>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>> sdata=cWLJ2jj9Ih
>>>>> cGnjAB8GEtEIdc3ZZO2OSAsgzPNEVrUzE%3D&reserved=0"
>>>>> xmlns:xlink="https://na01.safelinks.protection.outlook.
>>> com/?url=http%3A%2
>>>>> F%2Fwww.w3.org%2F1999%2Fxlink&data=02%7C01%7C%
>>> 7Cc23665e118fc4a7fed4c08d52
>>>>> 08c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636450710247213906&s
>>>>> data=sgNtytSumzad%2BraDA6NoITbm6XqJJx6yHQudjzhpm6Y%3D&reserved=0">
>>>>> <!-- Generator: Sketch 47.1 (45422) -
>>>>>
>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>> http%3A%2F%2Fwww.bohem
>>>>> iancoding.com%2Fsketch&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>> 8494
>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>> 7C636450710247213906&sdata=dE
>>>>> oGVBONBD6Z1XMTjYcpEc7gq5UqtS8BziB0I3f9qSs%3D&reserved=0 -->
>>>>> <desc>Created with Sketch.</desc>
>>>>> <defs>
>>>>> <rect id="path-1" x="0" y="0" width="150" height="40"
>>>>> rx="3"></rect>
>>>>> </defs>
>>>>> <g id="Page-1" stroke="none" stroke-width="1" fill="none"
>>>>> fill-rule="evenodd">
>>>>> <g id="Royale" transform="translate(-58.000000, -49.000000)">
>>>>> <g id="Button" transform="translate(58.000000,
>> 49.000000)">
>>>>> <g id="Background">
>>>>> <use fill="#D8D8D8" fill-rule="evenodd"
>>>>> xlink:href="#path-1"></use>
>>>>> <rect stroke="#979797" stroke-width="1" x="0.5"
>>>>> y="0.5"
>>>>> width="149" height="39" rx="3"></rect>
>>>>> </g>
>>>>> <text id="TextField" font-family="HelveticaNeue,
>>>>> Helvetica
>>>>> Neue" font-size="12" font-weight="normal" fill="#646D7A">
>>>>> <tspan x="57" y="25">Button</tspan>
>>>>> </text>
>>>>> </g>
>>>>> </g>
>>>>> </g>
>>>>> </svg>
>>>>>
>>>>> (SVG could be a base, but it needs to be removed absolute values and
>>>>> even
>>>>> some static parts to be usable)
>>>>>
>>>>> I'd like to create a Button "playground" app with a button and some
>>>>> controls that allow us to change how the button looks (colors,
>> strokes,
>>>>> round corners, font face, font weight,....)
>>>>>
>>>>> In the end this would be the starting point of a playground app for
>> all
>>>>> Royale controls
>>>>>
>>>>> Finaly this would be very useful if we can get the generated code for
>>>>> that
>>>>> particular styles and we could apply easily to any app, so change a
>>>>> "theme"
>>>>> will be quick and easy. Important: This will only work with our Royale
>>>>> components (Express mainly, and maybe Basic?, but not MDL, CreateJS,
>> or
>>>>> others)
>>>>>
>>>>> I'm as well interested in how we could integrate that "view" in some
>>>>> component in order to easy replace visuals for a concrete component.
>> For
>>>>> example, in the button above will be
>>>>>
>>>>> * we'll be making a skin part with SVG code, so we could pass values
>> to
>>>>> the
>>>>> skin (for example colors, text button, width,...)
>>>>> * if not using skins, how can we pass data from the component to the
>> svg
>>>>> part? (for example colors, text button, width,...)
>>>>>
>>>>> To progress with this effort, I think I could start doing only two
>>>>> controls, and then as we have all considerations in place progress
>>>>> through
>>>>> the rest.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>>
>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>> http%3A%2F%2Fabout.me%
>>>>> 2Fcarlosrovira&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>> 8494%7Cfa7b1
>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
>>> sdata=auPeQ0ub4B
>>>>> Iq%2FTscLQWJ0Xxb9XdM2eegav2v1LXcuYY%3D&reserved=0
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Piotr Zarzycki
>>>>
>>>> mobile: +48 880 859 557
>>>> skype: zarzycki10
>>>>
>>>> LinkedIn:
>>>> https://na01.safelinks.protection.outlook.com/?url=
>>> http%3A%2F%2Fwww.linked
>>>> in.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>> 8494%
>>>> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=
>>> xZ56
>>>> se7Z6gcWKcC7PuWDPW0E6F9wQjEZkuYZO4zvwnY%3D&reserved=0
>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>> https%3A%2F%2Fpl.linke
>>>> din.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%
>>> 7C01%7C%7Cc23665e118fc4a7fe
>>>> d4c08d5208c8494%7Cfa7b1b5a7b34438794aed2c178de
>>> cee1%7C0%7C0%7C6364507102472
>>>> 13906&sdata=1pwc5Fz1vKM2YCp6yUSe6x1Zdh9Au2xqb28Duy2Tqac%3D&reserved=0>
>>>>
>>>> GitHub:
>>>> https://na01.safelinks.protection.outlook.com/?url=
>>> https%3A%2F%2Fgithub.co
>>>> m%2Fpiotrzarzycki21&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
>>> 8494%7Cf
>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=
>>> Lr7JdnU
>>>> fF%2F4xHJbXVZlZN%2Fw7t4Tz5R5KbZFwdVnZFww%3D&reserved=0
>>>
>>>
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>> mobile: +48 880 859 557
>> skype: zarzycki10
>>
>> LinkedIn: http://www.linkedin.com/piotrzarzycki
>> <https://pl.linkedin.com/in/piotr-zarzycki-92a53552>
>>
>> GitHub: https://github.com/piotrzarzycki21
>>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: Working on UI Controls styling
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
I started a new project as Piotr suggested. After setup I only put one
single button to start figuring how to do this.
I'm starting for now with Basic, but as we discussed, don't know if this
should go directly to express or not...it seems like something we could
plug into Basic at any time as we can plug beads, and Express will come
with some theme bundled. That seem the most natural for me right now
Setting up a CSS-only theme seems pretty straight forward for me, and I
could go with it for now.
Regarding SVG, right now I don't see the way to add SVG in Royale. As Alex
suggested, I think we need to be able to add SVG in MXML.
I was looking at this topic and seems very powerful since it can be
integrated with CSS as well and in HTML
For Example we have: https://css-tricks.com/using-svg/
Maybe I could start with only CSS and see how far I can go, making
wireframe and royale themes, as well trying with PNG images to complement,
but I suppose I'll get stuck soon, so maybe we should talk about SVG
support as well and how hard it would be to make it happen in Royale. As
well if you know other ways to integrate SVG right now please let me know
Thanks
2017-10-31 21:31 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
> I can say at this point that I really like idea with swappable view. In
> most cases view is an ActionScript class where we may have more possibility
> to do things. When I was looking last time into the checkbox it for sure
> need to more love, some part of the logic should be moved to the View.
>
> Piotr
>
> 2017-10-31 20:50 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
> > Ugh, Something has gone bad in the Basic components. Things like
> > CheckBox and RadioButton should be creating simple <input type="check"/>
> > and <input type='radio' /> elements.
> >
> > The ability to style everything belongs in a different set of components.
> > Basic is supposed to generate the simplest tree of HTMLElements even if
> > they can't be fully styles. That's so someone can do the equivalent of
> > just using bare bones <input> elements.
> >
> > What is currently in Basic CheckBox and RadioButton might be right for
> > creating fully styleable components, or some other composition of
> > HTMLElements might be better. Carlos, I think that's up to you to
> decide.
> >
> > An alternative approach is to have the JS implementations of CheckBox and
> > RadioButton have views and the views could create the HTMLElements. That
> > seems a bit heavy for the simple case of someone who just wants to use
> > <input type="check" in an app, but that is a possibility.
> >
> > It sounds like you are looking for a way to manipulate SVG at runtime.
> It
> > is fine to have "static SVG" which is a block of SVG with that cannot be
> > modified and thus uses percentages and absolute values as best it can.
> > Then we probably want to have a way to create "dynamic" skins with run
> > code to generate or manipulate SVG. Those will be heavier, but that's
> > PAYG. Should we try to allow SVG tags in MXML files? Then you could
> > write code in an fx:Script block around your SVG tags and manipulate the
> > SVG?
> >
> > So IMO first, we should look into reverting Basic back to single simple
> > HTMLElements where possible, then decide whether we want to have
> swappable
> > views or a new skinnable component set, then build out that component set
> > and see what code it takes to get it to look the way we want it. And
> then
> > we'll know what code is needed and can plan out how to encapsulate and
> > re-use that code.
> >
> > My 2 cents,
> > -Alex
> >
> > On 10/31/17, 11:23 AM, "Piotr Zarzycki" <pi...@gmail.com>
> wrote:
> >
> > >Hi Carlos,
> > >
> > >I think you should start looking into the Basic module and later make an
> > >upgrades to Express once you have all components visually created. I
> would
> > >not think on that stage about how we implement them rather look how they
> > >look like currently.
> > >
> > >1) Create small app or run example with that component from our
> > >repository.
> > >2) Make it visually with theme
> > >3) Show on the dev list - once we agree on all of them we can decide how
> > >to
> > >apply those styles.
> > >
> > >My 2 cents. :) Piotr
> > >
> > >
> > >2017-10-31 19:12 GMT+01:00 Carlos Rovira <ca...@apache.org>:
> > >
> > >> Hi,
> > >>
> > >> I'm trying to find a valid workflow to start working in two initial
> > >>faces
> > >> for Royale components.
> > >>
> > >> I'm talking about to generate some kind of UI sheet with all controls
> > >>and a
> > >> basic wireframe style and another one that would be what more people
> > >>will
> > >> be using as default in Royale. From here, will be more easy to other
> > >>guys
> > >> to change styles. We could event create a Royale Theme editor in a
> near
> > >> future.
> > >>
> > >> So, to start working on this I need a design tool, and in this case, I
> > >> think that one is Sketch App.
> > >>
> > >> So I can create a design in Sketch with all controls (Button,
> TextInput,
> > >> CheckBox, Panel,...)
> > >>
> > >> From here, I can generate CSS and SVG code
> > >>
> > >> For example the code of this simple button
> > >>(https://na01.safelinks.protection.outlook.com/?url=
> > https%3A%2F%2Fsnag.gy
> > >>%2FAm2fRX.jpg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> > 8494%7Cfa7b1b
> > >>5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
> > sdata=Z4b6dMq%2Br
> > >>UmSSxpGYNjgKl0nkRkIlV%2FbQIDLVUIvo6E%3D&reserved=0)
> > >> that
> > >> I did quickly is:
> > >>
> > >> CSS
> > >>
> > >> /* Background: */
> > >> background: #D8D8D8;
> > >> border: 1px solid #979797;
> > >> border-radius: 3px;
> > >>
> > >> /* TextField: */
> > >> font-family: HelveticaNeue;
> > >> font-size: 12px;
> > >> color: #646D7A;
> > >>
> > >> (CSS is almost all usable)
> > >>
> > >> And SVG
> > >>
> > >> <svg width="150px" height="40px" viewBox="0 0 150 40" version="1.1"
> > >>xmlns="
> > >>
> > >>https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fwww.w3.or
> > >>g%2F2000%2Fsvg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> > 8494%7Cfa7b1
> > >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
> > sdata=cWLJ2jj9Ih
> > >>cGnjAB8GEtEIdc3ZZO2OSAsgzPNEVrUzE%3D&reserved=0"
> > >>xmlns:xlink="https://na01.safelinks.protection.outlook.
> > com/?url=http%3A%2
> > >>F%2Fwww.w3.org%2F1999%2Fxlink&data=02%7C01%7C%
> > 7Cc23665e118fc4a7fed4c08d52
> > >>08c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> > 7C636450710247213906&s
> > >>data=sgNtytSumzad%2BraDA6NoITbm6XqJJx6yHQudjzhpm6Y%3D&reserved=0">
> > >> <!-- Generator: Sketch 47.1 (45422) -
> > >>
> > >>https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fwww.bohem
> > >>iancoding.com%2Fsketch&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> > 8494
> > >>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> > 7C636450710247213906&sdata=dE
> > >>oGVBONBD6Z1XMTjYcpEc7gq5UqtS8BziB0I3f9qSs%3D&reserved=0 -->
> > >> <desc>Created with Sketch.</desc>
> > >> <defs>
> > >> <rect id="path-1" x="0" y="0" width="150" height="40"
> > >> rx="3"></rect>
> > >> </defs>
> > >> <g id="Page-1" stroke="none" stroke-width="1" fill="none"
> > >> fill-rule="evenodd">
> > >> <g id="Royale" transform="translate(-58.000000, -49.000000)">
> > >> <g id="Button" transform="translate(58.000000,
> 49.000000)">
> > >> <g id="Background">
> > >> <use fill="#D8D8D8" fill-rule="evenodd"
> > >> xlink:href="#path-1"></use>
> > >> <rect stroke="#979797" stroke-width="1" x="0.5"
> > >>y="0.5"
> > >> width="149" height="39" rx="3"></rect>
> > >> </g>
> > >> <text id="TextField" font-family="HelveticaNeue,
> > >>Helvetica
> > >> Neue" font-size="12" font-weight="normal" fill="#646D7A">
> > >> <tspan x="57" y="25">Button</tspan>
> > >> </text>
> > >> </g>
> > >> </g>
> > >> </g>
> > >> </svg>
> > >>
> > >> (SVG could be a base, but it needs to be removed absolute values and
> > >>even
> > >> some static parts to be usable)
> > >>
> > >> I'd like to create a Button "playground" app with a button and some
> > >> controls that allow us to change how the button looks (colors,
> strokes,
> > >> round corners, font face, font weight,....)
> > >>
> > >> In the end this would be the starting point of a playground app for
> all
> > >> Royale controls
> > >>
> > >> Finaly this would be very useful if we can get the generated code for
> > >>that
> > >> particular styles and we could apply easily to any app, so change a
> > >>"theme"
> > >> will be quick and easy. Important: This will only work with our Royale
> > >> components (Express mainly, and maybe Basic?, but not MDL, CreateJS,
> or
> > >> others)
> > >>
> > >> I'm as well interested in how we could integrate that "view" in some
> > >> component in order to easy replace visuals for a concrete component.
> For
> > >> example, in the button above will be
> > >>
> > >> * we'll be making a skin part with SVG code, so we could pass values
> to
> > >>the
> > >> skin (for example colors, text button, width,...)
> > >> * if not using skins, how can we pass data from the component to the
> svg
> > >> part? (for example colors, text button, width,...)
> > >>
> > >> To progress with this effort, I think I could start doing only two
> > >> controls, and then as we have all considerations in place progress
> > >>through
> > >> the rest.
> > >>
> > >> Thoughts?
> > >>
> > >> --
> > >> Carlos Rovira
> > >>
> > >>https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fabout.me%
> > >>2Fcarlosrovira&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> > 8494%7Cfa7b1
> > >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
> > sdata=auPeQ0ub4B
> > >>Iq%2FTscLQWJ0Xxb9XdM2eegav2v1LXcuYY%3D&reserved=0
> > >>
> > >
> > >
> > >
> > >--
> > >
> > >Piotr Zarzycki
> > >
> > >mobile: +48 880 859 557
> > >skype: zarzycki10
> > >
> > >LinkedIn:
> > >https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fwww.linked
> > >in.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> > 8494%
> > >7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=
> > xZ56
> > >se7Z6gcWKcC7PuWDPW0E6F9wQjEZkuYZO4zvwnY%3D&reserved=0
> > ><https://na01.safelinks.protection.outlook.com/?url=
> > https%3A%2F%2Fpl.linke
> > >din.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%
> > 7C01%7C%7Cc23665e118fc4a7fe
> > >d4c08d5208c8494%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C6364507102472
> > >13906&sdata=1pwc5Fz1vKM2YCp6yUSe6x1Zdh9Au2xqb28Duy2Tqac%3D&reserved=0>
> > >
> > >GitHub:
> > >https://na01.safelinks.protection.outlook.com/?url=
> > https%3A%2F%2Fgithub.co
> > >m%2Fpiotrzarzycki21&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> > 8494%7Cf
> > >a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=
> > Lr7JdnU
> > >fF%2F4xHJbXVZlZN%2Fw7t4Tz5R5KbZFwdVnZFww%3D&reserved=0
> >
> >
>
>
> --
>
> Piotr Zarzycki
>
> mobile: +48 880 859 557
> skype: zarzycki10
>
> LinkedIn: http://www.linkedin.com/piotrzarzycki
> <https://pl.linkedin.com/in/piotr-zarzycki-92a53552>
>
> GitHub: https://github.com/piotrzarzycki21
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Working on UI Controls styling
Posted by Piotr Zarzycki <pi...@gmail.com>.
I can say at this point that I really like idea with swappable view. In
most cases view is an ActionScript class where we may have more possibility
to do things. When I was looking last time into the checkbox it for sure
need to more love, some part of the logic should be moved to the View.
Piotr
2017-10-31 20:50 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> Ugh, Something has gone bad in the Basic components. Things like
> CheckBox and RadioButton should be creating simple <input type="check"/>
> and <input type='radio' /> elements.
>
> The ability to style everything belongs in a different set of components.
> Basic is supposed to generate the simplest tree of HTMLElements even if
> they can't be fully styles. That's so someone can do the equivalent of
> just using bare bones <input> elements.
>
> What is currently in Basic CheckBox and RadioButton might be right for
> creating fully styleable components, or some other composition of
> HTMLElements might be better. Carlos, I think that's up to you to decide.
>
> An alternative approach is to have the JS implementations of CheckBox and
> RadioButton have views and the views could create the HTMLElements. That
> seems a bit heavy for the simple case of someone who just wants to use
> <input type="check" in an app, but that is a possibility.
>
> It sounds like you are looking for a way to manipulate SVG at runtime. It
> is fine to have "static SVG" which is a block of SVG with that cannot be
> modified and thus uses percentages and absolute values as best it can.
> Then we probably want to have a way to create "dynamic" skins with run
> code to generate or manipulate SVG. Those will be heavier, but that's
> PAYG. Should we try to allow SVG tags in MXML files? Then you could
> write code in an fx:Script block around your SVG tags and manipulate the
> SVG?
>
> So IMO first, we should look into reverting Basic back to single simple
> HTMLElements where possible, then decide whether we want to have swappable
> views or a new skinnable component set, then build out that component set
> and see what code it takes to get it to look the way we want it. And then
> we'll know what code is needed and can plan out how to encapsulate and
> re-use that code.
>
> My 2 cents,
> -Alex
>
> On 10/31/17, 11:23 AM, "Piotr Zarzycki" <pi...@gmail.com> wrote:
>
> >Hi Carlos,
> >
> >I think you should start looking into the Basic module and later make an
> >upgrades to Express once you have all components visually created. I would
> >not think on that stage about how we implement them rather look how they
> >look like currently.
> >
> >1) Create small app or run example with that component from our
> >repository.
> >2) Make it visually with theme
> >3) Show on the dev list - once we agree on all of them we can decide how
> >to
> >apply those styles.
> >
> >My 2 cents. :) Piotr
> >
> >
> >2017-10-31 19:12 GMT+01:00 Carlos Rovira <ca...@apache.org>:
> >
> >> Hi,
> >>
> >> I'm trying to find a valid workflow to start working in two initial
> >>faces
> >> for Royale components.
> >>
> >> I'm talking about to generate some kind of UI sheet with all controls
> >>and a
> >> basic wireframe style and another one that would be what more people
> >>will
> >> be using as default in Royale. From here, will be more easy to other
> >>guys
> >> to change styles. We could event create a Royale Theme editor in a near
> >> future.
> >>
> >> So, to start working on this I need a design tool, and in this case, I
> >> think that one is Sketch App.
> >>
> >> So I can create a design in Sketch with all controls (Button, TextInput,
> >> CheckBox, Panel,...)
> >>
> >> From here, I can generate CSS and SVG code
> >>
> >> For example the code of this simple button
> >>(https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fsnag.gy
> >>%2FAm2fRX.jpg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> 8494%7Cfa7b1b
> >>5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
> sdata=Z4b6dMq%2Br
> >>UmSSxpGYNjgKl0nkRkIlV%2FbQIDLVUIvo6E%3D&reserved=0)
> >> that
> >> I did quickly is:
> >>
> >> CSS
> >>
> >> /* Background: */
> >> background: #D8D8D8;
> >> border: 1px solid #979797;
> >> border-radius: 3px;
> >>
> >> /* TextField: */
> >> font-family: HelveticaNeue;
> >> font-size: 12px;
> >> color: #646D7A;
> >>
> >> (CSS is almost all usable)
> >>
> >> And SVG
> >>
> >> <svg width="150px" height="40px" viewBox="0 0 150 40" version="1.1"
> >>xmlns="
> >>
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.w3.or
> >>g%2F2000%2Fsvg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> 8494%7Cfa7b1
> >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
> sdata=cWLJ2jj9Ih
> >>cGnjAB8GEtEIdc3ZZO2OSAsgzPNEVrUzE%3D&reserved=0"
> >>xmlns:xlink="https://na01.safelinks.protection.outlook.
> com/?url=http%3A%2
> >>F%2Fwww.w3.org%2F1999%2Fxlink&data=02%7C01%7C%
> 7Cc23665e118fc4a7fed4c08d52
> >>08c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636450710247213906&s
> >>data=sgNtytSumzad%2BraDA6NoITbm6XqJJx6yHQudjzhpm6Y%3D&reserved=0">
> >> <!-- Generator: Sketch 47.1 (45422) -
> >>
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.bohem
> >>iancoding.com%2Fsketch&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> 8494
> >>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636450710247213906&sdata=dE
> >>oGVBONBD6Z1XMTjYcpEc7gq5UqtS8BziB0I3f9qSs%3D&reserved=0 -->
> >> <desc>Created with Sketch.</desc>
> >> <defs>
> >> <rect id="path-1" x="0" y="0" width="150" height="40"
> >> rx="3"></rect>
> >> </defs>
> >> <g id="Page-1" stroke="none" stroke-width="1" fill="none"
> >> fill-rule="evenodd">
> >> <g id="Royale" transform="translate(-58.000000, -49.000000)">
> >> <g id="Button" transform="translate(58.000000, 49.000000)">
> >> <g id="Background">
> >> <use fill="#D8D8D8" fill-rule="evenodd"
> >> xlink:href="#path-1"></use>
> >> <rect stroke="#979797" stroke-width="1" x="0.5"
> >>y="0.5"
> >> width="149" height="39" rx="3"></rect>
> >> </g>
> >> <text id="TextField" font-family="HelveticaNeue,
> >>Helvetica
> >> Neue" font-size="12" font-weight="normal" fill="#646D7A">
> >> <tspan x="57" y="25">Button</tspan>
> >> </text>
> >> </g>
> >> </g>
> >> </g>
> >> </svg>
> >>
> >> (SVG could be a base, but it needs to be removed absolute values and
> >>even
> >> some static parts to be usable)
> >>
> >> I'd like to create a Button "playground" app with a button and some
> >> controls that allow us to change how the button looks (colors, strokes,
> >> round corners, font face, font weight,....)
> >>
> >> In the end this would be the starting point of a playground app for all
> >> Royale controls
> >>
> >> Finaly this would be very useful if we can get the generated code for
> >>that
> >> particular styles and we could apply easily to any app, so change a
> >>"theme"
> >> will be quick and easy. Important: This will only work with our Royale
> >> components (Express mainly, and maybe Basic?, but not MDL, CreateJS, or
> >> others)
> >>
> >> I'm as well interested in how we could integrate that "view" in some
> >> component in order to easy replace visuals for a concrete component. For
> >> example, in the button above will be
> >>
> >> * we'll be making a skin part with SVG code, so we could pass values to
> >>the
> >> skin (for example colors, text button, width,...)
> >> * if not using skins, how can we pass data from the component to the svg
> >> part? (for example colors, text button, width,...)
> >>
> >> To progress with this effort, I think I could start doing only two
> >> controls, and then as we have all considerations in place progress
> >>through
> >> the rest.
> >>
> >> Thoughts?
> >>
> >> --
> >> Carlos Rovira
> >>
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%
> >>2Fcarlosrovira&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> 8494%7Cfa7b1
> >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
> sdata=auPeQ0ub4B
> >>Iq%2FTscLQWJ0Xxb9XdM2eegav2v1LXcuYY%3D&reserved=0
> >>
> >
> >
> >
> >--
> >
> >Piotr Zarzycki
> >
> >mobile: +48 880 859 557
> >skype: zarzycki10
> >
> >LinkedIn:
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.linked
> >in.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> 8494%
> >7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=
> xZ56
> >se7Z6gcWKcC7PuWDPW0E6F9wQjEZkuYZO4zvwnY%3D&reserved=0
> ><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpl.linke
> >din.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%
> 7C01%7C%7Cc23665e118fc4a7fe
> >d4c08d5208c8494%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6364507102472
> >13906&sdata=1pwc5Fz1vKM2YCp6yUSe6x1Zdh9Au2xqb28Duy2Tqac%3D&reserved=0>
> >
> >GitHub:
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.co
> >m%2Fpiotrzarzycki21&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> 8494%7Cf
> >a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=
> Lr7JdnU
> >fF%2F4xHJbXVZlZN%2Fw7t4Tz5R5KbZFwdVnZFww%3D&reserved=0
>
>
--
Piotr Zarzycki
mobile: +48 880 859 557
skype: zarzycki10
LinkedIn: http://www.linkedin.com/piotrzarzycki
<https://pl.linkedin.com/in/piotr-zarzycki-92a53552>
GitHub: https://github.com/piotrzarzycki21
Re: Working on UI Controls styling
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Ugh, Something has gone bad in the Basic components. Things like
CheckBox and RadioButton should be creating simple <input type="check"/>
and <input type='radio' /> elements.
The ability to style everything belongs in a different set of components.
Basic is supposed to generate the simplest tree of HTMLElements even if
they can't be fully styles. That's so someone can do the equivalent of
just using bare bones <input> elements.
What is currently in Basic CheckBox and RadioButton might be right for
creating fully styleable components, or some other composition of
HTMLElements might be better. Carlos, I think that's up to you to decide.
An alternative approach is to have the JS implementations of CheckBox and
RadioButton have views and the views could create the HTMLElements. That
seems a bit heavy for the simple case of someone who just wants to use
<input type="check" in an app, but that is a possibility.
It sounds like you are looking for a way to manipulate SVG at runtime. It
is fine to have "static SVG" which is a block of SVG with that cannot be
modified and thus uses percentages and absolute values as best it can.
Then we probably want to have a way to create "dynamic" skins with run
code to generate or manipulate SVG. Those will be heavier, but that's
PAYG. Should we try to allow SVG tags in MXML files? Then you could
write code in an fx:Script block around your SVG tags and manipulate the
SVG?
So IMO first, we should look into reverting Basic back to single simple
HTMLElements where possible, then decide whether we want to have swappable
views or a new skinnable component set, then build out that component set
and see what code it takes to get it to look the way we want it. And then
we'll know what code is needed and can plan out how to encapsulate and
re-use that code.
My 2 cents,
-Alex
On 10/31/17, 11:23 AM, "Piotr Zarzycki" <pi...@gmail.com> wrote:
>Hi Carlos,
>
>I think you should start looking into the Basic module and later make an
>upgrades to Express once you have all components visually created. I would
>not think on that stage about how we implement them rather look how they
>look like currently.
>
>1) Create small app or run example with that component from our
>repository.
>2) Make it visually with theme
>3) Show on the dev list - once we agree on all of them we can decide how
>to
>apply those styles.
>
>My 2 cents. :) Piotr
>
>
>2017-10-31 19:12 GMT+01:00 Carlos Rovira <ca...@apache.org>:
>
>> Hi,
>>
>> I'm trying to find a valid workflow to start working in two initial
>>faces
>> for Royale components.
>>
>> I'm talking about to generate some kind of UI sheet with all controls
>>and a
>> basic wireframe style and another one that would be what more people
>>will
>> be using as default in Royale. From here, will be more easy to other
>>guys
>> to change styles. We could event create a Royale Theme editor in a near
>> future.
>>
>> So, to start working on this I need a design tool, and in this case, I
>> think that one is Sketch App.
>>
>> So I can create a design in Sketch with all controls (Button, TextInput,
>> CheckBox, Panel,...)
>>
>> From here, I can generate CSS and SVG code
>>
>> For example the code of this simple button
>>(https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsnag.gy
>>%2FAm2fRX.jpg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c8494%7Cfa7b1b
>>5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=Z4b6dMq%2Br
>>UmSSxpGYNjgKl0nkRkIlV%2FbQIDLVUIvo6E%3D&reserved=0)
>> that
>> I did quickly is:
>>
>> CSS
>>
>> /* Background: */
>> background: #D8D8D8;
>> border: 1px solid #979797;
>> border-radius: 3px;
>>
>> /* TextField: */
>> font-family: HelveticaNeue;
>> font-size: 12px;
>> color: #646D7A;
>>
>> (CSS is almost all usable)
>>
>> And SVG
>>
>> <svg width="150px" height="40px" viewBox="0 0 150 40" version="1.1"
>>xmlns="
>>
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.or
>>g%2F2000%2Fsvg&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c8494%7Cfa7b1
>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=cWLJ2jj9Ih
>>cGnjAB8GEtEIdc3ZZO2OSAsgzPNEVrUzE%3D&reserved=0"
>>xmlns:xlink="https://na01.safelinks.protection.outlook.com/?url=http%3A%2
>>F%2Fwww.w3.org%2F1999%2Fxlink&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d52
>>08c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&s
>>data=sgNtytSumzad%2BraDA6NoITbm6XqJJx6yHQudjzhpm6Y%3D&reserved=0">
>> <!-- Generator: Sketch 47.1 (45422) -
>>
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bohem
>>iancoding.com%2Fsketch&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c8494
>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=dE
>>oGVBONBD6Z1XMTjYcpEc7gq5UqtS8BziB0I3f9qSs%3D&reserved=0 -->
>> <desc>Created with Sketch.</desc>
>> <defs>
>> <rect id="path-1" x="0" y="0" width="150" height="40"
>> rx="3"></rect>
>> </defs>
>> <g id="Page-1" stroke="none" stroke-width="1" fill="none"
>> fill-rule="evenodd">
>> <g id="Royale" transform="translate(-58.000000, -49.000000)">
>> <g id="Button" transform="translate(58.000000, 49.000000)">
>> <g id="Background">
>> <use fill="#D8D8D8" fill-rule="evenodd"
>> xlink:href="#path-1"></use>
>> <rect stroke="#979797" stroke-width="1" x="0.5"
>>y="0.5"
>> width="149" height="39" rx="3"></rect>
>> </g>
>> <text id="TextField" font-family="HelveticaNeue,
>>Helvetica
>> Neue" font-size="12" font-weight="normal" fill="#646D7A">
>> <tspan x="57" y="25">Button</tspan>
>> </text>
>> </g>
>> </g>
>> </g>
>> </svg>
>>
>> (SVG could be a base, but it needs to be removed absolute values and
>>even
>> some static parts to be usable)
>>
>> I'd like to create a Button "playground" app with a button and some
>> controls that allow us to change how the button looks (colors, strokes,
>> round corners, font face, font weight,....)
>>
>> In the end this would be the starting point of a playground app for all
>> Royale controls
>>
>> Finaly this would be very useful if we can get the generated code for
>>that
>> particular styles and we could apply easily to any app, so change a
>>"theme"
>> will be quick and easy. Important: This will only work with our Royale
>> components (Express mainly, and maybe Basic?, but not MDL, CreateJS, or
>> others)
>>
>> I'm as well interested in how we could integrate that "view" in some
>> component in order to easy replace visuals for a concrete component. For
>> example, in the button above will be
>>
>> * we'll be making a skin part with SVG code, so we could pass values to
>>the
>> skin (for example colors, text button, width,...)
>> * if not using skins, how can we pass data from the component to the svg
>> part? (for example colors, text button, width,...)
>>
>> To progress with this effort, I think I could start doing only two
>> controls, and then as we have all considerations in place progress
>>through
>> the rest.
>>
>> Thoughts?
>>
>> --
>> Carlos Rovira
>>
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>2Fcarlosrovira&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c8494%7Cfa7b1
>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=auPeQ0ub4B
>>Iq%2FTscLQWJ0Xxb9XdM2eegav2v1LXcuYY%3D&reserved=0
>>
>
>
>
>--
>
>Piotr Zarzycki
>
>mobile: +48 880 859 557
>skype: zarzycki10
>
>LinkedIn:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linked
>in.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c8494%
>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=xZ56
>se7Z6gcWKcC7PuWDPW0E6F9wQjEZkuYZO4zvwnY%3D&reserved=0
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpl.linke
>din.com%2Fin%2Fpiotr-zarzycki-92a53552&data=02%7C01%7C%7Cc23665e118fc4a7fe
>d4c08d5208c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364507102472
>13906&sdata=1pwc5Fz1vKM2YCp6yUSe6x1Zdh9Au2xqb28Duy2Tqac%3D&reserved=0>
>
>GitHub:
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
>m%2Fpiotrzarzycki21&data=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c8494%7Cf
>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&sdata=Lr7JdnU
>fF%2F4xHJbXVZlZN%2Fw7t4Tz5R5KbZFwdVnZFww%3D&reserved=0
Re: Working on UI Controls styling
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Carlos,
I think you should start looking into the Basic module and later make an
upgrades to Express once you have all components visually created. I would
not think on that stage about how we implement them rather look how they
look like currently.
1) Create small app or run example with that component from our repository.
2) Make it visually with theme
3) Show on the dev list - once we agree on all of them we can decide how to
apply those styles.
My 2 cents. :) Piotr
2017-10-31 19:12 GMT+01:00 Carlos Rovira <ca...@apache.org>:
> Hi,
>
> I'm trying to find a valid workflow to start working in two initial faces
> for Royale components.
>
> I'm talking about to generate some kind of UI sheet with all controls and a
> basic wireframe style and another one that would be what more people will
> be using as default in Royale. From here, will be more easy to other guys
> to change styles. We could event create a Royale Theme editor in a near
> future.
>
> So, to start working on this I need a design tool, and in this case, I
> think that one is Sketch App.
>
> So I can create a design in Sketch with all controls (Button, TextInput,
> CheckBox, Panel,...)
>
> From here, I can generate CSS and SVG code
>
> For example the code of this simple button (https://snag.gy/Am2fRX.jpg)
> that
> I did quickly is:
>
> CSS
>
> /* Background: */
> background: #D8D8D8;
> border: 1px solid #979797;
> border-radius: 3px;
>
> /* TextField: */
> font-family: HelveticaNeue;
> font-size: 12px;
> color: #646D7A;
>
> (CSS is almost all usable)
>
> And SVG
>
> <svg width="150px" height="40px" viewBox="0 0 150 40" version="1.1" xmlns="
> http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
> <!-- Generator: Sketch 47.1 (45422) -
> http://www.bohemiancoding.com/sketch -->
> <desc>Created with Sketch.</desc>
> <defs>
> <rect id="path-1" x="0" y="0" width="150" height="40"
> rx="3"></rect>
> </defs>
> <g id="Page-1" stroke="none" stroke-width="1" fill="none"
> fill-rule="evenodd">
> <g id="Royale" transform="translate(-58.000000, -49.000000)">
> <g id="Button" transform="translate(58.000000, 49.000000)">
> <g id="Background">
> <use fill="#D8D8D8" fill-rule="evenodd"
> xlink:href="#path-1"></use>
> <rect stroke="#979797" stroke-width="1" x="0.5" y="0.5"
> width="149" height="39" rx="3"></rect>
> </g>
> <text id="TextField" font-family="HelveticaNeue, Helvetica
> Neue" font-size="12" font-weight="normal" fill="#646D7A">
> <tspan x="57" y="25">Button</tspan>
> </text>
> </g>
> </g>
> </g>
> </svg>
>
> (SVG could be a base, but it needs to be removed absolute values and even
> some static parts to be usable)
>
> I'd like to create a Button "playground" app with a button and some
> controls that allow us to change how the button looks (colors, strokes,
> round corners, font face, font weight,....)
>
> In the end this would be the starting point of a playground app for all
> Royale controls
>
> Finaly this would be very useful if we can get the generated code for that
> particular styles and we could apply easily to any app, so change a "theme"
> will be quick and easy. Important: This will only work with our Royale
> components (Express mainly, and maybe Basic?, but not MDL, CreateJS, or
> others)
>
> I'm as well interested in how we could integrate that "view" in some
> component in order to easy replace visuals for a concrete component. For
> example, in the button above will be
>
> * we'll be making a skin part with SVG code, so we could pass values to the
> skin (for example colors, text button, width,...)
> * if not using skins, how can we pass data from the component to the svg
> part? (for example colors, text button, width,...)
>
> To progress with this effort, I think I could start doing only two
> controls, and then as we have all considerations in place progress through
> the rest.
>
> Thoughts?
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
--
Piotr Zarzycki
mobile: +48 880 859 557
skype: zarzycki10
LinkedIn: http://www.linkedin.com/piotrzarzycki
<https://pl.linkedin.com/in/piotr-zarzycki-92a53552>
GitHub: https://github.com/piotrzarzycki21