You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2018/03/15 09:51:21 UTC

Re: Proper use of Themes and SASS

Hi Alex,

I didn't realize that I can add two themes to the build. If that's possible
in flex I never did.

So my main question here is, what happens if I have the same style in both
themes, what will win? will be both in the final app?
For example I can make JewelTheme used alone be some kind of default theme
(greyed or wireframed) and when added JewelBlueTheme, be colored in blue
So in JewelTheme and JewelBlueTheme will have the same style with
"background-color" set in one to grey and in the other one to blue.
Don't need to answer this, I'll try to do it myself and see what happen.

Comparing with for example MDL. I think they created lots of palettes and
build all combinations of final CSSs (thanks to using SASS). I think we can
do the same, although once we have a 1 or 2 themes working, that would be
work to do. I think Semantic does something similar. We can choose some
colors and offer those themes as part of royale. For other colors people
will need to create it themselves, even pull request us to include as part
of our release. We only loose one thing respect to foro example MDL: The
way to indicate two basic colors and get the final CSS, or maybe we could
consider that add to the -theme JewelTheme the word "Blue", can be enough.
All of this already means only *one color* (jewel-blue), and if we want
something more material should be jewel-blue-green for example

Regarding the problem with alone csss in maven, I think the right way is to
use a theme folder structure, so I really doesn't think that as a bug but
like a feature hehe ;)

With SASS, I only see a problem in the workflow. That can be solved as soon
as people not using SASS take care of it.
If someone changes the produced css without touch the sass files, this will
make that a new SASS compilation overrides the changes.
That is easy to solve since we all have to take care to not change one
without the other.

In the other hand, and after some days of playing with SASS, I want to
share that my experience is very positive and now understand why the rest
of theme frameworks out there uses some kind of css development tool
(Material uses SASS, Semantic LESS, ...). As a theme/UX developer is the
same I already mentioned, not using this will be like authoring an icon
without a creative tool like Sketch or Photoshop. I continue thinking that
SASS should not be part of Royale but maybe in people using ant should
introduce in the concrete case of JewelTheme the sass compilation. But not
for the rest (Basic , and others). Think of this as a sugerence, but for me
doesn't mind since I'm not an ANT user. Maybe in the future if we get other
Royale things with more priority done, we could introduce our own
sass-flavor compilation (something like ROCSS! ;)), that could give us the
same SASS does plus the ability to combine with AS3/MXML substitutions.

Final words, I'm thinking, as compiler, and structural problems will be
solved to make the following themes based of Jewel structure of html and
css rule selectors:

- Jewel (this is where I'm now and will set the foundation of names and all
that is need for each component, then we can have maybe 6 to 12 colors,
and/or combinations, to make this without SASS, I think is not possible
since means to automatically generate those final css and combinations, and
think about change only one attribute, what means to change this in the
rest of css. Doing this manually would make people spend hours)

-Material (this will have the same look as google material, and again, I
must create the different flavors of colors, again sass is involved in
order to not kill myself in the intention ;)

-Semantic (same as before replicating semantic)

-Bootstrap (same as the other cases replicating bootstrap)

This would be a huge effort, and with many time involved, maybe I never
could end this alone and can depend on how Royale be adopted in the
folowing months years. But this could make us to be very attractive since
people can change between different looks easily. This as well has a
consideration to, there are many components in that sets that are not in
royale, and maybe will never come, and I think that's not important. I talk
about have a common factor and try to recreate the different controls that
are in only in royale. Maybe we can consider to add for example a Card or
Badge component if we consider util...don't know.

Thanks



2018-03-14 18:32 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:

> So in trying to get the JewelExample to work, I think I understand what
> Carlos is trying to do with the Jewel Theme.  I'm going to attempt to
> clear up some confusion and propose a plan.  Note that below I am not
> using actual file names for brevity and clarity.
>
> A Theme in Royale is the same as it was in Flex.  It can be a SWC with
> code and assets (and some CSS), or just a simple CSS file.  You can
> specify more than one theme to the compiler.
>
> The themes/JewelTheme is not set up properly right now.  It has both a
> red.css and blue.css file that are being included in the JewelTheme.swc.
> The compiler has been taught to include all css in a SWC in the final
> output.  Really, in the themes folder there should be a JewelBlue folder
> with just a jewel-blue.css file in it and a JewelRed folder with just a
> jewel-red.css file in it and a JewelTheme folder with only shared assets.
>
> In Ant, command-line, or IDEs, the user would specify both JewelTheme.swc
> and either jewel-blue.css or jewel-red.css as themes.  For Maven, it is
> not clear how to make a simple css file be a Maven artifact so for other
> CSS-only themes, so we still build a SWC with only the .css file in it.
> See the basic.css in themes.
>
> IMO, that’s the Royale way for choosing your "primary" color of the theme
> at compile-time.  I think there may be customers who already know this and
> will expect it to work.  I don't see the need to develop some other way
> like additional compiler options and substitutions.
>
> If someone like Carlos wants to use SASS to generate the jewel-red.css and
> jewel-blue.css, I guess that's ok as long as that isn't part of the build
> such that every developer and patcher needs to install SASS.  We can call
> the "final" css files that are committed to the repo the source, IMO.
>
> Thoughts?
> -Alex
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Proper use of Themes and SASS

Posted by Alex Harui <ah...@adobe.com.INVALID>.

Hi Carlos,

I think your understanding of the technical part is correct except for one
thing:  Unless I'm forgetting something, you should be able to swap view
beads without touching the application code.  The view bead works with
some CSS to create the visuals.  Unless the visuals are vastly different,
replacement should "just work".  IOW, the user of a Button probably has no
code that is sensitive to whether the Button is actually:

<div>
  <label class="royale_button_label">
  <input class="royale_button_input">
</div>

Or:

<div>
  <label class="bootstrap_button_label">
  <input class="bootstrap_button_input">
</div>

They shouldn't care, because the SWF version is going to have a completely
different View.  The only thing the user cares about is whether it looks
good and dispatches a click event.


However, that does not mean that you should try to use Bootstrap for our
default theme because as I was trying to point out in my prior post, I
don't think Bootstrap has a default look for Panel, DataGrid and more.

If you want to try to emulate Bootstrap on the HTML structures you choose
for Jewel, that's fine, but I would think a reason not to do that would be
"expectations".  I think there are many Bootstrap themes and it will be
too much work and result in disappointment if we say we support Bootstrap
but can't support third-party Bootstrap themes without doing the work to
emulate those too.  IMO, the better strategy is to swap our HTML
structures for Bootstrap's HTML structures so their CSS can be used as-is
and then the additional work for third-party theme developers is to decide
on the CSS for our components like Panel and DataGrid.  And that way,
folks who don't use Panel and DataGrid can just use an existing Bootstrap
theme and it should just work in Royale.

But all that is future stuff, IMO.  Let's make sure we can get a default
theme in place for the components we have.

My 2 cents,
-Alex

On 3/16/18, 11:27 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:

>Hi Alex,
>
>I think you didn't understand me. My main goal is create a new UI set
>(Jewel) that can be easily stylizable using themes
>So people can code an App and change only a theme swc to change all
>styles.
>For that reason I always said that MDL library was very limited, since it
>was "only MDL".
>
>In this thread, I pointed to make different themes for Jewel (based in the
>structure of HTML and style name or class names I will create for Jewel).
>That implies that we will have our own style ( no mdl , no bootstrap,...),
>but that we can as well "emulate" the styles in other well-known libraries
>out there like bootstrap, semantic and, again, MDL. But for all of this,
>my
>plan is do it with the same html/styles that Jewel will enforce. So the
>key
>for this is emulation, an MDL button in Jewel will look mostly like a real
>MDL button, but will not be a real one, since the classes used will be
>"jewel button" and not "mdl-button" (like in the real lib). This implies,
>out components will always work consistently since will be the same royale
>component with different faces (css styles).
>
>Then, you open my mind to ViewBeads, so we can make a jewel button have
>different view beads, each one in its own library, so in this way we can
>match the same html structure and styles in native libraries. I love this
>idea, but then thinking about it I found some problems due to different
>"particularities" in each library.
>
>In Jewel we will end with a set of well defined properties to make the set
>easy to use. If we want to go the view bead, the only way I could think to
>get all the particularities of a concrete library is through beads, and
>that beads should be as some kind of interface or something, but in the
>end
>this will make people to change the app code and that's what I want to
>avoid.
>
>So I think this only let us with two options:
>
>1) Jewel set with themes that can emulate other styles out there, a part
>of
>our new styles
>2) Go the same path as we did with MDL to create Bootstrap, Semantic, and
>more.
>
>For me the path is 1), if I'm not missing something in my approach, since
>we should get our own presence a part from the rest, but as well I think
>emulate others, can be of great attractive to users, that only changing a
>theme can look very similar to mdl, semantic, or bootstrap.
>
>
>
>
>
>2018-03-16 17:38 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> Hi Carlos,
>>
>> I'm not sure I'm fully understanding you.
>>
>> If your question is about how to create a default look for Royale, I
>>would
>> not worry about Bootstrap and MDL.  Create the HTML structures you need
>> with the attributes you need and create the CSS that makes it look good.
>>
>> My point about Bootstrap is that if someday someone wants to support
>> Bootstrap in Royale, the way to do it is to create other views that
>>create
>> exactly the HTML structure expected by Bootstrap because then you can
>>use
>> any Bootstrap theme as-is.  Same for MDL, or any other CSS-based
>>framework.
>>
>> I don't think we can make one view for Button that works with Bootstrap
>> and MDL.  It would be nice if we could, but I think you are pointing out
>> that there are attributes in the HTML structure that are different for
>> each framework.
>>
>> I think Bootstrap and MDL do not have the same kinds of components that
>>we
>> have in Royale (like Panel and DataGrid) so existing themes will still
>> need enhancing to work for Royale components.  But the initial goal if
>>we
>> ever do try to support Bootstrap is just to create Royale components for
>> the components Bootstrap does support and if you can create your app
>>with
>> only those Bootstrap components, then any Bootstrap theme should "just
>> work" with it.
>>
>> My 2 cents.  Hopefully I am agreeing with you.
>> -Alex
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9f850f495faa4e34416208d5
>8b6baafb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636568216910167925&s
>data=PT1yI4VrmxsbkO55zy6XRqzU%2BFA6tYJzkIay7WQjkAw%3D&reserved=0

Re: Proper use of Themes and SASS

Posted by Carlos Rovira <ca...@apache.org>.

Hi Alex,

I think you didn't understand me. My main goal is create a new UI set
(Jewel) that can be easily stylizable using themes
So people can code an App and change only a theme swc to change all styles.
For that reason I always said that MDL library was very limited, since it
was "only MDL".

In this thread, I pointed to make different themes for Jewel (based in the
structure of HTML and style name or class names I will create for Jewel).
That implies that we will have our own style ( no mdl , no bootstrap,...),
but that we can as well "emulate" the styles in other well-known libraries
out there like bootstrap, semantic and, again, MDL. But for all of this, my
plan is do it with the same html/styles that Jewel will enforce. So the key
for this is emulation, an MDL button in Jewel will look mostly like a real
MDL button, but will not be a real one, since the classes used will be
"jewel button" and not "mdl-button" (like in the real lib). This implies,
out components will always work consistently since will be the same royale
component with different faces (css styles).

Then, you open my mind to ViewBeads, so we can make a jewel button have
different view beads, each one in its own library, so in this way we can
match the same html structure and styles in native libraries. I love this
idea, but then thinking about it I found some problems due to different
"particularities" in each library.

In Jewel we will end with a set of well defined properties to make the set
easy to use. If we want to go the view bead, the only way I could think to
get all the particularities of a concrete library is through beads, and
that beads should be as some kind of interface or something, but in the end
this will make people to change the app code and that's what I want to
avoid.

So I think this only let us with two options:

1) Jewel set with themes that can emulate other styles out there, a part of
our new styles
2) Go the same path as we did with MDL to create Bootstrap, Semantic, and
more.

For me the path is 1), if I'm not missing something in my approach, since
we should get our own presence a part from the rest, but as well I think
emulate others, can be of great attractive to users, that only changing a
theme can look very similar to mdl, semantic, or bootstrap.





2018-03-16 17:38 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:

> Hi Carlos,
>
> I'm not sure I'm fully understanding you.
>
> If your question is about how to create a default look for Royale, I would
> not worry about Bootstrap and MDL.  Create the HTML structures you need
> with the attributes you need and create the CSS that makes it look good.
>
> My point about Bootstrap is that if someday someone wants to support
> Bootstrap in Royale, the way to do it is to create other views that create
> exactly the HTML structure expected by Bootstrap because then you can use
> any Bootstrap theme as-is.  Same for MDL, or any other CSS-based framework.
>
> I don't think we can make one view for Button that works with Bootstrap
> and MDL.  It would be nice if we could, but I think you are pointing out
> that there are attributes in the HTML structure that are different for
> each framework.
>
> I think Bootstrap and MDL do not have the same kinds of components that we
> have in Royale (like Panel and DataGrid) so existing themes will still
> need enhancing to work for Royale components.  But the initial goal if we
> ever do try to support Bootstrap is just to create Royale components for
> the components Bootstrap does support and if you can create your app with
> only those Bootstrap components, then any Bootstrap theme should "just
> work" with it.
>
> My 2 cents.  Hopefully I am agreeing with you.
> -Alex
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Proper use of Themes and SASS

Posted by Alex Harui <ah...@adobe.com.INVALID>.

Hi Carlos,

I'm not sure I'm fully understanding you.

If your question is about how to create a default look for Royale, I would
not worry about Bootstrap and MDL.  Create the HTML structures you need
with the attributes you need and create the CSS that makes it look good.

My point about Bootstrap is that if someday someone wants to support
Bootstrap in Royale, the way to do it is to create other views that create
exactly the HTML structure expected by Bootstrap because then you can use
any Bootstrap theme as-is.  Same for MDL, or any other CSS-based framework.

I don't think we can make one view for Button that works with Bootstrap
and MDL.  It would be nice if we could, but I think you are pointing out
that there are attributes in the HTML structure that are different for
each framework.

I think Bootstrap and MDL do not have the same kinds of components that we
have in Royale (like Panel and DataGrid) so existing themes will still
need enhancing to work for Royale components.  But the initial goal if we
ever do try to support Bootstrap is just to create Royale components for
the components Bootstrap does support and if you can create your app with
only those Bootstrap components, then any Bootstrap theme should "just
work" with it.

My 2 cents.  Hopefully I am agreeing with you.
-Alex

On 3/16/18, 5:07 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:

>Hi Alex,
>
>I was thinking about use view beads with bootstrap, semantic, mdl... and I
>think is not as easy as we talked.
>
>Each ui set has its own particularities, for example, MDL has "primary"
>and
>"accent", while semantic has "primary", "secondary", and "emphasis", and
>Bootstrap has others.
>
>My plan was to have a Jewel set of properties for each component. For
>example, "primary" and "emphasized" (the last is the same in flex). Is
>something in the same way that we didi in MDL, so although I can use the
>view bead to output the html with attributes each set expects, we can't
>have each particularity of each ui set, for this reason my plan was to
>have
>our own set with our own properties and then create themes that conforms
>to
>that ui set. For components not in the Jewel UI set, we could create
>JewelBootstrap, where we could find the rest of components if we want, but
>for the controls all people use (Button, TextInput, CheckBox,...) we can't
>have properties for each case. The other way is to insert this in
>className, but that as well seems a bit like a mess, an not very "royale"
>(or "flex") style.
>
>Maybe we can use a beads to setup different particularities, but I think
>that's seems a little nightmare if I go that path.
>
>What do you think?
>
>
>2018-03-15 22:48 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> Some really low-level components like Label just thinly wrap an
>> HTMLElement.  All complex components should be creating a Div in
>> createElement and having a view bead construct the sub elements.  So, I
>> think a theme-able CheckBox that intends to support replaceable views
>> would not subclass the Basic Checkbox which creates an <input> and
>> subclass UIBase to get a div and have a bead that builds in the Label
>>and
>> Input.  I think there is already a checkbox that has a createElement
>>that
>> hard codes a div with Label and Input.  That's fine as well if you think
>> that structure never needs tweaking.
>>
>> My 2 cents,
>> -Alex
>>
>>
>> On 3/15/18, 2:30 PM, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>
>> >Thanks Piotr,
>> >
>> >I check your code and see how this works, but I have a question.
>> >If I have in the component a "createElement" like in Label, that
>>generates
>> >a <span> tag, what happens if I put an IBeadView?
>> >it overrides the createElement() to avoid create the <span> tag and
>> >creates
>> >what dictates the IBeadView?
>> >thanks
>> >
>> >2018-03-15 19:56 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
>> >
>> >> Carlos,
>> >>
>> >> In one of my example I have implemented custom TitleBar for Panel. In
>> >>order
>> >> to apply it I have used IBeadView [1]
>> >>
>> >> [1]
>> >>https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fgoo.gl%2
>> 
>>>>F3BAU9Y&data=02%7C01%7Caharui%40adobe.com%7C25b1cf8a49534632a77908d58ab
>>>>b
>> f
>> >>7fd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636567462291974066&sdata
>> >>=hPRx5U5zDYx4o7MTSVzGFMFdlUYMnkon2V1No2NKEnA%3D&reserved=0
>> >>
>> >> Thanks, Piotr
>> >>
>> >>
>> >> 2018-03-15 19:51 GMT+01:00 Carlos Rovira <ca...@apache.org>:
>> >>
>> >> > HI Alex,
>> >> >
>> >> > 2018-03-15 19:34 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>> >> >
>> >> > >
>> >> > > If you are saying you will have JewelTheme.swc that contains SVG
>>and
>> >> > > assets in one folder and then other folders with only CSS for
>> >>setting
>> >> > > colors that's fine.  If you need SVG in in the Blue theme and
>>have
>> >>to
>> >> > turn
>> >> > > it into a SWC as well, that is also fine.  The main point was to
>> >>avoid
>> >> > > having blue.css and red.css in the one JewelTheme.swc.
>> >> > >
>> >> >
>> >> > Right, that's the point now have a common theme (JewelTheme) and a
>> >>second
>> >> > derived theme for colors and other possible changes
>> >> > What is still to decide is if we should have blue, red, orange,
>> >>green,..
>> >> or
>> >> > maybe blue-red, blue-orange,...and then red-blue, red-orange,...
>> >> > and more for gradients. Maybe this is the final part on
>>"definitions"
>> >>or
>> >> > "foundations" to decide.
>> >> >
>> >> >
>> >> > > IMO, if we want to support Bootstrap, we should do it by
>> >>encapsulation
>> >> > > their HTML structures, not by trying to emulate their visuals.
>>Then
>> >> > other
>> >> > > Bootstrap themes will "just work".  Again, Royale is primarily in
>> >>the
>> >> > > business of encapsulating common patterns.  If every Bootstrap
>>user
>> >> must
>> >> > > fashion a Button out of a <div> and <label> and <input> and give
>> >>those
>> >> > > tags certain attributes so the Bootstrap CSS will take effect,
>>then
>> >>a
>> >> > > Bootstrap.swc for Royale would contain view beads that generate
>> >>those
>> >> > tags
>> >> > > with those attributes.  Another way of thinking about it is to
>>take
>> >>two
>> >> > > different Bootstrap websites, look at the HTML DOM, find the
>>common
>> >> > > patterns, and those patterns are what the view bead generates.  I
>> >> thought
>> >> > > MDL worked the same way.  We are creating our own component set
>>at
>> >> first
>> >> > > just to make debugging simple, but also to make it possible to
>>write
>> >> > > really simple HTML that isn't completely styleable and to avoid
>> >> licensing
>> >> > > issues, but now you are creating view beads that set up a
>>particular
>> >> HTML
>> >> > > so you can style it with your CSS.  If you love Bootstrap and
>>want
>> >>to
>> >> use
>> >> > > Bootstrap to get our default Royale look, that's fine with me, as
>> >>long
>> >> as
>> >> > > you can stay away from licensing issues.
>> >> > >
>> >> > >
>> >> > well, I think that's brilliant! :), I didn't think on this from
>>that
>> >> > perspective.
>> >> > So instead of emulate, we can use it's own css by using view beads.
>> >> > I think I'll give this a try to make a project to see how this will
>> >>work.
>> >> > If this is ok, we'll have the main scenario delineated and can
>>simply
>> >> start
>> >> > the work :)
>> >> >
>> >> > MDL library had the problem that is was limited to it's own
>>namespace
>> >> > I created "mdl:Button" or "mdl:TextField", and the structure in
>>html
>> >>was
>> >> > what MDL expected
>> >> > now we have our own royale way through "jewel", and we can have
>> >>different
>> >> > themes that will
>> >> > encapsulate their own view beads, this was a point of discussion
>>with
>> >> > @Piotr this morning
>> >> > in an issue thread and maybe this is a great way to exemplarize
>>what
>> >>we
>> >> can
>> >> > do with views in themes
>> >> > instead in the library
>> >> >
>> >> > btw, I never used a ViewBead, we have already docs on how to use
>>it?
>> >>or
>> >> > maybe you can point me to a class
>> >> > using a view bead.
>> >> >
>> >> > Finaly, I always think we must have our own style and that's where
>> >>more
>> >> > work will be pushed
>> >> > But I think is important to set the complete scenario so if I can
>>end
>> >>a
>> >> > Bootstrap effort, other can.
>> >> > Maybe I could go per component, setting up different themes for
>> >> > Jewel, Bootstrap, Semantic and MDL, and then
>> >> > go to the next control, and so on... but main should be ours! :)
>> >> >
>> >> > Thanks
>> >> >
>> >> >
>> >> > --
>> >> > Carlos Rovira
>> >> >
>> >>https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%
>> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
>> 7C25b1cf8a49534632a77908
>> >>d58abbf7fd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C63656746229197406
>> >>6&sdata=ShzF245nFYjOA5DWRAOza8vgRtPxbLOZQeUt0NaxuHA%3D&reserved=0
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Piotr Zarzycki
>> >>
>> >> Patreon:
>> >>*https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.pat
>> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>> %7C25b1cf8a4953
>> >>4632a77908d58abbf7fd%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C0%7C6365674
>> >>62291974066&sdata=5k%2BoEsMbBiXpy8HEA5qugWkBnR2ju5P
>> qt17wFB360Nk%3D&reserv
>> >>ed=0
>> >>
>> >><https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.pat
>> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>> %7C25b1cf8a4953
>> >>4632a77908d58abbf7fd%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C0%7C6365674
>> >>62291974066&sdata=5k%2BoEsMbBiXpy8HEA5qugWkBnR2ju5P
>> qt17wFB360Nk%3D&reserv
>> >>ed=0>*
>> >>
>> >
>> >
>> >
>> >--
>> >Carlos Rovira
>> >https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
>> 7C25b1cf8a49534632a77908d5
>> >8abbf7fd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636567462291974066&s
>> >data=ShzF245nFYjOA5DWRAOza8vgRtPxbLOZQeUt0NaxuHA%3D&reserved=0
>>
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfd992c09135f4dc6aa5008d5
>8b368e44%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636567988793544448&s
>data=S%2F9k%2FvE34bMncn8pMoBh9ywbKFwCOsS%2BsPxKBsxctDE%3D&reserved=0

Re: Proper use of Themes and SASS

Posted by Carlos Rovira <ca...@apache.org>.

Hi Alex,

I was thinking about use view beads with bootstrap, semantic, mdl... and I
think is not as easy as we talked.

Each ui set has its own particularities, for example, MDL has "primary" and
"accent", while semantic has "primary", "secondary", and "emphasis", and
Bootstrap has others.

My plan was to have a Jewel set of properties for each component. For
example, "primary" and "emphasized" (the last is the same in flex). Is
something in the same way that we didi in MDL, so although I can use the
view bead to output the html with attributes each set expects, we can't
have each particularity of each ui set, for this reason my plan was to have
our own set with our own properties and then create themes that conforms to
that ui set. For components not in the Jewel UI set, we could create
JewelBootstrap, where we could find the rest of components if we want, but
for the controls all people use (Button, TextInput, CheckBox,...) we can't
have properties for each case. The other way is to insert this in
className, but that as well seems a bit like a mess, an not very "royale"
(or "flex") style.

Maybe we can use a beads to setup different particularities, but I think
that's seems a little nightmare if I go that path.

What do you think?


2018-03-15 22:48 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:

> Some really low-level components like Label just thinly wrap an
> HTMLElement.  All complex components should be creating a Div in
> createElement and having a view bead construct the sub elements.  So, I
> think a theme-able CheckBox that intends to support replaceable views
> would not subclass the Basic Checkbox which creates an <input> and
> subclass UIBase to get a div and have a bead that builds in the Label and
> Input.  I think there is already a checkbox that has a createElement that
> hard codes a div with Label and Input.  That's fine as well if you think
> that structure never needs tweaking.
>
> My 2 cents,
> -Alex
>
>
> On 3/15/18, 2:30 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Thanks Piotr,
> >
> >I check your code and see how this works, but I have a question.
> >If I have in the component a "createElement" like in Label, that generates
> >a <span> tag, what happens if I put an IBeadView?
> >it overrides the createElement() to avoid create the <span> tag and
> >creates
> >what dictates the IBeadView?
> >thanks
> >
> >2018-03-15 19:56 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
> >
> >> Carlos,
> >>
> >> In one of my example I have implemented custom TitleBar for Panel. In
> >>order
> >> to apply it I have used IBeadView [1]
> >>
> >> [1]
> >>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgoo.gl%2
> >>F3BAU9Y&data=02%7C01%7Caharui%40adobe.com%7C25b1cf8a49534632a77908d58abb
> f
> >>7fd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636567462291974066&sdata
> >>=hPRx5U5zDYx4o7MTSVzGFMFdlUYMnkon2V1No2NKEnA%3D&reserved=0
> >>
> >> Thanks, Piotr
> >>
> >>
> >> 2018-03-15 19:51 GMT+01:00 Carlos Rovira <ca...@apache.org>:
> >>
> >> > HI Alex,
> >> >
> >> > 2018-03-15 19:34 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >> >
> >> > >
> >> > > If you are saying you will have JewelTheme.swc that contains SVG and
> >> > > assets in one folder and then other folders with only CSS for
> >>setting
> >> > > colors that's fine.  If you need SVG in in the Blue theme and have
> >>to
> >> > turn
> >> > > it into a SWC as well, that is also fine.  The main point was to
> >>avoid
> >> > > having blue.css and red.css in the one JewelTheme.swc.
> >> > >
> >> >
> >> > Right, that's the point now have a common theme (JewelTheme) and a
> >>second
> >> > derived theme for colors and other possible changes
> >> > What is still to decide is if we should have blue, red, orange,
> >>green,..
> >> or
> >> > maybe blue-red, blue-orange,...and then red-blue, red-orange,...
> >> > and more for gradients. Maybe this is the final part on "definitions"
> >>or
> >> > "foundations" to decide.
> >> >
> >> >
> >> > > IMO, if we want to support Bootstrap, we should do it by
> >>encapsulation
> >> > > their HTML structures, not by trying to emulate their visuals.  Then
> >> > other
> >> > > Bootstrap themes will "just work".  Again, Royale is primarily in
> >>the
> >> > > business of encapsulating common patterns.  If every Bootstrap user
> >> must
> >> > > fashion a Button out of a <div> and <label> and <input> and give
> >>those
> >> > > tags certain attributes so the Bootstrap CSS will take effect, then
> >>a
> >> > > Bootstrap.swc for Royale would contain view beads that generate
> >>those
> >> > tags
> >> > > with those attributes.  Another way of thinking about it is to take
> >>two
> >> > > different Bootstrap websites, look at the HTML DOM, find the common
> >> > > patterns, and those patterns are what the view bead generates.  I
> >> thought
> >> > > MDL worked the same way.  We are creating our own component set at
> >> first
> >> > > just to make debugging simple, but also to make it possible to write
> >> > > really simple HTML that isn't completely styleable and to avoid
> >> licensing
> >> > > issues, but now you are creating view beads that set up a particular
> >> HTML
> >> > > so you can style it with your CSS.  If you love Bootstrap and want
> >>to
> >> use
> >> > > Bootstrap to get our default Royale look, that's fine with me, as
> >>long
> >> as
> >> > > you can stay away from licensing issues.
> >> > >
> >> > >
> >> > well, I think that's brilliant! :), I didn't think on this from that
> >> > perspective.
> >> > So instead of emulate, we can use it's own css by using view beads.
> >> > I think I'll give this a try to make a project to see how this will
> >>work.
> >> > If this is ok, we'll have the main scenario delineated and can simply
> >> start
> >> > the work :)
> >> >
> >> > MDL library had the problem that is was limited to it's own namespace
> >> > I created "mdl:Button" or "mdl:TextField", and the structure in html
> >>was
> >> > what MDL expected
> >> > now we have our own royale way through "jewel", and we can have
> >>different
> >> > themes that will
> >> > encapsulate their own view beads, this was a point of discussion with
> >> > @Piotr this morning
> >> > in an issue thread and maybe this is a great way to exemplarize what
> >>we
> >> can
> >> > do with views in themes
> >> > instead in the library
> >> >
> >> > btw, I never used a ViewBead, we have already docs on how to use it?
> >>or
> >> > maybe you can point me to a class
> >> > using a view bead.
> >> >
> >> > Finaly, I always think we must have our own style and that's where
> >>more
> >> > work will be pushed
> >> > But I think is important to set the complete scenario so if I can end
> >>a
> >> > Bootstrap effort, other can.
> >> > Maybe I could go per component, setting up different themes for
> >> > Jewel, Bootstrap, Semantic and MDL, and then
> >> > go to the next control, and so on... but main should be ours! :)
> >> >
> >> > Thanks
> >> >
> >> >
> >> > --
> >> > Carlos Rovira
> >> >
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%
> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C25b1cf8a49534632a77908
> >>d58abbf7fd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C63656746229197406
> >>6&sdata=ShzF245nFYjOA5DWRAOza8vgRtPxbLOZQeUt0NaxuHA%3D&reserved=0
> >> >
> >>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon:
> >>*https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.pat
> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
> %7C25b1cf8a4953
> >>4632a77908d58abbf7fd%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6365674
> >>62291974066&sdata=5k%2BoEsMbBiXpy8HEA5qugWkBnR2ju5P
> qt17wFB360Nk%3D&reserv
> >>ed=0
> >>
> >><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.pat
> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
> %7C25b1cf8a4953
> >>4632a77908d58abbf7fd%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6365674
> >>62291974066&sdata=5k%2BoEsMbBiXpy8HEA5qugWkBnR2ju5P
> qt17wFB360Nk%3D&reserv
> >>ed=0>*
> >>
> >
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C25b1cf8a49534632a77908d5
> >8abbf7fd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636567462291974066&s
> >data=ShzF245nFYjOA5DWRAOza8vgRtPxbLOZQeUt0NaxuHA%3D&reserved=0
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Proper use of Themes and SASS

Posted by Alex Harui <ah...@adobe.com.INVALID>.

Some really low-level components like Label just thinly wrap an
HTMLElement.  All complex components should be creating a Div in
createElement and having a view bead construct the sub elements.  So, I
think a theme-able CheckBox that intends to support replaceable views
would not subclass the Basic Checkbox which creates an <input> and
subclass UIBase to get a div and have a bead that builds in the Label and
Input.  I think there is already a checkbox that has a createElement that
hard codes a div with Label and Input.  That's fine as well if you think
that structure never needs tweaking.

My 2 cents,
-Alex


On 3/15/18, 2:30 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:

>Thanks Piotr,
>
>I check your code and see how this works, but I have a question.
>If I have in the component a "createElement" like in Label, that generates
>a <span> tag, what happens if I put an IBeadView?
>it overrides the createElement() to avoid create the <span> tag and
>creates
>what dictates the IBeadView?
>thanks
>
>2018-03-15 19:56 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
>
>> Carlos,
>>
>> In one of my example I have implemented custom TitleBar for Panel. In
>>order
>> to apply it I have used IBeadView [1]
>>
>> [1]  
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgoo.gl%2
>>F3BAU9Y&data=02%7C01%7Caharui%40adobe.com%7C25b1cf8a49534632a77908d58abbf
>>7fd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636567462291974066&sdata
>>=hPRx5U5zDYx4o7MTSVzGFMFdlUYMnkon2V1No2NKEnA%3D&reserved=0
>>
>> Thanks, Piotr
>>
>>
>> 2018-03-15 19:51 GMT+01:00 Carlos Rovira <ca...@apache.org>:
>>
>> > HI Alex,
>> >
>> > 2018-03-15 19:34 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>> >
>> > >
>> > > If you are saying you will have JewelTheme.swc that contains SVG and
>> > > assets in one folder and then other folders with only CSS for
>>setting
>> > > colors that's fine.  If you need SVG in in the Blue theme and have
>>to
>> > turn
>> > > it into a SWC as well, that is also fine.  The main point was to
>>avoid
>> > > having blue.css and red.css in the one JewelTheme.swc.
>> > >
>> >
>> > Right, that's the point now have a common theme (JewelTheme) and a
>>second
>> > derived theme for colors and other possible changes
>> > What is still to decide is if we should have blue, red, orange,
>>green,..
>> or
>> > maybe blue-red, blue-orange,...and then red-blue, red-orange,...
>> > and more for gradients. Maybe this is the final part on "definitions"
>>or
>> > "foundations" to decide.
>> >
>> >
>> > > IMO, if we want to support Bootstrap, we should do it by
>>encapsulation
>> > > their HTML structures, not by trying to emulate their visuals.  Then
>> > other
>> > > Bootstrap themes will "just work".  Again, Royale is primarily in
>>the
>> > > business of encapsulating common patterns.  If every Bootstrap user
>> must
>> > > fashion a Button out of a <div> and <label> and <input> and give
>>those
>> > > tags certain attributes so the Bootstrap CSS will take effect, then
>>a
>> > > Bootstrap.swc for Royale would contain view beads that generate
>>those
>> > tags
>> > > with those attributes.  Another way of thinking about it is to take
>>two
>> > > different Bootstrap websites, look at the HTML DOM, find the common
>> > > patterns, and those patterns are what the view bead generates.  I
>> thought
>> > > MDL worked the same way.  We are creating our own component set at
>> first
>> > > just to make debugging simple, but also to make it possible to write
>> > > really simple HTML that isn't completely styleable and to avoid
>> licensing
>> > > issues, but now you are creating view beads that set up a particular
>> HTML
>> > > so you can style it with your CSS.  If you love Bootstrap and want
>>to
>> use
>> > > Bootstrap to get our default Royale look, that's fine with me, as
>>long
>> as
>> > > you can stay away from licensing issues.
>> > >
>> > >
>> > well, I think that's brilliant! :), I didn't think on this from that
>> > perspective.
>> > So instead of emulate, we can use it's own css by using view beads.
>> > I think I'll give this a try to make a project to see how this will
>>work.
>> > If this is ok, we'll have the main scenario delineated and can simply
>> start
>> > the work :)
>> >
>> > MDL library had the problem that is was limited to it's own namespace
>> > I created "mdl:Button" or "mdl:TextField", and the structure in html
>>was
>> > what MDL expected
>> > now we have our own royale way through "jewel", and we can have
>>different
>> > themes that will
>> > encapsulate their own view beads, this was a point of discussion with
>> > @Piotr this morning
>> > in an issue thread and maybe this is a great way to exemplarize what
>>we
>> can
>> > do with views in themes
>> > instead in the library
>> >
>> > btw, I never used a ViewBead, we have already docs on how to use it?
>>or
>> > maybe you can point me to a class
>> > using a view bead.
>> >
>> > Finaly, I always think we must have our own style and that's where
>>more
>> > work will be pushed
>> > But I think is important to set the complete scenario so if I can end
>>a
>> > Bootstrap effort, other can.
>> > Maybe I could go per component, setting up different themes for
>> > Jewel, Bootstrap, Semantic and MDL, and then
>> > go to the next control, and so on... but main should be ours! :)
>> >
>> > Thanks
>> >
>> >
>> > --
>> > Carlos Rovira
>> > 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C25b1cf8a49534632a77908
>>d58abbf7fd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63656746229197406
>>6&sdata=ShzF245nFYjOA5DWRAOza8vgRtPxbLOZQeUt0NaxuHA%3D&reserved=0
>> >
>>
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>> Patreon: 
>>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat
>>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C25b1cf8a4953
>>4632a77908d58abbf7fd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365674
>>62291974066&sdata=5k%2BoEsMbBiXpy8HEA5qugWkBnR2ju5Pqt17wFB360Nk%3D&reserv
>>ed=0
>> 
>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat
>>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C25b1cf8a4953
>>4632a77908d58abbf7fd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365674
>>62291974066&sdata=5k%2BoEsMbBiXpy8HEA5qugWkBnR2ju5Pqt17wFB360Nk%3D&reserv
>>ed=0>*
>>
>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C25b1cf8a49534632a77908d5
>8abbf7fd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636567462291974066&s
>data=ShzF245nFYjOA5DWRAOza8vgRtPxbLOZQeUt0NaxuHA%3D&reserved=0

Re: Proper use of Themes and SASS

Posted by Carlos Rovira <ca...@apache.org>.

Thanks Piotr,

I check your code and see how this works, but I have a question.
If I have in the component a "createElement" like in Label, that generates
a <span> tag, what happens if I put an IBeadView?
it overrides the createElement() to avoid create the <span> tag and creates
what dictates the IBeadView?
thanks

2018-03-15 19:56 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:

> Carlos,
>
> In one of my example I have implemented custom TitleBar for Panel. In order
> to apply it I have used IBeadView [1]
>
> [1]  https://goo.gl/3BAU9Y
>
> Thanks, Piotr
>
>
> 2018-03-15 19:51 GMT+01:00 Carlos Rovira <ca...@apache.org>:
>
> > HI Alex,
> >
> > 2018-03-15 19:34 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >
> > >
> > > If you are saying you will have JewelTheme.swc that contains SVG and
> > > assets in one folder and then other folders with only CSS for setting
> > > colors that's fine.  If you need SVG in in the Blue theme and have to
> > turn
> > > it into a SWC as well, that is also fine.  The main point was to avoid
> > > having blue.css and red.css in the one JewelTheme.swc.
> > >
> >
> > Right, that's the point now have a common theme (JewelTheme) and a second
> > derived theme for colors and other possible changes
> > What is still to decide is if we should have blue, red, orange, green,..
> or
> > maybe blue-red, blue-orange,...and then red-blue, red-orange,...
> > and more for gradients. Maybe this is the final part on "definitions" or
> > "foundations" to decide.
> >
> >
> > > IMO, if we want to support Bootstrap, we should do it by encapsulation
> > > their HTML structures, not by trying to emulate their visuals.  Then
> > other
> > > Bootstrap themes will "just work".  Again, Royale is primarily in the
> > > business of encapsulating common patterns.  If every Bootstrap user
> must
> > > fashion a Button out of a <div> and <label> and <input> and give those
> > > tags certain attributes so the Bootstrap CSS will take effect, then a
> > > Bootstrap.swc for Royale would contain view beads that generate those
> > tags
> > > with those attributes.  Another way of thinking about it is to take two
> > > different Bootstrap websites, look at the HTML DOM, find the common
> > > patterns, and those patterns are what the view bead generates.  I
> thought
> > > MDL worked the same way.  We are creating our own component set at
> first
> > > just to make debugging simple, but also to make it possible to write
> > > really simple HTML that isn't completely styleable and to avoid
> licensing
> > > issues, but now you are creating view beads that set up a particular
> HTML
> > > so you can style it with your CSS.  If you love Bootstrap and want to
> use
> > > Bootstrap to get our default Royale look, that's fine with me, as long
> as
> > > you can stay away from licensing issues.
> > >
> > >
> > well, I think that's brilliant! :), I didn't think on this from that
> > perspective.
> > So instead of emulate, we can use it's own css by using view beads.
> > I think I'll give this a try to make a project to see how this will work.
> > If this is ok, we'll have the main scenario delineated and can simply
> start
> > the work :)
> >
> > MDL library had the problem that is was limited to it's own namespace
> > I created "mdl:Button" or "mdl:TextField", and the structure in html was
> > what MDL expected
> > now we have our own royale way through "jewel", and we can have different
> > themes that will
> > encapsulate their own view beads, this was a point of discussion with
> > @Piotr this morning
> > in an issue thread and maybe this is a great way to exemplarize what we
> can
> > do with views in themes
> > instead in the library
> >
> > btw, I never used a ViewBead, we have already docs on how to use it? or
> > maybe you can point me to a class
> > using a view bead.
> >
> > Finaly, I always think we must have our own style and that's where more
> > work will be pushed
> > But I think is important to set the complete scenario so if I can end a
> > Bootstrap effort, other can.
> > Maybe I could go per component, setting up different themes for
> > Jewel, Bootstrap, Semantic and MDL, and then
> > go to the next control, and so on... but main should be ours! :)
> >
> > Thanks
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Proper use of Themes and SASS

Posted by Piotr Zarzycki <pi...@gmail.com>.

Carlos,

In one of my example I have implemented custom TitleBar for Panel. In order
to apply it I have used IBeadView [1]

[1]  https://goo.gl/3BAU9Y

Thanks, Piotr


2018-03-15 19:51 GMT+01:00 Carlos Rovira <ca...@apache.org>:

> HI Alex,
>
> 2018-03-15 19:34 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
> >
> > If you are saying you will have JewelTheme.swc that contains SVG and
> > assets in one folder and then other folders with only CSS for setting
> > colors that's fine.  If you need SVG in in the Blue theme and have to
> turn
> > it into a SWC as well, that is also fine.  The main point was to avoid
> > having blue.css and red.css in the one JewelTheme.swc.
> >
>
> Right, that's the point now have a common theme (JewelTheme) and a second
> derived theme for colors and other possible changes
> What is still to decide is if we should have blue, red, orange, green,.. or
> maybe blue-red, blue-orange,...and then red-blue, red-orange,...
> and more for gradients. Maybe this is the final part on "definitions" or
> "foundations" to decide.
>
>
> > IMO, if we want to support Bootstrap, we should do it by encapsulation
> > their HTML structures, not by trying to emulate their visuals.  Then
> other
> > Bootstrap themes will "just work".  Again, Royale is primarily in the
> > business of encapsulating common patterns.  If every Bootstrap user must
> > fashion a Button out of a <div> and <label> and <input> and give those
> > tags certain attributes so the Bootstrap CSS will take effect, then a
> > Bootstrap.swc for Royale would contain view beads that generate those
> tags
> > with those attributes.  Another way of thinking about it is to take two
> > different Bootstrap websites, look at the HTML DOM, find the common
> > patterns, and those patterns are what the view bead generates.  I thought
> > MDL worked the same way.  We are creating our own component set at first
> > just to make debugging simple, but also to make it possible to write
> > really simple HTML that isn't completely styleable and to avoid licensing
> > issues, but now you are creating view beads that set up a particular HTML
> > so you can style it with your CSS.  If you love Bootstrap and want to use
> > Bootstrap to get our default Royale look, that's fine with me, as long as
> > you can stay away from licensing issues.
> >
> >
> well, I think that's brilliant! :), I didn't think on this from that
> perspective.
> So instead of emulate, we can use it's own css by using view beads.
> I think I'll give this a try to make a project to see how this will work.
> If this is ok, we'll have the main scenario delineated and can simply start
> the work :)
>
> MDL library had the problem that is was limited to it's own namespace
> I created "mdl:Button" or "mdl:TextField", and the structure in html was
> what MDL expected
> now we have our own royale way through "jewel", and we can have different
> themes that will
> encapsulate their own view beads, this was a point of discussion with
> @Piotr this morning
> in an issue thread and maybe this is a great way to exemplarize what we can
> do with views in themes
> instead in the library
>
> btw, I never used a ViewBead, we have already docs on how to use it? or
> maybe you can point me to a class
> using a view bead.
>
> Finaly, I always think we must have our own style and that's where more
> work will be pushed
> But I think is important to set the complete scenario so if I can end a
> Bootstrap effort, other can.
> Maybe I could go per component, setting up different themes for
> Jewel, Bootstrap, Semantic and MDL, and then
> go to the next control, and so on... but main should be ours! :)
>
> Thanks
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Re: Proper use of Themes and SASS

Posted by Alex Harui <ah...@adobe.com.INVALID>.


On 3/15/18, 1:57 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:

>2018-03-15 20:20 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> Sounds like we are mostly in agreement.  A couple of thoughts:
>>
>> 1) Using Bootstrap CSS as-is should work on JS but won't work on SWF
>>since
>> we don’t yet have support in SWF code for all of the fancy CSS in
>> Bootstrap.  But I wouldn't let that stop us from making this work on JS.
>>
>
>I'd like to focus as well on SWF, but I think there's so much work in that
>part
>Don't know...I would like to maintain structure and as well try to see if
>we can have
>SWF, but I don't want to promise anything at this moment. When I started
>with
>SVG and see the problems for SVG in SWF, I renounce to the SWF part. Now
>that
>I'm mostly on CSS3, I could check again if is possible without having more
>headaches
>For Bootstrap, Semantic and MDL, I think will not be possible without more
>people
>working on it.

To support SWF, an AdvancedCSSValuesImpl needs to be written that handles
all of the CSS that Bootstrap uses.  That's still not a full CSS
implementation, so it might be doable, but really for SWF support we only
need to get the boxes in the right places so the implementation doesn't
have to be perfect.
>
>
>>
>> 2) I'm undecided on where the viewbead goes.  Maybe it doesn't matter.
>> IMO there should be a component SWC in frameworks/libs and
>> frameworks/js/libs with classes that represent the top-level components
>> and with a defaults.css that dictates the beads so the beads would go in
>> the component SWC.  And then styling-specific classes, assets and CSS go
>> in Theme SWCs.  IOW, Bootstrap is not a Theme in Royale, it is a
>>component
>> set.  Just like we have a Basic component SWC and then a Basic.css
>>theme.
>> Then Bootstrap themes like Flat would go in a Theme as a .css file or a
>> .swc if it is more than just a .css file.  If a viewbead is required to
>> get a specific look for a specific theme, then it can go in a theme swc.
>> But if all themes need the same view bead (the same HTML structure) then
>> that should go in a component SWC.
>>
>
>IMO, that will confuse people. If we make views to be in themes, people
>will take this
>as a best practice, and will follow. But anyone can do what they want.
>People could make
>a library and have css colors in it, and then override in a theme, and
>that's not wrong
>But, I'll try to make views in themes if I can for methodology and
>separation of concerns.
>Even if a view in MDL coincides with a view in Bootstrap, I think the
>right
>option is to have
>both in both themes. At least in our official themes. Then people can do,
>and I'm sure they'll do
>what they think better for their concrete use cases.

Duplication is bad too.  It might be that we have a component set called
CSSThemableComponents that has views that set the structure that MDL and
Bootstrap want if they are in fact the same down to EVERY attribute.  I
think that MDL and Bootstrap will use different class names on the
elements.  Even the Flat theme for Bootstrap might use different class
names on the elements.  Not sure.  I guess you'll find out when you try to
make it work and then we can discuss how to organize what is being shared.

First things, first.  See if you can get Bootstrap to work as-is on JS in
Royale.

Good luck,
-Alex

Re: Proper use of Themes and SASS

Posted by Carlos Rovira <ca...@apache.org>.

2018-03-15 20:20 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:

> Sounds like we are mostly in agreement.  A couple of thoughts:
>
> 1) Using Bootstrap CSS as-is should work on JS but won't work on SWF since
> we don’t yet have support in SWF code for all of the fancy CSS in
> Bootstrap.  But I wouldn't let that stop us from making this work on JS.
>

I'd like to focus as well on SWF, but I think there's so much work in that
part
Don't know...I would like to maintain structure and as well try to see if
we can have
SWF, but I don't want to promise anything at this moment. When I started
with
SVG and see the problems for SVG in SWF, I renounce to the SWF part. Now
that
I'm mostly on CSS3, I could check again if is possible without having more
headaches
For Bootstrap, Semantic and MDL, I think will not be possible without more
people
working on it.


>
> 2) I'm undecided on where the viewbead goes.  Maybe it doesn't matter.
> IMO there should be a component SWC in frameworks/libs and
> frameworks/js/libs with classes that represent the top-level components
> and with a defaults.css that dictates the beads so the beads would go in
> the component SWC.  And then styling-specific classes, assets and CSS go
> in Theme SWCs.  IOW, Bootstrap is not a Theme in Royale, it is a component
> set.  Just like we have a Basic component SWC and then a Basic.css theme.
> Then Bootstrap themes like Flat would go in a Theme as a .css file or a
> .swc if it is more than just a .css file.  If a viewbead is required to
> get a specific look for a specific theme, then it can go in a theme swc.
> But if all themes need the same view bead (the same HTML structure) then
> that should go in a component SWC.
>

IMO, that will confuse people. If we make views to be in themes, people
will take this
as a best practice, and will follow. But anyone can do what they want.
People could make
a library and have css colors in it, and then override in a theme, and
that's not wrong
But, I'll try to make views in themes if I can for methodology and
separation of concerns.
Even if a view in MDL coincides with a view in Bootstrap, I think the right
option is to have
both in both themes. At least in our official themes. Then people can do,
and I'm sure they'll do
what they think better for their concrete use cases.

thanks

Carlos


>
> My 2 cents,
> -Alex
>
>
> On 3/15/18, 11:51 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >HI Alex,
> >
> >2018-03-15 19:34 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >
> >>
> >> If you are saying you will have JewelTheme.swc that contains SVG and
> >> assets in one folder and then other folders with only CSS for setting
> >> colors that's fine.  If you need SVG in in the Blue theme and have to
> >>turn
> >> it into a SWC as well, that is also fine.  The main point was to avoid
> >> having blue.css and red.css in the one JewelTheme.swc.
> >>
> >
> >Right, that's the point now have a common theme (JewelTheme) and a second
> >derived theme for colors and other possible changes
> >What is still to decide is if we should have blue, red, orange, green,..
> >or
> >maybe blue-red, blue-orange,...and then red-blue, red-orange,...
> >and more for gradients. Maybe this is the final part on "definitions" or
> >"foundations" to decide.
> >
> >
> >> IMO, if we want to support Bootstrap, we should do it by encapsulation
> >> their HTML structures, not by trying to emulate their visuals.  Then
> >>other
> >> Bootstrap themes will "just work".  Again, Royale is primarily in the
> >> business of encapsulating common patterns.  If every Bootstrap user must
> >> fashion a Button out of a <div> and <label> and <input> and give those
> >> tags certain attributes so the Bootstrap CSS will take effect, then a
> >> Bootstrap.swc for Royale would contain view beads that generate those
> >>tags
> >> with those attributes.  Another way of thinking about it is to take two
> >> different Bootstrap websites, look at the HTML DOM, find the common
> >> patterns, and those patterns are what the view bead generates.  I
> >>thought
> >> MDL worked the same way.  We are creating our own component set at first
> >> just to make debugging simple, but also to make it possible to write
> >> really simple HTML that isn't completely styleable and to avoid
> >>licensing
> >> issues, but now you are creating view beads that set up a particular
> >>HTML
> >> so you can style it with your CSS.  If you love Bootstrap and want to
> >>use
> >> Bootstrap to get our default Royale look, that's fine with me, as long
> >>as
> >> you can stay away from licensing issues.
> >>
> >>
> >well, I think that's brilliant! :), I didn't think on this from that
> >perspective.
> >So instead of emulate, we can use it's own css by using view beads.
> >I think I'll give this a try to make a project to see how this will work.
> >If this is ok, we'll have the main scenario delineated and can simply
> >start
> >the work :)
> >
> >MDL library had the problem that is was limited to it's own namespace
> >I created "mdl:Button" or "mdl:TextField", and the structure in html was
> >what MDL expected
> >now we have our own royale way through "jewel", and we can have different
> >themes that will
> >encapsulate their own view beads, this was a point of discussion with
> >@Piotr this morning
> >in an issue thread and maybe this is a great way to exemplarize what we
> >can
> >do with views in themes
> >instead in the library
> >
> >btw, I never used a ViewBead, we have already docs on how to use it? or
> >maybe you can point me to a class
> >using a view bead.
> >
> >Finaly, I always think we must have our own style and that's where more
> >work will be pushed
> >But I think is important to set the complete scenario so if I can end a
> >Bootstrap effort, other can.
> >Maybe I could go per component, setting up different themes for
> >Jewel, Bootstrap, Semantic and MDL, and then
> >go to the next control, and so on... but main should be ours! :)
> >
> >Thanks
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C6a1a27dd2b904fa0473908d5
> >8aa5d77b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636567367251534018&s
> >data=KKb%2BtzbEmTVJ4l8A4Q%2FZYOlslPcZH5i11KQD2AsoJ2k%3D&reserved=0
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Proper use of Themes and SASS

Posted by Alex Harui <ah...@adobe.com.INVALID>.

Sounds like we are mostly in agreement.  A couple of thoughts:

1) Using Bootstrap CSS as-is should work on JS but won't work on SWF since
we don’t yet have support in SWF code for all of the fancy CSS in
Bootstrap.  But I wouldn't let that stop us from making this work on JS.

2) I'm undecided on where the viewbead goes.  Maybe it doesn't matter.
IMO there should be a component SWC in frameworks/libs and
frameworks/js/libs with classes that represent the top-level components
and with a defaults.css that dictates the beads so the beads would go in
the component SWC.  And then styling-specific classes, assets and CSS go
in Theme SWCs.  IOW, Bootstrap is not a Theme in Royale, it is a component
set.  Just like we have a Basic component SWC and then a Basic.css theme.
Then Bootstrap themes like Flat would go in a Theme as a .css file or a
.swc if it is more than just a .css file.  If a viewbead is required to
get a specific look for a specific theme, then it can go in a theme swc.
But if all themes need the same view bead (the same HTML structure) then
that should go in a component SWC.

My 2 cents,
-Alex


On 3/15/18, 11:51 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:

>HI Alex,
>
>2018-03-15 19:34 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
>>
>> If you are saying you will have JewelTheme.swc that contains SVG and
>> assets in one folder and then other folders with only CSS for setting
>> colors that's fine.  If you need SVG in in the Blue theme and have to
>>turn
>> it into a SWC as well, that is also fine.  The main point was to avoid
>> having blue.css and red.css in the one JewelTheme.swc.
>>
>
>Right, that's the point now have a common theme (JewelTheme) and a second
>derived theme for colors and other possible changes
>What is still to decide is if we should have blue, red, orange, green,..
>or
>maybe blue-red, blue-orange,...and then red-blue, red-orange,...
>and more for gradients. Maybe this is the final part on "definitions" or
>"foundations" to decide.
>
>
>> IMO, if we want to support Bootstrap, we should do it by encapsulation
>> their HTML structures, not by trying to emulate their visuals.  Then
>>other
>> Bootstrap themes will "just work".  Again, Royale is primarily in the
>> business of encapsulating common patterns.  If every Bootstrap user must
>> fashion a Button out of a <div> and <label> and <input> and give those
>> tags certain attributes so the Bootstrap CSS will take effect, then a
>> Bootstrap.swc for Royale would contain view beads that generate those
>>tags
>> with those attributes.  Another way of thinking about it is to take two
>> different Bootstrap websites, look at the HTML DOM, find the common
>> patterns, and those patterns are what the view bead generates.  I
>>thought
>> MDL worked the same way.  We are creating our own component set at first
>> just to make debugging simple, but also to make it possible to write
>> really simple HTML that isn't completely styleable and to avoid
>>licensing
>> issues, but now you are creating view beads that set up a particular
>>HTML
>> so you can style it with your CSS.  If you love Bootstrap and want to
>>use
>> Bootstrap to get our default Royale look, that's fine with me, as long
>>as
>> you can stay away from licensing issues.
>>
>>
>well, I think that's brilliant! :), I didn't think on this from that
>perspective.
>So instead of emulate, we can use it's own css by using view beads.
>I think I'll give this a try to make a project to see how this will work.
>If this is ok, we'll have the main scenario delineated and can simply
>start
>the work :)
>
>MDL library had the problem that is was limited to it's own namespace
>I created "mdl:Button" or "mdl:TextField", and the structure in html was
>what MDL expected
>now we have our own royale way through "jewel", and we can have different
>themes that will
>encapsulate their own view beads, this was a point of discussion with
>@Piotr this morning
>in an issue thread and maybe this is a great way to exemplarize what we
>can
>do with views in themes
>instead in the library
>
>btw, I never used a ViewBead, we have already docs on how to use it? or
>maybe you can point me to a class
>using a view bead.
>
>Finaly, I always think we must have our own style and that's where more
>work will be pushed
>But I think is important to set the complete scenario so if I can end a
>Bootstrap effort, other can.
>Maybe I could go per component, setting up different themes for
>Jewel, Bootstrap, Semantic and MDL, and then
>go to the next control, and so on... but main should be ours! :)
>
>Thanks
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6a1a27dd2b904fa0473908d5
>8aa5d77b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636567367251534018&s
>data=KKb%2BtzbEmTVJ4l8A4Q%2FZYOlslPcZH5i11KQD2AsoJ2k%3D&reserved=0

Re: Proper use of Themes and SASS

Posted by Carlos Rovira <ca...@apache.org>.

HI Alex,

2018-03-15 19:34 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:

>
> If you are saying you will have JewelTheme.swc that contains SVG and
> assets in one folder and then other folders with only CSS for setting
> colors that's fine.  If you need SVG in in the Blue theme and have to turn
> it into a SWC as well, that is also fine.  The main point was to avoid
> having blue.css and red.css in the one JewelTheme.swc.
>

Right, that's the point now have a common theme (JewelTheme) and a second
derived theme for colors and other possible changes
What is still to decide is if we should have blue, red, orange, green,.. or
maybe blue-red, blue-orange,...and then red-blue, red-orange,...
and more for gradients. Maybe this is the final part on "definitions" or
"foundations" to decide.


> IMO, if we want to support Bootstrap, we should do it by encapsulation
> their HTML structures, not by trying to emulate their visuals.  Then other
> Bootstrap themes will "just work".  Again, Royale is primarily in the
> business of encapsulating common patterns.  If every Bootstrap user must
> fashion a Button out of a <div> and <label> and <input> and give those
> tags certain attributes so the Bootstrap CSS will take effect, then a
> Bootstrap.swc for Royale would contain view beads that generate those tags
> with those attributes.  Another way of thinking about it is to take two
> different Bootstrap websites, look at the HTML DOM, find the common
> patterns, and those patterns are what the view bead generates.  I thought
> MDL worked the same way.  We are creating our own component set at first
> just to make debugging simple, but also to make it possible to write
> really simple HTML that isn't completely styleable and to avoid licensing
> issues, but now you are creating view beads that set up a particular HTML
> so you can style it with your CSS.  If you love Bootstrap and want to use
> Bootstrap to get our default Royale look, that's fine with me, as long as
> you can stay away from licensing issues.
>
>
well, I think that's brilliant! :), I didn't think on this from that
perspective.
So instead of emulate, we can use it's own css by using view beads.
I think I'll give this a try to make a project to see how this will work.
If this is ok, we'll have the main scenario delineated and can simply start
the work :)

MDL library had the problem that is was limited to it's own namespace
I created "mdl:Button" or "mdl:TextField", and the structure in html was
what MDL expected
now we have our own royale way through "jewel", and we can have different
themes that will
encapsulate their own view beads, this was a point of discussion with
@Piotr this morning
in an issue thread and maybe this is a great way to exemplarize what we can
do with views in themes
instead in the library

btw, I never used a ViewBead, we have already docs on how to use it? or
maybe you can point me to a class
using a view bead.

Finaly, I always think we must have our own style and that's where more
work will be pushed
But I think is important to set the complete scenario so if I can end a
Bootstrap effort, other can.
Maybe I could go per component, setting up different themes for
Jewel, Bootstrap, Semantic and MDL, and then
go to the next control, and so on... but main should be ours! :)

Thanks


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Proper use of Themes and SASS

Posted by Alex Harui <ah...@adobe.com.INVALID>.

Hi Carlos, I cut out portions where we have agreement and am responding to
others inline.

On 3/15/18, 10:06 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:

>HI Alex,
>
>2018-03-15 17:44 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
>>I am hopeful I have explained the issues well enough that you can go
>> refactor JewelTheme into multiple folders and get it all working in
>>Maven.
>>  I just found this article [1] about using install-file to install
>> single-file artifacts.  Don't know about deploying single-file artifacts
>> though.  Maybe this will help [2].  So I would like to have you do the
>> refactoring.  Once you do that, and also adjust JewelTheme to build both
>> SWF and JSRoyale targets, your ClassReference issue should go away.
>>
>
>I think as I have the projects setup and running that's ok as well. I need
>to remove now common things from blue
>and keep only con the common theme. But I think Jewel is not a
>single-file,
>at least in development, although it generates one .css
>so I think is ok for now, at least you think it's not. let me know. for me
>is ok in the actual state (just committed few moments ago)

If you are saying you will have JewelTheme.swc that contains SVG and
assets in one folder and then other folders with only CSS for setting
colors that's fine.  If you need SVG in in the Blue theme and have to turn
it into a SWC as well, that is also fine.  The main point was to avoid
having blue.css and red.css in the one JewelTheme.swc.
>
>>
>> Regarding supporting other things like Bootstrap, if the sub-trees in
>>the
>> components for Jewel are the same as the ones in Bootstrap, then
>>Bootstrap
>> should "just work".  Ideally, Bootstrap support isn't critical to Royale
>> and we would get noticed for other successes and Bootstrap fans would do
>> the work of getting Royale to work with Bootstrap.
>>
>
>Maybe this can be confusing, by supporting I mean creating a theme that
>"emulates" those well-known styles
>but I can guarantee that we can't use the styles in those projects
>directly
>(although if we can due to licenses)
>in Jewel there's a concrete html structure and each of the before
>mentioned
>styles use their own, so I think will
>be almost imposible to apply directly all of that CSSs. So for a button
>I'll must to recreate the look and feel
>and even effects (fades, resizes..) to look very similar to what they
>have,
>but with our own code and css rules
>(for example a button in mdl is "mdl-button mdl-buton--js" while in
>semantic is "ui button" and so on)
>
IMO, if we want to support Bootstrap, we should do it by encapsulation
their HTML structures, not by trying to emulate their visuals.  Then other
Bootstrap themes will "just work".  Again, Royale is primarily in the
business of encapsulating common patterns.  If every Bootstrap user must
fashion a Button out of a <div> and <label> and <input> and give those
tags certain attributes so the Bootstrap CSS will take effect, then a
Bootstrap.swc for Royale would contain view beads that generate those tags
with those attributes.  Another way of thinking about it is to take two
different Bootstrap websites, look at the HTML DOM, find the common
patterns, and those patterns are what the view bead generates.  I thought
MDL worked the same way.  We are creating our own component set at first
just to make debugging simple, but also to make it possible to write
really simple HTML that isn't completely styleable and to avoid licensing
issues, but now you are creating view beads that set up a particular HTML
so you can style it with your CSS.  If you love Bootstrap and want to use
Bootstrap to get our default Royale look, that's fine with me, as long as
you can stay away from licensing issues.

My 2 cents,
-Alex
>

Re: Proper use of Themes and SASS

Posted by Carlos Rovira <ca...@apache.org>.

HI Alex,

2018-03-15 17:44 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:

> Hi Carlos,
>
> Regarding rule precedence in with more than one theme:  I'm pretty sure
> the compiler outputs rules in the order it loads them.  If it doesn't, we
> could probably make it so.  The only trick is in the order of loading when
> one theme is specified on the command line and another is specified in a
> config file.  I think command-line would be last in the order


I just make JewelTheme and JewelBlueTheme to give a first try and you are
right. The trick is the precedence
The later declaration wins, so the following works:

<dependency>
<groupId>org.apache.royale.framework</groupId>
<artifactId>JewelTheme</artifactId>
<version>0.9.3-SNAPSHOT</version>
<type>swc</type>
<scope>theme</scope>
</dependency>
<dependency>
<groupId>org.apache.royale.framework</groupId>
<artifactId>JewelBlueTheme</artifactId>
<version>0.9.3-SNAPSHOT</version>
<type>swc</type>
<scope>theme</scope>
</dependency>

 since the reverse makes colors in default override blue.

so I think is ok


>
> I am hopeful I have explained the issues well enough that you can go
> refactor JewelTheme into multiple folders and get it all working in Maven.
>  I just found this article [1] about using install-file to install
> single-file artifacts.  Don't know about deploying single-file artifacts
> though.  Maybe this will help [2].  So I would like to have you do the
> refactoring.  Once you do that, and also adjust JewelTheme to build both
> SWF and JSRoyale targets, your ClassReference issue should go away.
>

I think as I have the projects setup and running that's ok as well. I need
to remove now common things from blue
and keep only con the common theme. But I think Jewel is not a single-file,
at least in development, although it generates one .css
so I think is ok for now, at least you think it's not. let me know. for me
is ok in the actual state (just committed few moments ago)


>
> It wasn't clear to me that folks should be able to specify any two colors.
>  I thought that MDL and even us in Royale would specify a set of color
> pairs that we know look good together.  And for Royale, those could be
> just themes as .css files.
>

This what I need to think about since the decision will imply less or more
work to do


>
> Regarding supporting other things like Bootstrap, if the sub-trees in the
> components for Jewel are the same as the ones in Bootstrap, then Bootstrap
> should "just work".  Ideally, Bootstrap support isn't critical to Royale
> and we would get noticed for other successes and Bootstrap fans would do
> the work of getting Royale to work with Bootstrap.
>

Maybe this can be confusing, by supporting I mean creating a theme that
"emulates" those well-known styles
but I can guarantee that we can't use the styles in those projects directly
(although if we can due to licenses)
in Jewel there's a concrete html structure and each of the before mentioned
styles use their own, so I think will
be almost imposible to apply directly all of that CSSs. So for a button
I'll must to recreate the look and feel
and even effects (fades, resizes..) to look very similar to what they have,
but with our own code and css rules
(for example a button in mdl is "mdl-button mdl-buton--js" while in
semantic is "ui button" and so on)


>
> I'm off to do other things.  Hopefully you can get Jewel and JewelBlue (or
> even JewelBlueGreen) working in Maven in separate folders and finish up
> the Jewel theme.
>

Yes ok I think I'm already going, only need to test the ClassReference thing

thanks!


>
> Thanks,
> -Alex
>
> [1]
> https://stackoverflow.com/questions/31807924/a-simple-
> way-to-create-a-singl
> e-file-artifact-using-maven
> [2]
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html
>
> On 3/15/18, 2:51 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Hi Alex,
> >
> >I didn't realize that I can add two themes to the build. If that's
> >possible
> >in flex I never did.
> >
> >So my main question here is, what happens if I have the same style in both
> >themes, what will win? will be both in the final app?
> >For example I can make JewelTheme used alone be some kind of default theme
> >(greyed or wireframed) and when added JewelBlueTheme, be colored in blue
> >So in JewelTheme and JewelBlueTheme will have the same style with
> >"background-color" set in one to grey and in the other one to blue.
> >Don't need to answer this, I'll try to do it myself and see what happen.
> >
> >Comparing with for example MDL. I think they created lots of palettes and
> >build all combinations of final CSSs (thanks to using SASS). I think we
> >can
> >do the same, although once we have a 1 or 2 themes working, that would be
> >work to do. I think Semantic does something similar. We can choose some
> >colors and offer those themes as part of royale. For other colors people
> >will need to create it themselves, even pull request us to include as part
> >of our release. We only loose one thing respect to foro example MDL: The
> >way to indicate two basic colors and get the final CSS, or maybe we could
> >consider that add to the -theme JewelTheme the word "Blue", can be enough.
> >All of this already means only *one color* (jewel-blue), and if we want
> >something more material should be jewel-blue-green for example
> >
> >Regarding the problem with alone csss in maven, I think the right way is
> >to
> >use a theme folder structure, so I really doesn't think that as a bug but
> >like a feature hehe ;)
> >
> >With SASS, I only see a problem in the workflow. That can be solved as
> >soon
> >as people not using SASS take care of it.
> >If someone changes the produced css without touch the sass files, this
> >will
> >make that a new SASS compilation overrides the changes.
> >That is easy to solve since we all have to take care to not change one
> >without the other.
> >
> >In the other hand, and after some days of playing with SASS, I want to
> >share that my experience is very positive and now understand why the rest
> >of theme frameworks out there uses some kind of css development tool
> >(Material uses SASS, Semantic LESS, ...). As a theme/UX developer is the
> >same I already mentioned, not using this will be like authoring an icon
> >without a creative tool like Sketch or Photoshop. I continue thinking that
> >SASS should not be part of Royale but maybe in people using ant should
> >introduce in the concrete case of JewelTheme the sass compilation. But not
> >for the rest (Basic , and others). Think of this as a sugerence, but for
> >me
> >doesn't mind since I'm not an ANT user. Maybe in the future if we get
> >other
> >Royale things with more priority done, we could introduce our own
> >sass-flavor compilation (something like ROCSS! ;)), that could give us the
> >same SASS does plus the ability to combine with AS3/MXML substitutions.
> >
> >Final words, I'm thinking, as compiler, and structural problems will be
> >solved to make the following themes based of Jewel structure of html and
> >css rule selectors:
> >
> >- Jewel (this is where I'm now and will set the foundation of names and
> >all
> >that is need for each component, then we can have maybe 6 to 12 colors,
> >and/or combinations, to make this without SASS, I think is not possible
> >since means to automatically generate those final css and combinations,
> >and
> >think about change only one attribute, what means to change this in the
> >rest of css. Doing this manually would make people spend hours)
> >
> >-Material (this will have the same look as google material, and again, I
> >must create the different flavors of colors, again sass is involved in
> >order to not kill myself in the intention ;)
> >
> >-Semantic (same as before replicating semantic)
> >
> >-Bootstrap (same as the other cases replicating bootstrap)
> >
> >This would be a huge effort, and with many time involved, maybe I never
> >could end this alone and can depend on how Royale be adopted in the
> >folowing months years. But this could make us to be very attractive since
> >people can change between different looks easily. This as well has a
> >consideration to, there are many components in that sets that are not in
> >royale, and maybe will never come, and I think that's not important. I
> >talk
> >about have a common factor and try to recreate the different controls that
> >are in only in royale. Maybe we can consider to add for example a Card or
> >Badge component if we consider util...don't know.
> >
> >Thanks
> >
> >
> >
> >2018-03-14 18:32 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> >
> >> So in trying to get the JewelExample to work, I think I understand what
> >> Carlos is trying to do with the Jewel Theme.  I'm going to attempt to
> >> clear up some confusion and propose a plan.  Note that below I am not
> >> using actual file names for brevity and clarity.
> >>
> >> A Theme in Royale is the same as it was in Flex.  It can be a SWC with
> >> code and assets (and some CSS), or just a simple CSS file.  You can
> >> specify more than one theme to the compiler.
> >>
> >> The themes/JewelTheme is not set up properly right now.  It has both a
> >> red.css and blue.css file that are being included in the JewelTheme.swc.
> >> The compiler has been taught to include all css in a SWC in the final
> >> output.  Really, in the themes folder there should be a JewelBlue folder
> >> with just a jewel-blue.css file in it and a JewelRed folder with just a
> >> jewel-red.css file in it and a JewelTheme folder with only shared
> >>assets.
> >>
> >> In Ant, command-line, or IDEs, the user would specify both
> >>JewelTheme.swc
> >> and either jewel-blue.css or jewel-red.css as themes.  For Maven, it is
> >> not clear how to make a simple css file be a Maven artifact so for other
> >> CSS-only themes, so we still build a SWC with only the .css file in it.
> >> See the basic.css in themes.
> >>
> >> IMO, that’s the Royale way for choosing your "primary" color of the
> >>theme
> >> at compile-time.  I think there may be customers who already know this
> >>and
> >> will expect it to work.  I don't see the need to develop some other way
> >> like additional compiler options and substitutions.
> >>
> >> If someone like Carlos wants to use SASS to generate the jewel-red.css
> >>and
> >> jewel-blue.css, I guess that's ok as long as that isn't part of the
> >>build
> >> such that every developer and patcher needs to install SASS.  We can
> >>call
> >> the "final" css files that are committed to the repo the source, IMO.
> >>
> >> Thoughts?
> >> -Alex
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C3a0b7828f62b4a82a7ec08d5
> >8a5a5efe%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636567043103456398&s
> >data=YiPRBIev2mWNmK3R329LekESsm4UMy%2F4RwFa8%2FuhsG0%3D&reserved=0
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Proper use of Themes and SASS

Posted by Alex Harui <ah...@adobe.com.INVALID>.

Hi Carlos,

Regarding rule precedence in with more than one theme:  I'm pretty sure
the compiler outputs rules in the order it loads them.  If it doesn't, we
could probably make it so.  The only trick is in the order of loading when
one theme is specified on the command line and another is specified in a
config file.  I think command-line would be last in the order.

I am hopeful I have explained the issues well enough that you can go
refactor JewelTheme into multiple folders and get it all working in Maven.
 I just found this article [1] about using install-file to install
single-file artifacts.  Don't know about deploying single-file artifacts
though.  Maybe this will help [2].  So I would like to have you do the
refactoring.  Once you do that, and also adjust JewelTheme to build both
SWF and JSRoyale targets, your ClassReference issue should go away.

It wasn't clear to me that folks should be able to specify any two colors.
 I thought that MDL and even us in Royale would specify a set of color
pairs that we know look good together.  And for Royale, those could be
just themes as .css files.

Regarding supporting other things like Bootstrap, if the sub-trees in the
components for Jewel are the same as the ones in Bootstrap, then Bootstrap
should "just work".  Ideally, Bootstrap support isn't critical to Royale
and we would get noticed for other successes and Bootstrap fans would do
the work of getting Royale to work with Bootstrap.

I'm off to do other things.  Hopefully you can get Jewel and JewelBlue (or
even JewelBlueGreen) working in Maven in separate folders and finish up
the Jewel theme.

Thanks,
-Alex

[1] 
https://stackoverflow.com/questions/31807924/a-simple-way-to-create-a-singl
e-file-artifact-using-maven
[2] 
http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

On 3/15/18, 2:51 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:

>Hi Alex,
>
>I didn't realize that I can add two themes to the build. If that's
>possible
>in flex I never did.
>
>So my main question here is, what happens if I have the same style in both
>themes, what will win? will be both in the final app?
>For example I can make JewelTheme used alone be some kind of default theme
>(greyed or wireframed) and when added JewelBlueTheme, be colored in blue
>So in JewelTheme and JewelBlueTheme will have the same style with
>"background-color" set in one to grey and in the other one to blue.
>Don't need to answer this, I'll try to do it myself and see what happen.
>
>Comparing with for example MDL. I think they created lots of palettes and
>build all combinations of final CSSs (thanks to using SASS). I think we
>can
>do the same, although once we have a 1 or 2 themes working, that would be
>work to do. I think Semantic does something similar. We can choose some
>colors and offer those themes as part of royale. For other colors people
>will need to create it themselves, even pull request us to include as part
>of our release. We only loose one thing respect to foro example MDL: The
>way to indicate two basic colors and get the final CSS, or maybe we could
>consider that add to the -theme JewelTheme the word "Blue", can be enough.
>All of this already means only *one color* (jewel-blue), and if we want
>something more material should be jewel-blue-green for example
>
>Regarding the problem with alone csss in maven, I think the right way is
>to
>use a theme folder structure, so I really doesn't think that as a bug but
>like a feature hehe ;)
>
>With SASS, I only see a problem in the workflow. That can be solved as
>soon
>as people not using SASS take care of it.
>If someone changes the produced css without touch the sass files, this
>will
>make that a new SASS compilation overrides the changes.
>That is easy to solve since we all have to take care to not change one
>without the other.
>
>In the other hand, and after some days of playing with SASS, I want to
>share that my experience is very positive and now understand why the rest
>of theme frameworks out there uses some kind of css development tool
>(Material uses SASS, Semantic LESS, ...). As a theme/UX developer is the
>same I already mentioned, not using this will be like authoring an icon
>without a creative tool like Sketch or Photoshop. I continue thinking that
>SASS should not be part of Royale but maybe in people using ant should
>introduce in the concrete case of JewelTheme the sass compilation. But not
>for the rest (Basic , and others). Think of this as a sugerence, but for
>me
>doesn't mind since I'm not an ANT user. Maybe in the future if we get
>other
>Royale things with more priority done, we could introduce our own
>sass-flavor compilation (something like ROCSS! ;)), that could give us the
>same SASS does plus the ability to combine with AS3/MXML substitutions.
>
>Final words, I'm thinking, as compiler, and structural problems will be
>solved to make the following themes based of Jewel structure of html and
>css rule selectors:
>
>- Jewel (this is where I'm now and will set the foundation of names and
>all
>that is need for each component, then we can have maybe 6 to 12 colors,
>and/or combinations, to make this without SASS, I think is not possible
>since means to automatically generate those final css and combinations,
>and
>think about change only one attribute, what means to change this in the
>rest of css. Doing this manually would make people spend hours)
>
>-Material (this will have the same look as google material, and again, I
>must create the different flavors of colors, again sass is involved in
>order to not kill myself in the intention ;)
>
>-Semantic (same as before replicating semantic)
>
>-Bootstrap (same as the other cases replicating bootstrap)
>
>This would be a huge effort, and with many time involved, maybe I never
>could end this alone and can depend on how Royale be adopted in the
>folowing months years. But this could make us to be very attractive since
>people can change between different looks easily. This as well has a
>consideration to, there are many components in that sets that are not in
>royale, and maybe will never come, and I think that's not important. I
>talk
>about have a common factor and try to recreate the different controls that
>are in only in royale. Maybe we can consider to add for example a Card or
>Badge component if we consider util...don't know.
>
>Thanks
>
>
>
>2018-03-14 18:32 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> So in trying to get the JewelExample to work, I think I understand what
>> Carlos is trying to do with the Jewel Theme.  I'm going to attempt to
>> clear up some confusion and propose a plan.  Note that below I am not
>> using actual file names for brevity and clarity.
>>
>> A Theme in Royale is the same as it was in Flex.  It can be a SWC with
>> code and assets (and some CSS), or just a simple CSS file.  You can
>> specify more than one theme to the compiler.
>>
>> The themes/JewelTheme is not set up properly right now.  It has both a
>> red.css and blue.css file that are being included in the JewelTheme.swc.
>> The compiler has been taught to include all css in a SWC in the final
>> output.  Really, in the themes folder there should be a JewelBlue folder
>> with just a jewel-blue.css file in it and a JewelRed folder with just a
>> jewel-red.css file in it and a JewelTheme folder with only shared
>>assets.
>>
>> In Ant, command-line, or IDEs, the user would specify both
>>JewelTheme.swc
>> and either jewel-blue.css or jewel-red.css as themes.  For Maven, it is
>> not clear how to make a simple css file be a Maven artifact so for other
>> CSS-only themes, so we still build a SWC with only the .css file in it.
>> See the basic.css in themes.
>>
>> IMO, that’s the Royale way for choosing your "primary" color of the
>>theme
>> at compile-time.  I think there may be customers who already know this
>>and
>> will expect it to work.  I don't see the need to develop some other way
>> like additional compiler options and substitutions.
>>
>> If someone like Carlos wants to use SASS to generate the jewel-red.css
>>and
>> jewel-blue.css, I guess that's ok as long as that isn't part of the
>>build
>> such that every developer and patcher needs to install SASS.  We can
>>call
>> the "final" css files that are committed to the repo the source, IMO.
>>
>> Thoughts?
>> -Alex
>>
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C3a0b7828f62b4a82a7ec08d5
>8a5a5efe%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636567043103456398&s
>data=YiPRBIev2mWNmK3R329LekESsm4UMy%2F4RwFa8%2FuhsG0%3D&reserved=0