Re: Working on UI Controls styling

[Piotr Zarzycki]

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 :

> 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 
>
> 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:
> enabled="{bugReportEnabled}" width="72"
> height="82"
>x="19" y="283"
>click="reportBug()" className="bug"/>
>
> I wanted to allow the following:
>
> 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  questions/5293280/css-pseudo-classes-with-inline-styles>
> [2]https://stackoverflow.com/questions/986618/is-it-
> possible-to-create-inline-pseudo-styles  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 
> 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 :
> >
> >> 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 

RE: Working on UI Controls styling

[Idylog - Nicolas Granon]

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:p...@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
> <harbs.li...@gmail.com<mailto:harbs.li...@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=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7C
> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243=tko
> afaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%3D=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste
> .apache.org%2Ftc8f=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7
> Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456506748081243=tk
> oafaegyBTfQezUYJl2CJLgrc3aedf2UEqsSz8NTY4%3D=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:
>   enabled="{bugReportEnabled}" width="72" height="82"
>   x="19" y="283"
>   click="reportBug()" className="bug"/>
> 
> I wanted to allow the following:
> 
>   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=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3
> 4438794aed2c178decee1%7C0%7C0%7C636456506748081243=krVr8HQkvOU3nq
> ALzR4Hs5mzQbbB9m3v5uWgBzRkPII%3D=0
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstack
> overflow.com%2Fquestions%2F5293280%2Fcss-pseudo-classes-with-inline-
> styles=02%7C01%7C%7C24fb66825ebf4f27c58b08d525d21de0%7Cfa7b1b5a7b3
> 4438794ae

Re: Working on UI Controls styling

[Harbs]

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 

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:


I wanted to allow the following:



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
 

[2]https://stackoverflow.com/questions/986618/is-it-possible-to-create-inline-pseudo-styles
 

[3]https://stackoverflow.com/a/5293426/5475183 

[4]https://stackoverflow.com/a/39712777/5475183 


> On Nov 6, 2017, at 8:22 PM, Carlos Rovira  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 :
> 
>> 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 :
>> 
>>> 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.rov...@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 

Re: Working on UI Controls styling

[Harbs]

+1.

> On Nov 6, 2017, at 8:22 PM, Carlos Rovira  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 :
> 
>> 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 :
>> 
>>> 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.rov...@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 :
 
> 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 

Re: Working on UI Controls styling

[Carlos Rovira]

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 :

> 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 :
>
> > 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.rov...@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 :
> > >
> > >> 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
> 

Re: Working on UI Controls styling

[Harbs]

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  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  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

[Alex Harui]

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"  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 :
>
>> 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  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"  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
>> 

Re: Working on UI Controls styling

[Piotr Zarzycki]

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 :

> 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  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"  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=02%7C0
> >1%7C%7Cdfc2dc02415b446e995108d524945950%7Cfa7b1b5a7b34438794aed2c178de
> cee1
> >%7C0%7C0%7C636455141932227764=CCCp3fmlnGFtImPTsEf9JsIXJdkcQV
> g3zbkIch
> >2buoc%3D=0
> >
> >Hope this is useful,
> >Harbs
> >
> >> On Nov 5, 2017, at 11:01 PM, Piotr Zarzycki 
> >>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 

Re: Working on UI Controls styling

[Alex Harui]

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  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"  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=02%7C0
>1%7C%7Cdfc2dc02415b446e995108d524945950%7Cfa7b1b5a7b34438794aed2c178decee1
>%7C0%7C0%7C636455141932227764=CCCp3fmlnGFtImPTsEf9JsIXJdkcQVg3zbkIch
>2buoc%3D=0
>
>Hope this is useful,
>Harbs
>
>> On Nov 5, 2017, at 11:01 PM, Piotr Zarzycki 
>>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 :
>> 
>>> I would suggest starting a new component set with a 

Re: Working on UI Controls styling

[Harbs]

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  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 :
> 
>> 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.rov...@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 :

Re: Working on UI Controls styling

[Piotr Zarzycki]

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 :

> 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.rov...@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 :
> >
> >> 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.rov...@gmail.com on behalf of Carlos
> Rovira"
> >>  wrote:
> >>
> >>> HI Alex,
> >>>
> >>>
> >>> 2017-11-03 17:52 GMT+01:00 Alex Harui :
> >>>
>  Hi Carlos,
> 
>  I skimmed through
>  

Re: Working on UI Controls styling

[Harbs]

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  
> 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 :
> 
>> 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.rov...@gmail.com on behalf of Carlos Rovira"
>>  wrote:
>> 
>>> HI Alex,
>>> 
>>> 
>>> 2017-11-03 17:52 GMT+01:00 Alex Harui :
>>> 
 Hi Carlos,
 
 I skimmed through
 https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fmaterial
 .io%2Fguidelines%2F%23=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
>> 82e0
 %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636454056000808812=g5
 M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D=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

Re: Working on UI Controls styling

[Carlos Rovira]

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 :

> 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.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >HI Alex,
> >
> >
> >2017-11-03 17:52 GMT+01:00 Alex Harui :
> >
> >> Hi Carlos,
> >>
> >> I skimmed through
> >>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fmaterial
> >>.io%2Fguidelines%2F%23=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
> 82e0
> >>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636454056000808812=g5
> >>M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D=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: Working on UI Controls styling

[Piotr Zarzycki]

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  wrote:

> HI Alex,
>
>
> 2017-11-03 17:52 GMT+01:00 Alex Harui :
>
> > 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  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 

Re: Working on UI Controls styling

[Carlos Rovira]

HI Alex,


2017-11-03 17:52 GMT+01:00 Alex Harui :

> 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  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.rov...@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 

RE: Working on UI Controls styling

[Idylog - Nicolas Granon]

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:aha...@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 
> 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.rov...@gmail.com on behalf of Carlos
> Rovira"
> <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com>
> wrote:
> 
> >Hi Alex,
> >
> >2017-11-03 7:39 GMT+01:00 Alex Harui <aha...@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 so

Re: Working on UI Controls styling

[Alex Harui]

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.rov...@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 > 

Re: Working on UI Controls styling

[Piotr Zarzycki]

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 :

> 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 
> 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


GitHub: https://github.com/piotrzarzycki21

Re: Working on UI Controls styling

[Harbs]

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  wrote:
> 
> The problem with Trevor and Angelo is that are not very active here.

Re: Working on UI Controls styling

[Carlos Rovira]

Hi Harbs,

2017-11-03 8:57 GMT+01:00 Harbs :

> 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/ 
>
> 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 
> 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, maybe as I did, in
> > some grey scale colors. But for Vivid, I'm still figuring if it should be
> > something "flat" 

Re: Working on UI Controls styling

[Harbs]

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/ 

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  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, 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 greator
> 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:
>>> 

Re: Working on UI Controls styling

[Alex Harui]

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 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.

Thanks,
Alex

On 11/2/17, 5:15 PM, "carlos.rov...@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=02%7C01%7C%7C203485b5b9c744aed92608d522500f48%7Cfa7b1b5a7
>b34438794aed2c178decee1%7C0%7C0%7C636452649612378558=%2Fk8YQxC5bDOaC
>D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D=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=02%7C01%7C%7C203485b5b9c744aed92608d522500f48%7Cfa7b1b5a7
>b34438794aed2c178decee1%7C0%7C0%7C636452649612378558=kxYE7ylOsXPUEeE
>r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D=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, 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 greator
>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:

Re: Working on UI Controls styling

[Carlos Rovira]

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, 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 greator
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://vcalendar.netlify.com/ 
>>
>> > 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://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 > > 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  

Re: Working on UI Controls styling

[Carlos Rovira]

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 :

> 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  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

[Harbs]

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  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"  > 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  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  wrote:
 
 >>> src="assets/images/icons/0896-flip-horizontal2.svg"/>
 >>> src="assets/images/icons/0897-flip-vertical2.svg"/>
 
 
> On Nov 1, 2017, at 2:45 PM, Carlos Rovira
>  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 :
> 
>> 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 
>> 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=02%7C01%7C%7Cb9d4d9d3a67f4966e3d408d52
>>> 12b2186%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364513914828032
>>> 19=iiUxSDh%2Be%2F3Zt37Lo2IdRYxgA8tIeyYTTawRO2WSNOI%3D=
>>> 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,

Re: Working on UI Controls styling

[Harbs]

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  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  wrote:
>> 
>> > src="assets/images/icons/0896-flip-horizontal2.svg"/>
>> > src="assets/images/icons/0897-flip-vertical2.svg"/>
>> 
>> 
>>> On Nov 1, 2017, at 2:45 PM, Carlos Rovira  
>>> 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 :
>>> 
 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 
 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 :
> 
>> 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 :
>> 
>>> Ugh,  Something has gone bad in the Basic components.  Things like
>>> CheckBox and RadioButton should be creating simple >>> type="check"/>
>>> and  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  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
>>> >> 
>>> 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 

Re: Working on UI Controls styling

[Harbs]

> On Nov 1, 2017, at 2:45 PM, Carlos Rovira  
> 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 :
> 
>> 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 
>> 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 :
>>> 
 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 :
 
> Ugh,  Something has gone bad in the Basic components.  Things like
> CheckBox and RadioButton should be creating simple > type="check"/>
> and  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  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
>  
> 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" 
 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.
>> 
>> 

Re: Working on UI Controls styling

[Carlos Rovira]

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 :

> 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 
> 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 :
> >
> >> 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 :
> >>
> >>> Ugh,  Something has gone bad in the Basic components.  Things like
> >>> CheckBox and RadioButton should be creating simple  type="check"/>
> >>> and  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  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
> >>>  >>>
> >>> 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" 
> >> 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 :
> 
> > Hi,
> >
> > I'm trying 

Re: Working on UI Controls styling

[Piotr Zarzycki]

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 :

> Ugh,  Something has gone bad in the Basic components.  Things like
> CheckBox and RadioButton should be creating simple 
> and  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  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
> 
> 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"  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 :
> >
> >> 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=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> 8494%7Cfa7b1b
> >>5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
> sdata=Z4b6dMq%2Br
> >>UmSSxpGYNjgKl0nkRkIlV%2FbQIDLVUIvo6E%3D=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
> >>
> >>  >>xmlns="
> >>
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.w3.or
> >>g%2F2000%2Fsvg=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c
> 8494%7Cfa7b1
> >>b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906&
> sdata=cWLJ2jj9Ih
> >>cGnjAB8GEtEIdc3ZZO2OSAsgzPNEVrUzE%3D=0"
> >>xmlns:xlink="https://na01.safelinks.protection.outlook.
> com/?url=http%3A%2
> >>F%2Fwww.w3.org%2F1999%2Fxlink=02%7C01%7C%
> 7Cc23665e118fc4a7fed4c08d52
> >>08c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636450710247213906
> >>data=sgNtytSumzad%2BraDA6NoITbm6XqJJx6yHQudjzhpm6Y%3D=0">
> >> 
> >> Created with Sketch.
> >> 
> >>  >> rx="3">
> >> 
> >>  >> fill-rule="evenodd">
> >> 
> 

Re: Working on UI Controls styling

[Alex Harui]

Ugh,  Something has gone bad in the Basic components.  Things like
CheckBox and RadioButton should be creating simple 
and  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  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
 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 :
>
>> 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=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c8494%7Cfa7b1b
>>5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906=Z4b6dMq%2Br
>>UmSSxpGYNjgKl0nkRkIlV%2FbQIDLVUIvo6E%3D=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
>>
>> >xmlns="
>> 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.or
>>g%2F2000%2Fsvg=02%7C01%7C%7Cc23665e118fc4a7fed4c08d5208c8494%7Cfa7b1
>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906=cWLJ2jj9Ih
>>cGnjAB8GEtEIdc3ZZO2OSAsgzPNEVrUzE%3D=0"
>>xmlns:xlink="https://na01.safelinks.protection.outlook.com/?url=http%3A%2
>>F%2Fwww.w3.org%2F1999%2Fxlink=02%7C01%7C%7Cc23665e118fc4a7fed4c08d52
>>08c8494%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636450710247213906
>>data=sgNtytSumzad%2BraDA6NoITbm6XqJJx6yHQudjzhpm6Y%3D=0">
>> 
>> Created with Sketch.
>> 
>> > rx="3">
>> 
>> > fill-rule="evenodd">
>> 
>> 
>> 
>> > xlink:href="#path-1">
>> >y="0.5"
>> width="149" height="39" rx="3">
>> 
>> 
>> Button
>> 
>> 
>> 
>> 
>> 
>>
>> (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
>> 

Re: Working on UI Controls styling

[Piotr Zarzycki]

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 :

> 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
>
> http://www.w3.org/2000/svg; xmlns:xlink="http://www.w3.org/1999/xlink;>
> 
> Created with Sketch.
> 
>  rx="3">
> 
>  fill-rule="evenodd">
> 
> 
> 
>  xlink:href="#path-1">
>  width="149" height="39" rx="3">
> 
> 
> Button
> 
> 
> 
> 
> 
>
> (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


GitHub: https://github.com/piotrzarzycki21