Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Carlos Rovira]

Hi Alex

what do you think about separating the part in Basic that is inherently the
same as in Jewel (Button, CheckBox, TextInput, List, ...) along with CSS
that wire the beads for Basic UI set, and left the fundamental building
blocks as something that is not Core but can be reused by Basic and Jewel
(Let's call this "Foundation" Lib, I even like this name for this library).

I mean that having "Foundation" lib and "Basic" lib, will be more clear,
since we can expect what is in Basic will be never reused to build other UI
Sets (MDL, or others can still hang from there or if someone wants to take
the time refactor it).

Foundation will not have any CSS wiring beads. We can return classes from
Core to Foundation.

Basic will have its own CSS wiring beads, the same for Jewel. Both will
requiere Core and Foundation.

I assume this will make all of us happy.

We can as well do the package name changes to ensure consistency along all
code and libraries.

Let me know what do you think

thanks

Carlos


2018-05-21 19:38 GMT+02:00 Alex Harui :

> I understand this isn't the latest post on this thread, but it is the
> easiest one for me to reply to:
>
> First, the hopefully easy things we can agree on:
> -I have no objection to dropping "Bead" off of bead class names
> -I have no objection to moving all views into a view subfolder as long as
> nobody else is concerned about the size and performance issues.
> -I have no objection to moving classes in Basic that are
> org.apache.royale.html to org.apache.royale.basic.
> -I have no objection to doing a massive rename and long as it isn't me
> doing the work.
> -Whatever is in Core and Basic now or before Carlos's started moving
> things around is not perfect.
>
> Now for the less easy.  Regarding Core vs Basic, I see it this way:  Basic
> is the simplest implementation of the constructs/concepts in Royale.  It is
> intended to be extended and enhanced by other component sets via our PAYG
> principles.  Core is intended to identify the constructs/concepts and their
> fundamental contracts.
>
> Think of it this way:  When you open any class in Royale, you will want to
> know what kind of class it is.  It is a TLC, a Bead?  And what kind of TLC
> or Bead?  Is it  View, Model, Controller?  An ItemRenderer?  These are the
> categories of classes we had, even in Flex.  I've probably left out a few
> categories.  It is the interfaces for these categories that go in Core.
> And maybe some classes we think are universal implementations of those
> categories.  And some beads that are component set agnostic, like
> BrowserResizeHandler, although we could move those to another SWC and say
> that Core should not have any MXML components except maybe State.
>
> After any rename/refactor we decide on, Basic should still have some
> interfaces because those interfaces describe the contract required for the
> simplest implementation.  I get that it can be a fine line between
> "fundamental" and "simplest", but where many classes that were in Basic get
> away from "fundamental" is mainly around Containers.  The way we handle
> Containers in Basic really seems like an opinion instead of a universal,
> "everyone must implement Containers this way" sort of thing.  So it does
> not seem right that lots of Container-related things were moved to Core.
>
> I thought we had agreement on the Terminology and Concepts thread that
> re-usable pieces would be organized into multiple SWCs like Apache or AS3
> Commons.  Any component set designer gets to choose what SWCs to borrow
> from.  The emulation SWCs may borrow from Express because they want to
> re-use multi-purpose beads and aren't interested in the smallest, fastest,
> implementation.   Assuming we fix any issues with accidentally dragging in
> classes that aren't used, if you can re-use code from some other group of
> classes in another SWC, just do it.  But do it because you "want to".
> There is no "need to".  The implementers should "want" to re-use code when
> possible.
>
> In the end, many component sets will re-use Basic beads.  Maybe even
> transitively because they re-use Express which re-uses Basic.  That should
> be ok.  That doesn't make it Core.  It just that lots of component sets
> will start from simple implementations and add more complex functionality.
>  The goal is to minimize code size and maximize performance by re-using
> code.  And as I thought we had agreed upon in Terminology and Concepts, we
> should not be afraid to re-use code.  We are asking our users to do exactly
> the same.  We must create testing infrastructure and have review periods
> and other processes so we don't break downstream component sets or our
> users applications.
>
> One related tidbit:  IMO, the way folks will know what beads work with
> what components will be done by identifying what interfaces the beads
> implement, but also, I expected that we would use ASDoc as well.  If you
> rummage through the source, 

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Carlos Rovira]

Hi Harbs

2018-05-21 18:35 GMT+02:00 Harbs :

> No. Just referencing the Jewel TextPrompt would bring in the class. As
> long as the Basic swc is available, it’ll just work. Assuming any piece of
> Jewel uses Basic, I think Basic should be declared as a dependency by Jewel
> in Maven. With other build types, the swc should always be available. Only
> the actual class used should be imported into the app, so that’s not a
> problem.
>

I think this is our major point of disagreement. In my mind UI sets are
interchangeable pieces. When you start a royale App you choose one of them,
If you want to mix, you want to choose more of them, is your
responsibility. But doing the following tree: Core -> Basic -> Jewel, seems
strange to me since Jewel needs core pieces but no Basic pieces. If Jewel
need a piece that is now in Basic, most probably will be that piece is Core
or is not still elaborated in its final state to be a reusable piece. Other
scenarios more flexible and more suitable for me could be Core -> Jewel and
Core -> Basic, or Core -> Beads (and maybe other components that while are
not core are not of any concrete UI Set) and then Beads -> Basic and Beads
-> Jewel.

I as well talk various times of other technical advantages of separating UI
sets, for me one clear is that we'll be more confident that doing a new
major version will be very easy for us and as well our users will be glad
to not having to deal with a major update mixed with the actual code.
That's a huge benefit.

The major reason is what I already commented: "libraries with resources
that wire beads through CSS should not be obligated to be linked in any
application. That should be something to be choose by Application
developers" (despite existing bugs will be fixed)


> > or do you like more TextPromptBead than TextPrompt?
>
>
> I actually prefer dropping the word Bead, although I think consistency is
> important.
>

Well, consistency should come in 1.0. Is very normal in software to make a
final adjustment before 1.0.
Then we'll need to have a huge point to change something.
But If we'll propose a poll I think we should find that 1) very few users
will respond to the poll, since we are still very few, and 2) most user
will not have problems with this cause of 1) and cause in most cases they
are testing some things in royale at the moment, and 3) I'm pretty sure
that they will understand that we are in 0.9x version and is what they can
expect right now.


>
> FWIW, I’ve done a few beads where the component name is different than the
> class name. One example is  where the class name
> is org.apache.royale.html.beads.ApplicationParametersBead.
>
> I don’t know if this a good idea but it’s what I did… ;-)
>

I think that is legit, but I think you should have in mind that people can
be confused about different names one for mxml and one in code...

Thanks



>
> Harbs
>
> > On May 21, 2018, at 7:21 PM, Carlos Rovira 
> wrote:
> >
> > Ok, that's good point.
> >
> > But, if users need to refer it in code they will need to import the full
> > package rute plus TextPromptBead right?
> > This could be very confusing right? It's only a suggestion (I think is
> > good)? or do you like more TextPromptBead than TextPrompt?
> >
> > Thanks
> >
> > Carlos
> >
> >
> >
> > 2018-05-21 17:44 GMT+02:00 Harbs :
> >
> >> Commenting on this one item (before I respond to the rest).
> >>
> >> If all you want to do is add , you can do this:
> >>
> >>  >> lookupOnly="true" />
> >>
> >> Express does this a lot.
> >>
> >> Harbs
> >>
> >>> On May 21, 2018, at 5:47 PM, Carlos Rovira 
> >> wrote:
> >>>
> >>> In the other hand as I notice before, we can use this to refactor
> >> packages
> >>> and names. Before I mention the convenience to reduce names.
> >>> 
> >>> 
> >>>
> >>> seems less verbose, more elegant and equally efective than
> >>>
> >>> 
> >>> 
> >>>
> >>> right?
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Alex Harui]

I understand this isn't the latest post on this thread, but it is the easiest 
one for me to reply to:

First, the hopefully easy things we can agree on:
-I have no objection to dropping "Bead" off of bead class names
-I have no objection to moving all views into a view subfolder as long as 
nobody else is concerned about the size and performance issues.
-I have no objection to moving classes in Basic that are org.apache.royale.html 
to org.apache.royale.basic.
-I have no objection to doing a massive rename and long as it isn't me doing 
the work.
-Whatever is in Core and Basic now or before Carlos's started moving things 
around is not perfect.

Now for the less easy.  Regarding Core vs Basic, I see it this way:  Basic is 
the simplest implementation of the constructs/concepts in Royale.  It is 
intended to be extended and enhanced by other component sets via our PAYG 
principles.  Core is intended to identify the constructs/concepts and their 
fundamental contracts.

Think of it this way:  When you open any class in Royale, you will want to know 
what kind of class it is.  It is a TLC, a Bead?  And what kind of TLC or Bead?  
Is it  View, Model, Controller?  An ItemRenderer?  These are the categories of 
classes we had, even in Flex.  I've probably left out a few categories.  It is 
the interfaces for these categories that go in Core.  And maybe some classes we 
think are universal implementations of those categories.  And some beads that 
are component set agnostic, like BrowserResizeHandler, although we could move 
those to another SWC and say that Core should not have any MXML components 
except maybe State.

After any rename/refactor we decide on, Basic should still have some interfaces 
because those interfaces describe the contract required for the simplest 
implementation.  I get that it can be a fine line between "fundamental" and 
"simplest", but where many classes that were in Basic get away from 
"fundamental" is mainly around Containers.  The way we handle Containers in 
Basic really seems like an opinion instead of a universal, "everyone must 
implement Containers this way" sort of thing.  So it does not seem right that 
lots of Container-related things were moved to Core.

I thought we had agreement on the Terminology and Concepts thread that 
re-usable pieces would be organized into multiple SWCs like Apache or AS3 
Commons.  Any component set designer gets to choose what SWCs to borrow from.  
The emulation SWCs may borrow from Express because they want to re-use 
multi-purpose beads and aren't interested in the smallest, fastest, 
implementation.   Assuming we fix any issues with accidentally dragging in 
classes that aren't used, if you can re-use code from some other group of 
classes in another SWC, just do it.  But do it because you "want to".  There is 
no "need to".  The implementers should "want" to re-use code when possible.

In the end, many component sets will re-use Basic beads.  Maybe even 
transitively because they re-use Express which re-uses Basic.  That should be 
ok.  That doesn't make it Core.  It just that lots of component sets will start 
from simple implementations and add more complex functionality.   The goal is 
to minimize code size and maximize performance by re-using code.  And as I 
thought we had agreed upon in Terminology and Concepts, we should not be afraid 
to re-use code.  We are asking our users to do exactly the same.  We must 
create testing infrastructure and have review periods and other processes so we 
don't break downstream component sets or our users applications.

One related tidbit:  IMO, the way folks will know what beads work with what 
components will be done by identifying what interfaces the beads implement, but 
also, I expected that we would use ASDoc as well.  If you rummage through the 
source, you'll see that I annotated a few classes with @viewbead and @toplevel. 
 We could add more.  And because our ASDoc is an app, we can then apply smarter 
filtering that help folks narrow down what their choices are, similar to many 
of the online shopping filters I see.

My 2 cents,
-Alex


On 5/21/18, 3:53 AM, "Harbs"  wrote:

Thank you for this.

There’s two groups of files that were changed: Interfaces and and Classes.

In general, I would be more inclined to move interfaces than classes, but 
there are some things to consider:

1. There are still 17 interfaces in Basic. If the 5 that were moved belong 
in Core, what about the remaining 17?
2. I don’t think we’ve come to an agreement on what belongs in Core and 
what belongs in Basic.
3. I’d like to some to an agreement on a package name pattern. What defines 
something belonging to a “core” path as opposed to an “html” path? Some classes 
are in supportClasses and some had that removed from the path. What’s the 
logic? etc.
4. How should different pieces (such as different bead types) be defined in 
paths? (I don’t think 

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Alex Harui]

I think we are in agreement.  My most recent posts were intended to show that 
#2 is not easily solvable, if at all, and thus we should not invest time or 
energy there.

My only suggestions regarding #1 is that we do not invent a second naming 
system, and that whatever we do is PAYG in the sense that I don’t expect users 
to mix component sets as much as borrow beads from other component sets.  Folks 
who have the goal of building the smallest possible app with only one component 
set should not pay for the possibility of mixing in other component sets.

My 2 cents,
-Alex

On 5/21/18, 7:00 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

I think Harbs is right here.

We should take into account that as we focus on presentation (CSS, styles,
drawings, colors, fonts) things are showing that before passed unnoticed.
And now we have the chance to address all of this to make architecture and
presentation get to its best. Both things are equally important here,
Royale finaly has to be very careful with visual things since we are an
interface framework, so if we get styling things works as flexible as
possible, we can expect designers to work with royale.

Thanks

2018-05-21 11:35 GMT+02:00 Harbs :

> I’m getting confused.
>
> Let me try and summarize the issues as I understand them:
>
> There are two different types of issues: Compile time issues, and runtime
> issues.
>
> Compile time issues are:
> 1. Compiled css files do not differentiate between different packages.
> (i.e. ImageButton type selectors will always compile to and .ImageButton
> class selector, no matter what the package name is.
> 2. There’s no way to prevent superclass dependencies from being included
> in output when they are specified in Type selectors in Royale CSS files.
>
> Runtime issues:
> 1. Because of the issue in #1 above, there can be css styling conflicts
> across component sets.
>
> I’m pretty sure that ValuesManager is currently working fine.
>
> From my perspective, the only issue which *needs* to be solved is compiler
> issue #1. That seems like a relatively simple issue to solve. Solving that
> does not require any runtime metadata. All we need is for the “typenames”
> variable in a class to match whatever class name selector the compiler
> outputs in the CSS file. It does *not* need to be the same qualified class
> name that the ValuesManager uses at runtime. The classname that’s actually
> assigned to the HTML element needs to match the CSS class selector in the
> CSS file and it needs to be unique across packages.
>
> Resolving this will fix all the runtime issue that I know of.
>
> Resolving compiler issue #2 is a nice “plus” if we can do it. It would
> allow subclassing components without necessarily bringing in all the
> superclass CSS dependencies. I *think* your main points have to do with
> issue #2.
>
> Are we on the same page here, or am I missing something?
>
> Harbs
>
>
> > On May 19, 2018, at 2:50 AM, Alex Harui 
> wrote:
> >
> >
> >
> > On 5/18/18, 2:50 AM, "Harbs"  wrote:
> >And basic.css has:
> >RadioButton
> >{
> >   font-size: 12px;
> >   font-family: sans-serif;
> >}
> >
> >RadioButton is a Royale Type Selector as it should be. No discussion
> on that front (with the exception that the styling should be removed from
> the defaults.css).
> >
> >Te whole question is what happens in MyApp.css which is compiled
> standard HTML CSS.
> >
> >Currently we get:
> >
> >.RadioButton {
> >font-family: sans-serif;
> >font-size: 12px;
> >}
> >
> >This CSS comes from the Type Selector in basic.css. This seems to be
> included in the app.css even if RadioButton is not included. But putting
> that point aside at the moment, the question is what the class selector 
(in
> app.css) should be *produced* from the type selector.
> >
> > It is not obvious why RadioButton is in the app.css.  This might be a
> new bug from the theme handling I did recently.  I will investigate more.
> >
> >I think we agree that “.RadioButton" is not right because there can
> be RadioButton from more than one component set.
> >
> >One option is to fully qualify the *compiled* class selector so it’s
> named “.org_apache_royale_html_RadioButton”. I’m pretty sure this is what
> you are proposing. The primary objection to that is that it’s a rather 
long
> string and kind of “ugly”.
> >
> > You can choose other string transformations, 

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

No. Just referencing the Jewel TextPrompt would bring in the class. As long as 
the Basic swc is available, it’ll just work. Assuming any piece of Jewel uses 
Basic, I think Basic should be declared as a dependency by Jewel in Maven. With 
other build types, the swc should always be available. Only the actual class 
used should be imported into the app, so that’s not a problem.

> or do you like more TextPromptBead than TextPrompt?


I actually prefer dropping the word Bead, although I think consistency is 
important.

FWIW, I’ve done a few beads where the component name is different than the 
class name. One example is  where the class name is 
org.apache.royale.html.beads.ApplicationParametersBead.

I don’t know if this a good idea but it’s what I did… ;-)

Harbs

> On May 21, 2018, at 7:21 PM, Carlos Rovira  wrote:
> 
> Ok, that's good point.
> 
> But, if users need to refer it in code they will need to import the full
> package rute plus TextPromptBead right?
> This could be very confusing right? It's only a suggestion (I think is
> good)? or do you like more TextPromptBead than TextPrompt?
> 
> Thanks
> 
> Carlos
> 
> 
> 
> 2018-05-21 17:44 GMT+02:00 Harbs :
> 
>> Commenting on this one item (before I respond to the rest).
>> 
>> If all you want to do is add , you can do this:
>> 
>> > class="org.apache.royale.html.accessories.TextPromptBead"
>> lookupOnly="true" />
>> 
>> Express does this a lot.
>> 
>> Harbs
>> 
>>> On May 21, 2018, at 5:47 PM, Carlos Rovira 
>> wrote:
>>> 
>>> In the other hand as I notice before, we can use this to refactor
>> packages
>>> and names. Before I mention the convenience to reduce names.
>>> 
>>> 
>>> 
>>> seems less verbose, more elegant and equally efective than
>>> 
>>> 
>>> 
>>> 
>>> right?
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Carlos Rovira]

Ok, that's good point.

But, if users need to refer it in code they will need to import the full
package rute plus TextPromptBead right?
This could be very confusing right? It's only a suggestion (I think is
good)? or do you like more TextPromptBead than TextPrompt?

Thanks

Carlos



2018-05-21 17:44 GMT+02:00 Harbs :

> Commenting on this one item (before I respond to the rest).
>
> If all you want to do is add , you can do this:
>
>  class="org.apache.royale.html.accessories.TextPromptBead"
> lookupOnly="true" />
>
> Express does this a lot.
>
> Harbs
>
> > On May 21, 2018, at 5:47 PM, Carlos Rovira 
> wrote:
> >
> > In the other hand as I notice before, we can use this to refactor
> packages
> > and names. Before I mention the convenience to reduce names.
> > 
> >  
> >
> > seems less verbose, more elegant and equally efective than
> >
> > 
> >  
> >
> > right?
>
>


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

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

Commenting on this one item (before I respond to the rest).

If all you want to do is add , you can do this:



Express does this a lot.

Harbs

> On May 21, 2018, at 5:47 PM, Carlos Rovira  wrote:
> 
> In the other hand as I notice before, we can use this to refactor packages
> and names. Before I mention the convenience to reduce names.
> 
>  
> 
> seems less verbose, more elegant and equally efective than
> 
> 
>  
> 
> right?

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Carlos Rovira]

Hi Harbs,

2018-05-21 12:52 GMT+02:00 Harbs :

> Thank you for this.
>
> There’s two groups of files that were changed: Interfaces and and Classes.
>
> In general, I would be more inclined to move interfaces than classes, but
> there are some things to consider:
>
> 1. There are still 17 interfaces in Basic. If the 5 that were moved belong
> in Core, what about the remaining 17?
>

I still didn't have to deal with the rest, but normaly when I'll complete
more Jewel components I'll do. As well, I'm pretty sure that I'll need
those interfaces, what will mean that are Core and needs to be moved to
Core project. The other thing to take into account is what we are
discussing in this thread, if I can put in a right core package or not.


> 2. I don’t think we’ve come to an agreement on what belongs in Core and
> what belongs in Basic.
>

I think that's not the focus of this thread, maybe we should discuss in
other? My understanding is that all pieces needed to make a UI set should
go in Core, so Jewel, Basic, and the rest can use it without the need to
use things in others sets.


> 3. I’d like to some to an agreement on a package name pattern. What
> defines something belonging to a “core” path as opposed to an “html” path?


For me is simple: classes in Core lib should be in "core" package. Things
in Basic lib, "basic" package, and so... mixing seems confusing and it
seems that we do not have the house clean. package, classes and method
names and signatures are very important. Is what we expose to users, and
what they'll finally be using.


> Some classes are in supportClasses and some had that removed from the
> path. What’s the logic? etc.
>

I think this is something to unify now. There's lot of this all over
Royale. We have the change on make some work this days to unify the
packages. We can take the ones that have different approaches and unifies
all of them. I think now is better than later. I think we can't go 1.0
without do this. After 1.0 we'll be mostly "freeze".


> 4. How should different pieces (such as different bead types) be defined
> in paths? (I don’t think we’re completely consistent today.)
>

RIght, I think if we have "models" and "controllers" packages, we should
have as well others like "views" and maybe even organize beads that applies
to controls.
How do we expect users to find the beads that apply to a particular
control? If we have "beads/controls/textinput" and inside all TextInput
beads, that should be more easy for a user to know what's available. If not
he can miss some functionality, or never know that already exits.
For beads that are usable cross controls "beads/controls" will be the best
place.
As well to make beads less verbose, I'll vote to remove "Bead" from the
class name, since the package already indicate that is a bead.
composition is more verbose to declare, and it's the main point against it
for what I listen from people. We should try to make names as short while
descriptive as possible.


>
> I think we are coming to a conclusion on the CSS issues that Jewel brought
> up. I think the CSS problems can be solved no matter whether we move things
> between packages and no matter wether we change package paths. I think the
> question on reorganization needs to be discussed on its own right. Do you
> agree with that?
>

Right, I always said that package changes was not something needed for UI
Sets independence. Just said the package changes were advisable to do.
IMHO, that was not the focus at that time, and I think we can do our best
on this focusing on it to get the best final snapshot.


>
> First organization of packages:
> To me, there are two primary questions related to Core vs. Basic:
> 1. What is the defining criteria for something to belong in Core as
> opposed to Basic?
>

For me Core is what is needed to build any UI set we want to support
(Jewel, Basic,), or other libraries that uses as well common
functionality.
Is the required building block in every royale application.


> 2. Is there an issue with one component set (i.e. Jewel) to rely on
> another (i.e. Basic).
>

For me clearly. Making set independent we have more flexibility. And we're
preparing Royale for the needs of the future. In this way a Royale 2.0
version would be far more easy to develop, and to make existing user not be
affected by important changes that a major version will introduce. We can
avoid the problems other did like in Flex, or even more neat in time
Angular 1.x to 2.x and so.
For me independence is clearly a winner feature.


>
> To be clear: I do believe that there is likely some reorganization
> appropriate, but I’m not clear on exactly what and how.
>

It's only a matter of focus a discussion on it like we did on the rest of
points.


>
> Depending on the answers to these questions, we can have a number of
> different courses of action. We might keep things very similar to how they
> are. We might move things from Basic to Core. We might split Basic 

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Carlos Rovira]

Hi Pior,

I think if you could take care of ANT files as well it would be great.
In this way, when I upload the new 70 theme projects, I'll be doing taking
into account your work to make all work directly

thanks



2018-05-21 15:57 GMT+02:00 Piotr Zarzycki :

> I think new one will be more visible, but it doesn't matter to me. I will
> add Moonshine files to those projects. If any user open project with
> Moonshine it will just work.
>
> I will try to update also VSCode files, unless someone beat me with that.
>
> Piotr
>
> 2018-05-21 15:51 GMT+02:00 Carlos Rovira :
>
> > Hi Piotr,
> >
> > that's right, right now several people reported problems to try this.
> Hope
> > as we release they'll have less problems. I want to figure if we can
> update
> > blog posts with more info, or make a new post and then reference existing
> > post to that one...I'll take a look as I have some time
> >
> > thanks
> >
> > 2018-05-21 11:19 GMT+02:00 Piotr Zarzycki :
> >
> > > Alex,
> > >
> > > I can confirm that this is working. When I added following compiler
> > > arguments
> > >
> > > -theme=${royalelib}/themes/Jewel-Light-NoFlat-Primary-
> > > Blue-Theme/src/main/resources/defaults.css
> > >
> > > My suggestion is that:
> > >
> > > 1) We should write blog post which describes how to setup all examples
> in
> > > Moonshine and VSCode. Write about above compiler arguments, because I
> see
> > > couple of comments where people just trying to use example and having
> > > problems.
> > > 2) Make proper description in Release notes or Wiki.
> > >
> > > Thanks,
> > > Piotr
> > >
> > > 2018-05-21 8:18 GMT+02:00 Alex Harui :
> > >
> > > > I'm too swamped to read this whole thread, but one note:  Ant doesn't
> > > need
> > > > to build CSS-only themes.  The examples that use them only need to
> use
> > > > -theme=
> > > >
> > > > HTH,
> > > > -Alex
> > > >
> > > > On 5/20/18, 12:52 AM, "carlos.rov...@gmail.com on behalf of Carlos
> > > > Rovira"  carlosrov...@apache.org>
> > > > wrote:
> > > >
> > > > So great! :)
> > > >
> > > > as I said in the my last email, someone should contribute the ANT
> > > > builds
> > > > for each theme.
> > > > In that way, since at some time I'll be uploading the other half
> of
> > > > themes,
> > > > those themes can go with the right ANT build.
> > > > Think that all Jewel themes are about 140, and I uploaded around
> > 70.
> > > >
> > > > Thanks! :)
> > > >
> > > > 2018-05-19 12:36 GMT+02:00 Piotr Zarzycki <
> > piotrzarzyck...@gmail.com
> > > >:
> > > >
> > > > > Definitely ant build for all themes is broken. There is
> > absolutely
> > > > no swcs.
> > > > > However I did small experiment - I build specific theme by
> Maven
> > > and
> > > > it
> > > > > produces for me:
> > > > >
> > > > > */themes/Jewel-Light-NoFlat-Primary-Blue-Theme/target/
> > > > > Jewel-Light-NoFlat-Primary-Blue-Theme-0.9.4-SNAPSHOT-js.swc*
> > > > >
> > > > > I have added in Moonshine in project Settings Additional
> compiler
> > > > options:
> > > > >
> > > > > *-theme=${royalelib}/themes/Jewel-Light-NoFlat-Primary-
> > > > > Blue-Theme/target/Jewel-Light-NoFlat-Primary-Blue-Theme-0.9.
> > > > > 4-SNAPSHOT-js.swc*
> > > > >
> > > > > And Example: "
> > > > > *BE0006_Binding_the_text_property_of_a_Jewel_Textinput_
> > > > > to_update_a_text_label*"
> > > > > successfully loaded theme. We definitely have solution for the
> > path
> > > > > problem!
> > > > >
> > > > > Many Thanks Josh.
> > > > >
> > > > > The only thing which have to be fix is ANT build.
> > > > >
> > > > > Thanks,
> > > > > Piotr
> > > > >
> > > > >
> > > > > 2018-05-19 12:18 GMT+02:00 Piotr Zarzycki <
> > > piotrzarzyck...@gmail.com
> > > > >:
> > > > >
> > > > > > Carlos,
> > > > > >
> > > > > > If when I checked distribution package of Royale [1] I don't
> > see
> > > > there
> > > > > > Jewel-Dark-NoFlat-Emphasized-Blue-Theme.swc. The only things
> > > > which I'm
> > > > > > seeing is folder frameworks/themes/
> > Jewel-Dark-NoFlat-Emphasized-
> > > > > > Blue-Theme.
> > > > > >
> > > > > > Where those swcs are ? Have you make them build by ANT ?
> > > > > >
> > > > > > [1] https://na01.safelinks.protection.outlook.com/?url=
> > > > http%3A%2F%2Fapacheroyaleci.westus2.cloudapp.azure.com%
> > > > 3A8080%2Fjob%2F=02%7C01%7Caharui%40adobe.com%
> > > > 7Ce94879db7680431c8e9708d5be269652%7Cfa7b1b5a7b34438794aed2c178de
> > > > cee1%7C0%7C0%7C636623995327137023=
> CTQf3SW4yMdjGNMGtVZc0CJCUg8jxF
> > > > 06pgGFYKPAQxs%3D=0
> > > > > royale-asjs/
> > > > > >
> > > > > > Thanks,
> > > > > > Piotr
> > > > > >
> > > > > >
> > > > > > 2018-05-19 7:08 GMT+02:00 Carlos Rovira <
> > carlosrov...@apache.org
> > 

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Piotr Zarzycki]

I think new one will be more visible, but it doesn't matter to me. I will
add Moonshine files to those projects. If any user open project with
Moonshine it will just work.

I will try to update also VSCode files, unless someone beat me with that.

Piotr

2018-05-21 15:51 GMT+02:00 Carlos Rovira :

> Hi Piotr,
>
> that's right, right now several people reported problems to try this. Hope
> as we release they'll have less problems. I want to figure if we can update
> blog posts with more info, or make a new post and then reference existing
> post to that one...I'll take a look as I have some time
>
> thanks
>
> 2018-05-21 11:19 GMT+02:00 Piotr Zarzycki :
>
> > Alex,
> >
> > I can confirm that this is working. When I added following compiler
> > arguments
> >
> > -theme=${royalelib}/themes/Jewel-Light-NoFlat-Primary-
> > Blue-Theme/src/main/resources/defaults.css
> >
> > My suggestion is that:
> >
> > 1) We should write blog post which describes how to setup all examples in
> > Moonshine and VSCode. Write about above compiler arguments, because I see
> > couple of comments where people just trying to use example and having
> > problems.
> > 2) Make proper description in Release notes or Wiki.
> >
> > Thanks,
> > Piotr
> >
> > 2018-05-21 8:18 GMT+02:00 Alex Harui :
> >
> > > I'm too swamped to read this whole thread, but one note:  Ant doesn't
> > need
> > > to build CSS-only themes.  The examples that use them only need to use
> > > -theme=
> > >
> > > HTH,
> > > -Alex
> > >
> > > On 5/20/18, 12:52 AM, "carlos.rov...@gmail.com on behalf of Carlos
> > > Rovira" 
> > > wrote:
> > >
> > > So great! :)
> > >
> > > as I said in the my last email, someone should contribute the ANT
> > > builds
> > > for each theme.
> > > In that way, since at some time I'll be uploading the other half of
> > > themes,
> > > those themes can go with the right ANT build.
> > > Think that all Jewel themes are about 140, and I uploaded around
> 70.
> > >
> > > Thanks! :)
> > >
> > > 2018-05-19 12:36 GMT+02:00 Piotr Zarzycki <
> piotrzarzyck...@gmail.com
> > >:
> > >
> > > > Definitely ant build for all themes is broken. There is
> absolutely
> > > no swcs.
> > > > However I did small experiment - I build specific theme by Maven
> > and
> > > it
> > > > produces for me:
> > > >
> > > > */themes/Jewel-Light-NoFlat-Primary-Blue-Theme/target/
> > > > Jewel-Light-NoFlat-Primary-Blue-Theme-0.9.4-SNAPSHOT-js.swc*
> > > >
> > > > I have added in Moonshine in project Settings Additional compiler
> > > options:
> > > >
> > > > *-theme=${royalelib}/themes/Jewel-Light-NoFlat-Primary-
> > > > Blue-Theme/target/Jewel-Light-NoFlat-Primary-Blue-Theme-0.9.
> > > > 4-SNAPSHOT-js.swc*
> > > >
> > > > And Example: "
> > > > *BE0006_Binding_the_text_property_of_a_Jewel_Textinput_
> > > > to_update_a_text_label*"
> > > > successfully loaded theme. We definitely have solution for the
> path
> > > > problem!
> > > >
> > > > Many Thanks Josh.
> > > >
> > > > The only thing which have to be fix is ANT build.
> > > >
> > > > Thanks,
> > > > Piotr
> > > >
> > > >
> > > > 2018-05-19 12:18 GMT+02:00 Piotr Zarzycki <
> > piotrzarzyck...@gmail.com
> > > >:
> > > >
> > > > > Carlos,
> > > > >
> > > > > If when I checked distribution package of Royale [1] I don't
> see
> > > there
> > > > > Jewel-Dark-NoFlat-Emphasized-Blue-Theme.swc. The only things
> > > which I'm
> > > > > seeing is folder frameworks/themes/
> Jewel-Dark-NoFlat-Emphasized-
> > > > > Blue-Theme.
> > > > >
> > > > > Where those swcs are ? Have you make them build by ANT ?
> > > > >
> > > > > [1] https://na01.safelinks.protection.outlook.com/?url=
> > > http%3A%2F%2Fapacheroyaleci.westus2.cloudapp.azure.com%
> > > 3A8080%2Fjob%2F=02%7C01%7Caharui%40adobe.com%
> > > 7Ce94879db7680431c8e9708d5be269652%7Cfa7b1b5a7b34438794aed2c178de
> > > cee1%7C0%7C0%7C636623995327137023=CTQf3SW4yMdjGNMGtVZc0CJCUg8jxF
> > > 06pgGFYKPAQxs%3D=0
> > > > royale-asjs/
> > > > >
> > > > > Thanks,
> > > > > Piotr
> > > > >
> > > > >
> > > > > 2018-05-19 7:08 GMT+02:00 Carlos Rovira <
> carlosrov...@apache.org
> > >:
> > > > >
> > > > >> Great Josh!, this sounds like a solution! Hope Harbs or Piotr
> > can
> > > try
> > > > this
> > > > >> and report if is working! :)
> > > > >>
> > > > >> 2018-05-19 0:38 GMT+02:00 Josh Tynjala <
> joshtynj...@apache.org
> > >:
> > > > >>
> > > > >> > Please forgive me if I'm missing some context because I'm
> just
> > > > skimming
> > > > >> > through here. However, I think I may be able to offer a
> > > suggestion.
> > > > >> >
> > > > >> > Is the absolute path a location inside the the Royale 

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Carlos Rovira]

Hi Piotr,

that's right, right now several people reported problems to try this. Hope
as we release they'll have less problems. I want to figure if we can update
blog posts with more info, or make a new post and then reference existing
post to that one...I'll take a look as I have some time

thanks

2018-05-21 11:19 GMT+02:00 Piotr Zarzycki :

> Alex,
>
> I can confirm that this is working. When I added following compiler
> arguments
>
> -theme=${royalelib}/themes/Jewel-Light-NoFlat-Primary-
> Blue-Theme/src/main/resources/defaults.css
>
> My suggestion is that:
>
> 1) We should write blog post which describes how to setup all examples in
> Moonshine and VSCode. Write about above compiler arguments, because I see
> couple of comments where people just trying to use example and having
> problems.
> 2) Make proper description in Release notes or Wiki.
>
> Thanks,
> Piotr
>
> 2018-05-21 8:18 GMT+02:00 Alex Harui :
>
> > I'm too swamped to read this whole thread, but one note:  Ant doesn't
> need
> > to build CSS-only themes.  The examples that use them only need to use
> > -theme=
> >
> > HTH,
> > -Alex
> >
> > On 5/20/18, 12:52 AM, "carlos.rov...@gmail.com on behalf of Carlos
> > Rovira" 
> > wrote:
> >
> > So great! :)
> >
> > as I said in the my last email, someone should contribute the ANT
> > builds
> > for each theme.
> > In that way, since at some time I'll be uploading the other half of
> > themes,
> > those themes can go with the right ANT build.
> > Think that all Jewel themes are about 140, and I uploaded around 70.
> >
> > Thanks! :)
> >
> > 2018-05-19 12:36 GMT+02:00 Piotr Zarzycki  >:
> >
> > > Definitely ant build for all themes is broken. There is absolutely
> > no swcs.
> > > However I did small experiment - I build specific theme by Maven
> and
> > it
> > > produces for me:
> > >
> > > */themes/Jewel-Light-NoFlat-Primary-Blue-Theme/target/
> > > Jewel-Light-NoFlat-Primary-Blue-Theme-0.9.4-SNAPSHOT-js.swc*
> > >
> > > I have added in Moonshine in project Settings Additional compiler
> > options:
> > >
> > > *-theme=${royalelib}/themes/Jewel-Light-NoFlat-Primary-
> > > Blue-Theme/target/Jewel-Light-NoFlat-Primary-Blue-Theme-0.9.
> > > 4-SNAPSHOT-js.swc*
> > >
> > > And Example: "
> > > *BE0006_Binding_the_text_property_of_a_Jewel_Textinput_
> > > to_update_a_text_label*"
> > > successfully loaded theme. We definitely have solution for the path
> > > problem!
> > >
> > > Many Thanks Josh.
> > >
> > > The only thing which have to be fix is ANT build.
> > >
> > > Thanks,
> > > Piotr
> > >
> > >
> > > 2018-05-19 12:18 GMT+02:00 Piotr Zarzycki <
> piotrzarzyck...@gmail.com
> > >:
> > >
> > > > Carlos,
> > > >
> > > > If when I checked distribution package of Royale [1] I don't see
> > there
> > > > Jewel-Dark-NoFlat-Emphasized-Blue-Theme.swc. The only things
> > which I'm
> > > > seeing is folder frameworks/themes/ Jewel-Dark-NoFlat-Emphasized-
> > > > Blue-Theme.
> > > >
> > > > Where those swcs are ? Have you make them build by ANT ?
> > > >
> > > > [1] https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fapacheroyaleci.westus2.cloudapp.azure.com%
> > 3A8080%2Fjob%2F=02%7C01%7Caharui%40adobe.com%
> > 7Ce94879db7680431c8e9708d5be269652%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636623995327137023=CTQf3SW4yMdjGNMGtVZc0CJCUg8jxF
> > 06pgGFYKPAQxs%3D=0
> > > royale-asjs/
> > > >
> > > > Thanks,
> > > > Piotr
> > > >
> > > >
> > > > 2018-05-19 7:08 GMT+02:00 Carlos Rovira  >:
> > > >
> > > >> Great Josh!, this sounds like a solution! Hope Harbs or Piotr
> can
> > try
> > > this
> > > >> and report if is working! :)
> > > >>
> > > >> 2018-05-19 0:38 GMT+02:00 Josh Tynjala  >:
> > > >>
> > > >> > Please forgive me if I'm missing some context because I'm just
> > > skimming
> > > >> > through here. However, I think I may be able to offer a
> > suggestion.
> > > >> >
> > > >> > Is the absolute path a location inside the the Royale SDK? If
> > so, then
> > > >> you
> > > >> > can use the ${royalelib} token to refer to the path relative
> to
> > the
> > > >> SDK's
> > > >> > *frameworks* directory. The Royale compiler knows how to
> > resolve a
> > > path
> > > >> > based on this token.
> > > >> >
> > > >> > For other SDKs, there's a similar ${flexlib} token. For the
> > example
> > > >> themes
> > > >> > included with the Feathers SDK, I've successfully used
> > ${flexlib} to
> > > >> add a
> > > >> > SWC to my project in *asconfig.json* without needing an
> > absolute path:
> > > 

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

[Harbs]

Thank you for this.

There’s two groups of files that were changed: Interfaces and and Classes.

In general, I would be more inclined to move interfaces than classes, but there 
are some things to consider:

1. There are still 17 interfaces in Basic. If the 5 that were moved belong in 
Core, what about the remaining 17?
2. I don’t think we’ve come to an agreement on what belongs in Core and what 
belongs in Basic.
3. I’d like to some to an agreement on a package name pattern. What defines 
something belonging to a “core” path as opposed to an “html” path? Some classes 
are in supportClasses and some had that removed from the path. What’s the 
logic? etc.
4. How should different pieces (such as different bead types) be defined in 
paths? (I don’t think we’re completely consistent today.)

I think we are coming to a conclusion on the CSS issues that Jewel brought up. 
I think the CSS problems can be solved no matter whether we move things between 
packages and no matter wether we change package paths. I think the question on 
reorganization needs to be discussed on its own right. Do you agree with that?

First organization of packages:
To me, there are two primary questions related to Core vs. Basic:
1. What is the defining criteria for something to belong in Core as opposed to 
Basic?
2. Is there an issue with one component set (i.e. Jewel) to rely on another 
(i.e. Basic).

To be clear: I do believe that there is likely some reorganization appropriate, 
but I’m not clear on exactly what and how.

Depending on the answers to these questions, we can have a number of different 
courses of action. We might keep things very similar to how they are. We might 
move things from Basic to Core. We might split Basic into two packages. Other 
options?

Regarding package paths: I don’t think there’s a single “right” answer to that, 
but we do need to agree on a pattern that we all stick to. Currently (even 
before any refactor) package paths feel like many are haphazard, and I often 
have difficulty guessing what the path is for a specific class. I also 
sometimes have difficulty guessing which package a specific class belongs to.

These are the high-level questions I have.

Please allow me to focus on question #2. I find it easiest to discuss concrete 
examples, so I’m taking TextPrompt, but it’s just an example. Basic has a 
TextPromptBead. Jewel has TextPrompt. The code of the two classes are 
identical. I’m assuming TextPrompt was copied because TextPromptBead does not 
belong in Core (something I agree with), and you did not want Jewel to have a 
dependency on Basic. So my question is (assuming CSS and classes not used are 
not copied), what is wrong with Jewel using the TextPromptBead in Basic? To me 
the advantage of using the Basic bead is that there’s no code duplication and 
that helps from a development perspective (i.e. only a single place to fix 
bugs) and from a perspective of code size in the resulting application (in case 
both classes are used somewhere).

Harbs

> On May 21, 2018, at 11:29 AM, Carlos Rovira  wrote:
> 
> Hi,
> 
> as we talked I take the time to make a list of package name changes.
> Finally 20 classes were changed from package.
> Here's the list from 16c0dcd643974fe708fd67a3774ea6e35e879811 (in red the
> changes to better following)
> 
> frameworks/projects/Core/src/main/royale/org/apache/royale/core/MXMLBeadView.as
> 
> frameworks/projects/Basic/src/main/royale/org/apache/royale/html
> /MXMLBeadView.as
> frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/views/ContainerView.as
>  
> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/ContainerView.as.
>  (1)
> frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/views/DataContainerView.as
>  frameworks/projects/Basic/src/main/royale/org/apache/royale/html
> /beads/DataContainerView.as
> frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/GroupView.as
> 
> frameworks/projects/Basic/src/main/royale/org/apache/royale/html
> /beads/GroupView.as
> frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/IBackgroundBead.as
>  frameworks/projects/Basic/src/main/royale/org/apache/royale/
> html/beads/IBackgroundBead.as
> frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/IBorderBead.as
> 
> frameworks/projects/Basic/src/main/royale/org/apache/royale/html
> /beads/IBorderBead.as
> frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/IDropDownListView.as
>frameworks/projects/Basic/src/main/royale/org/apache/royale/html
> /beads/IDropDownListView.as
> frameworks/projects/Core/src/main/royale/org/apache/royale/core/IListView.as
> 
> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/IListView.as.
>   (2)
> frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/ITextFieldView.as
>   

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

[Harbs]

I’m getting confused.

Let me try and summarize the issues as I understand them:

There are two different types of issues: Compile time issues, and runtime 
issues.

Compile time issues are:
1. Compiled css files do not differentiate between different packages. (i.e. 
ImageButton type selectors will always compile to and .ImageButton class 
selector, no matter what the package name is.
2. There’s no way to prevent superclass dependencies from being included in 
output when they are specified in Type selectors in Royale CSS files.

Runtime issues:
1. Because of the issue in #1 above, there can be css styling conflicts across 
component sets.

I’m pretty sure that ValuesManager is currently working fine.

From my perspective, the only issue which *needs* to be solved is compiler 
issue #1. That seems like a relatively simple issue to solve. Solving that does 
not require any runtime metadata. All we need is for the “typenames” variable 
in a class to match whatever class name selector the compiler outputs in the 
CSS file. It does *not* need to be the same qualified class name that the 
ValuesManager uses at runtime. The classname that’s actually assigned to the 
HTML element needs to match the CSS class selector in the CSS file and it needs 
to be unique across packages.

Resolving this will fix all the runtime issue that I know of.

Resolving compiler issue #2 is a nice “plus” if we can do it. It would allow 
subclassing components without necessarily bringing in all the superclass CSS 
dependencies. I *think* your main points have to do with issue #2.

Are we on the same page here, or am I missing something?

Harbs


> On May 19, 2018, at 2:50 AM, Alex Harui  wrote:
> 
> 
> 
> On 5/18/18, 2:50 AM, "Harbs"  wrote:
>And basic.css has:
>RadioButton
>{
>   font-size: 12px;
>   font-family: sans-serif;
>}
> 
>RadioButton is a Royale Type Selector as it should be. No discussion on 
> that front (with the exception that the styling should be removed from the 
> defaults.css).
> 
>Te whole question is what happens in MyApp.css which is compiled standard 
> HTML CSS.
> 
>Currently we get:
> 
>.RadioButton {
>font-family: sans-serif;
>font-size: 12px;
>}
> 
>This CSS comes from the Type Selector in basic.css. This seems to be 
> included in the app.css even if RadioButton is not included. But putting that 
> point aside at the moment, the question is what the class selector (in 
> app.css) should be *produced* from the type selector.
> 
> It is not obvious why RadioButton is in the app.css.  This might be a new bug 
> from the theme handling I did recently.  I will investigate more.
> 
>I think we agree that “.RadioButton" is not right because there can be 
> RadioButton from more than one component set.
> 
>One option is to fully qualify the *compiled* class selector so it’s named 
> “.org_apache_royale_html_RadioButton”. I’m pretty sure this is what you are 
> proposing. The primary objection to that is that it’s a rather long string 
> and kind of “ugly”.
> 
> You can choose other string transformations, but the key point is that they 
> should be derived from the unique QName.  Any other scheme just means that 
> the developer has to solve the unique name problem twice which increases the 
> chance of collision.
> 
>Another option is “.basic.Button”. The advantage of this approach is 
> mostly aesthetics. It also has the advantage of being theoretically more 
> flexible because CSS can be applied to “basic" and “Button” separately. Of 
> course that goes both ways and if there’s css applied to “.Button” by 
> mistake, it can effect the “basic” Button where it’s not supposed to.
> 
> I'm not clear how the compiler or the ValuesManager (at runtime) can 
> efficiently associate .basic.Button with org.apache.royale.basic.Button.  
> Metadata lookups can be expensive.
> 
> 
>> If one problem is with Type Selectors in Royale inheriting styles from Base 
>> Classes, we should discuss ways to manage that.  Metadata is possible, but 
>> metadata is expensive at runtime.
> 
>Good point about extra code from meta tags. Maybe the compiler could strip 
> these out?
> 
> My point is that ValuesManager will need this information at runtime.
> 
>My suggestion with meta-data was a way to enable the second option. It 
> does not need to be specifically meta-tags. It could be something like this 
> as well:
> 
>/**
>* royaleclassselector RadioButton
>* royaleclassprefix basic
>* royaleinheritsbaseselector
>*/
> 
> These ASDoc directives are definitely not available at runtime.
> 
> 
>> There are two parts to how Type Selectors work.  The main concern appears to 
>> be the ClassReferences kind of CSS, which is not handled by the Browser.  
>> The IValuesImpl has to decide whether to look up the base class and it would 
>> have to fetch and parse metadata at runtime to do 

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Piotr Zarzycki]

Alex,

I can confirm that this is working. When I added following compiler
arguments

-theme=${royalelib}/themes/Jewel-Light-NoFlat-Primary-Blue-Theme/src/main/resources/defaults.css

My suggestion is that:

1) We should write blog post which describes how to setup all examples in
Moonshine and VSCode. Write about above compiler arguments, because I see
couple of comments where people just trying to use example and having
problems.
2) Make proper description in Release notes or Wiki.

Thanks,
Piotr

2018-05-21 8:18 GMT+02:00 Alex Harui :

> I'm too swamped to read this whole thread, but one note:  Ant doesn't need
> to build CSS-only themes.  The examples that use them only need to use
> -theme=
>
> HTH,
> -Alex
>
> On 5/20/18, 12:52 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> So great! :)
>
> as I said in the my last email, someone should contribute the ANT
> builds
> for each theme.
> In that way, since at some time I'll be uploading the other half of
> themes,
> those themes can go with the right ANT build.
> Think that all Jewel themes are about 140, and I uploaded around 70.
>
> Thanks! :)
>
> 2018-05-19 12:36 GMT+02:00 Piotr Zarzycki :
>
> > Definitely ant build for all themes is broken. There is absolutely
> no swcs.
> > However I did small experiment - I build specific theme by Maven and
> it
> > produces for me:
> >
> > */themes/Jewel-Light-NoFlat-Primary-Blue-Theme/target/
> > Jewel-Light-NoFlat-Primary-Blue-Theme-0.9.4-SNAPSHOT-js.swc*
> >
> > I have added in Moonshine in project Settings Additional compiler
> options:
> >
> > *-theme=${royalelib}/themes/Jewel-Light-NoFlat-Primary-
> > Blue-Theme/target/Jewel-Light-NoFlat-Primary-Blue-Theme-0.9.
> > 4-SNAPSHOT-js.swc*
> >
> > And Example: "
> > *BE0006_Binding_the_text_property_of_a_Jewel_Textinput_
> > to_update_a_text_label*"
> > successfully loaded theme. We definitely have solution for the path
> > problem!
> >
> > Many Thanks Josh.
> >
> > The only thing which have to be fix is ANT build.
> >
> > Thanks,
> > Piotr
> >
> >
> > 2018-05-19 12:18 GMT+02:00 Piotr Zarzycki  >:
> >
> > > Carlos,
> > >
> > > If when I checked distribution package of Royale [1] I don't see
> there
> > > Jewel-Dark-NoFlat-Emphasized-Blue-Theme.swc. The only things
> which I'm
> > > seeing is folder frameworks/themes/ Jewel-Dark-NoFlat-Emphasized-
> > > Blue-Theme.
> > >
> > > Where those swcs are ? Have you make them build by ANT ?
> > >
> > > [1] https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fapacheroyaleci.westus2.cloudapp.azure.com%
> 3A8080%2Fjob%2F=02%7C01%7Caharui%40adobe.com%
> 7Ce94879db7680431c8e9708d5be269652%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636623995327137023=CTQf3SW4yMdjGNMGtVZc0CJCUg8jxF
> 06pgGFYKPAQxs%3D=0
> > royale-asjs/
> > >
> > > Thanks,
> > > Piotr
> > >
> > >
> > > 2018-05-19 7:08 GMT+02:00 Carlos Rovira :
> > >
> > >> Great Josh!, this sounds like a solution! Hope Harbs or Piotr can
> try
> > this
> > >> and report if is working! :)
> > >>
> > >> 2018-05-19 0:38 GMT+02:00 Josh Tynjala :
> > >>
> > >> > Please forgive me if I'm missing some context because I'm just
> > skimming
> > >> > through here. However, I think I may be able to offer a
> suggestion.
> > >> >
> > >> > Is the absolute path a location inside the the Royale SDK? If
> so, then
> > >> you
> > >> > can use the ${royalelib} token to refer to the path relative to
> the
> > >> SDK's
> > >> > *frameworks* directory. The Royale compiler knows how to
> resolve a
> > path
> > >> > based on this token.
> > >> >
> > >> > For other SDKs, there's a similar ${flexlib} token. For the
> example
> > >> themes
> > >> > included with the Feathers SDK, I've successfully used
> ${flexlib} to
> > >> add a
> > >> > SWC to my project in *asconfig.json* without needing an
> absolute path:
> > >> >
> > >> > "library-path": ["${flexlib}/themes/MetalWorksDesktopTheme/
> > >> > MetalWorksDesktopTheme.swc"]
> > >> >
> > >> > A while back, I made sure that the ${royalelib} and ${flexlib}
> tokens
> > >> both
> > >> > work in VSCode.
> > >> >
> > >> > - Josh
> > >> >
> > >> > On 2018/05/18 13:05:34, Harbs  wrote:
> > >> > > No. Specifying the themes seems to be a major problem.
> > >> > >
> > >> > > It’s possible to specify a theme using additional compiler
> options
> > in
> > >> > asconfig, but I’m not prepared to specify an absolute path. This
> > needs a
>  

[Discussion] Package change names (was Re: 0.9.3 Release)

[Carlos Rovira]

Hi,

as we talked I take the time to make a list of package name changes.
Finally 20 classes were changed from package.
Here's the list from 16c0dcd643974fe708fd67a3774ea6e35e879811 (in red the
changes to better following)

frameworks/projects/Core/src/main/royale/org/apache/royale/core/MXMLBeadView.as

 frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/MXMLBeadView.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/views/ContainerView.as
  
frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/ContainerView.as.
  (1)
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/views/DataContainerView.as
  frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/DataContainerView.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/GroupView.as

frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/GroupView.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/IBackgroundBead.as
  frameworks/projects/Basic/src/main/royale/org/apache/royale/
html/beads/IBackgroundBead.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/IBorderBead.as

frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/IBorderBead.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/IDropDownListView.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/IDropDownListView.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/IListView.as

frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/IListView.as.
   (2)
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/ITextFieldView.as
   frameworks/projects/Basic/src/main/royale/org/apache/royale/
html/beads/ITextFieldView.as(2)
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/TextFieldViewBase.as

frameworks/projects/Basic/src/main/royale/org/apache/royale/html/beads/TextFieldViewBase.as
(2)
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/layouts/LayoutChangeNotifier.as
 frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/layouts/LayoutChangeNotifier.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/models/ArraySelectionModel.as
   frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/models/ArraySelectionModel.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/beads/models/ViewportModel.as
 frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/beads/models/ViewportModel.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/supportClasses/Border.as
  frameworks/projects/Basic/src/main/royale/org/apache/royale/
html/supportClasses/Border.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/supportClasses/ContainerContentArea.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html/supportClasses/ContainerContentArea.as.
(2)
frameworks/projects/Core/src/main/royale/org/apache/royale/core/supportClasses/DataGroup.as
   
frameworks/projects/Basic/src/main/royale/org/apache/royale/html/supportClasses/DataGroup.as

frameworks/projects/Core/src/main/royale/org/apache/royale/core/DataItemRenderer.as

 frameworks/projects/Basic/src/main/royale/org/apache/royale/html/
supportClasses/DataItemRenderer.as  (3)
frameworks/projects/Core/src/main/royale/org/apache/royale/core/MXMLItemRenderer.as

 frameworks/projects/Basic/src/main/royale/org/apache/royale/html/
supportClasses/MXMLItemRenderer.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/UIItemRendererBase.as

 frameworks/projects/Basic/src/main/royale/org/apache/royale/html/
supportClasses/UIItemRendererBase.as
frameworks/projects/Core/src/main/royale/org/apache/royale/core/supportClasses/Viewport.as
frameworks/projects/Basic/src/main/royale/org/apache/royale/html
/supportClasses/Viewport.as

Some comments:

(1) "views" should follow the same package structure we have with other
beads 8"models", "controllers"...) to be consistent.
(2) should go to "core/beads/views" as well
(3) item renderers that should normaly be used by final users could go some
kind of "itemRenderers" package, while base item redeemer classes could go
again to supportClasses.

As Harbs said, if we agree in the change of packages, we should do this
well and perform some other changes that make all more consistent though
libraries.

Thanks

Carlos




2018-05-17 11:16 GMT+02:00 Harbs :

> Definitely a plan.
>
> My guess is that if we agree on changing package paths, there will likely
> be other classes that should be considered.
>
> My preference would be to have this discussion after we finish the project
> refactor discussion because I think it’s going to be 

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Alex Harui]

I'm too swamped to read this whole thread, but one note:  Ant doesn't need to 
build CSS-only themes.  The examples that use them only need to use 
-theme=

HTH,
-Alex

On 5/20/18, 12:52 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

So great! :)

as I said in the my last email, someone should contribute the ANT builds
for each theme.
In that way, since at some time I'll be uploading the other half of themes,
those themes can go with the right ANT build.
Think that all Jewel themes are about 140, and I uploaded around 70.

Thanks! :)

2018-05-19 12:36 GMT+02:00 Piotr Zarzycki :

> Definitely ant build for all themes is broken. There is absolutely no 
swcs.
> However I did small experiment - I build specific theme by Maven and it
> produces for me:
>
> */themes/Jewel-Light-NoFlat-Primary-Blue-Theme/target/
> Jewel-Light-NoFlat-Primary-Blue-Theme-0.9.4-SNAPSHOT-js.swc*
>
> I have added in Moonshine in project Settings Additional compiler options:
>
> *-theme=${royalelib}/themes/Jewel-Light-NoFlat-Primary-
> Blue-Theme/target/Jewel-Light-NoFlat-Primary-Blue-Theme-0.9.
> 4-SNAPSHOT-js.swc*
>
> And Example: "
> *BE0006_Binding_the_text_property_of_a_Jewel_Textinput_
> to_update_a_text_label*"
> successfully loaded theme. We definitely have solution for the path
> problem!
>
> Many Thanks Josh.
>
> The only thing which have to be fix is ANT build.
>
> Thanks,
> Piotr
>
>
> 2018-05-19 12:18 GMT+02:00 Piotr Zarzycki :
>
> > Carlos,
> >
> > If when I checked distribution package of Royale [1] I don't see there
> > Jewel-Dark-NoFlat-Emphasized-Blue-Theme.swc. The only things which I'm
> > seeing is folder frameworks/themes/ Jewel-Dark-NoFlat-Emphasized-
> > Blue-Theme.
> >
> > Where those swcs are ? Have you make them build by ANT ?
> >
> > [1] 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheroyaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2F=02%7C01%7Caharui%40adobe.com%7Ce94879db7680431c8e9708d5be269652%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636623995327137023=CTQf3SW4yMdjGNMGtVZc0CJCUg8jxF06pgGFYKPAQxs%3D=0
> royale-asjs/
> >
> > Thanks,
> > Piotr
> >
> >
> > 2018-05-19 7:08 GMT+02:00 Carlos Rovira :
> >
> >> Great Josh!, this sounds like a solution! Hope Harbs or Piotr can try
> this
> >> and report if is working! :)
> >>
> >> 2018-05-19 0:38 GMT+02:00 Josh Tynjala :
> >>
> >> > Please forgive me if I'm missing some context because I'm just
> skimming
> >> > through here. However, I think I may be able to offer a suggestion.
> >> >
> >> > Is the absolute path a location inside the the Royale SDK? If so, 
then
> >> you
> >> > can use the ${royalelib} token to refer to the path relative to the
> >> SDK's
> >> > *frameworks* directory. The Royale compiler knows how to resolve a
> path
> >> > based on this token.
> >> >
> >> > For other SDKs, there's a similar ${flexlib} token. For the example
> >> themes
> >> > included with the Feathers SDK, I've successfully used ${flexlib} to
> >> add a
> >> > SWC to my project in *asconfig.json* without needing an absolute 
path:
> >> >
> >> > "library-path": ["${flexlib}/themes/MetalWorksDesktopTheme/
> >> > MetalWorksDesktopTheme.swc"]
> >> >
> >> > A while back, I made sure that the ${royalelib} and ${flexlib} tokens
> >> both
> >> > work in VSCode.
> >> >
> >> > - Josh
> >> >
> >> > On 2018/05/18 13:05:34, Harbs  wrote:
> >> > > No. Specifying the themes seems to be a major problem.
> >> > >
> >> > > It’s possible to specify a theme using additional compiler options
> in
> >> > asconfig, but I’m not prepared to specify an absolute path. This
> needs a
> >> > solution…
> >> > >
> >> > > Harbs
> >> > >
> >> > > > On May 18, 2018, at 3:56 PM, Piotr Zarzycki <
> >> piotrzarzyck...@gmail.com>
> >> > wrote:
> >> > > >
> >> > > > Hi Harbs,
> >> > > >
> >> > > > Were you able to setup project in IDE ?
> >> > > >
> >> > > > Thanks,
> >> > > > Piotr
> >> > > >
> >> > > > 2018-05-17 15:13 GMT+02:00 Carlos Rovira  >:
> >> > > >
> >> > > >> Look foro "Inject a Font"
> >> > > >>
> >> > > >> 2018-05-17 15:12 GMT+02:00 Harbs :
> >> > > >>
> >> > > >>> What was the subject?
> >> > > >>>
> >> > >  On May 17, 2018, at 4:08 PM, Carlos Rovira <
> >> carlosrov...@apache.org
> >> > >
> >> > > >>> wrote:
> >> 

Re: [royale-asjs] 01/02: Allow acceptance of licenses by setting ACCEPT_ALL_ROYALE_LICENSES=true environment variable.

[Alex Harui]

Hi Om,

I'd have to check with Adobe people on bypassing acceptance of Adobe 
agreements.  Before I bother them, why is this bypass required?  We did already 
get approval to store that you have accepted once so future installs don't 
require license acceptance.  Is there a way to do something like that instead?

Thanks,
-Alex

On 5/19/18, 5:11 PM, "bigosma...@apache.org"  wrote:

This is an automated email from the ASF dual-hosted git repository.

bigosmallm pushed a commit to branch issues/230-Add_License_Agreement_Env
in repository 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%2Froyale-asjs.git=02%7C01%7Caharui%40adobe.com%7C4291890b8b8b449e0e0808d5bde627c1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636623718625660132=l0bfzrXIAm%2B52%2B8MBhX4q7Ddgj8R%2BD%2FQ1ebponx1NNU%3D=0

commit 614753f1d0046593402e0e2b126e73344f10e7df
Author: Om Muppirala 
AuthorDate: Sat May 19 17:10:07 2018 -0700

Allow acceptance of licenses by setting ACCEPT_ALL_ROYALE_LICENSES=true 
environment variable.
---
 npm/README.md| 12 ++--
 npm/js-swf/dependencies/AdobeAIR.js  |  8 +++-
 npm/js-swf/dependencies/FlashPlayerGlobal.js |  8 +++-
 npm/js-swf/dependencies/FlatUI.js|  8 +++-
 4 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/npm/README.md b/npm/README.md
index d637783..3f9fb00 100644
--- a/npm/README.md
+++ b/npm/README.md
@@ -8,7 +8,9 @@ The **Apache Royale** NPM packages are distributed under 
the Apache-Royale NPM o
 The package: `@apache-royale/royale-js` supports only the JS/HTML output.  
 The package: `@apache-royale/royale-js-swf` supports both JS/HTML and 
SWF/AIR output.  
 
-**For End Users**
+##For End Users
+
+**Manual installs**
 
 To install these packages, users need to run the following commands:
 
@@ -17,7 +19,13 @@ npm install @apache-royale/royale-js -g
 npm install @apache-royale/royale-js-swf -g
 ```
 
-**For Release Managers:**
+**Automated installs**
+
+Set the environment variable: `ACCEPT_ALL_ROYALE_LICENSES=true` to accept 
all the licenses prompted 
+by the npm installer script.  This lets you use the installer in a 
automated environment without 
+interactive prompts. 
+
+##For Release Managers
 
 To setup the publish scripts, first run:
 
diff --git a/npm/js-swf/dependencies/AdobeAIR.js 
b/npm/js-swf/dependencies/AdobeAIR.js
index 30c77da..4261212 100644
--- a/npm/js-swf/dependencies/AdobeAIR.js
+++ b/npm/js-swf/dependencies/AdobeAIR.js
@@ -96,5 +96,11 @@ function extract()
 
 AdobeAIR.install = function()
 {
-promptForAdobeAIR();
+if(process.env.ACCEPT_ALL_ROYALE_LICENSES === 'true')
+{
+downloadAdobeAIR();
+}
+else {
+promptForAdobeAIR();
+}
 };
\ No newline at end of file
diff --git a/npm/js-swf/dependencies/FlashPlayerGlobal.js 
b/npm/js-swf/dependencies/FlashPlayerGlobal.js
index ca2abd2..bfb6edd 100644
--- a/npm/js-swf/dependencies/FlashPlayerGlobal.js
+++ b/npm/js-swf/dependencies/FlashPlayerGlobal.js
@@ -97,5 +97,11 @@ function handleInstallComplete(event)
 
 FlashPlayerGlobal.install = function()
 {
-FlashPlayerGlobal.promptForFlashPlayerGlobal();
+if(process.env.ACCEPT_ALL_ROYALE_LICENSES === 'true')
+{
+FlashPlayerGlobal.downloadFlashPlayerGlobal();
+}
+else {
+FlashPlayerGlobal.promptForFlashPlayerGlobal();
+}
 };
\ No newline at end of file
diff --git a/npm/js-swf/dependencies/FlatUI.js 
b/npm/js-swf/dependencies/FlatUI.js
index ea4a88c..41cb89a 100644
--- a/npm/js-swf/dependencies/FlatUI.js
+++ b/npm/js-swf/dependencies/FlatUI.js
@@ -127,5 +127,11 @@ function extract()
 
 FlatUI.install = function()
 {
-FlatUI.prompt();
+if(process.env.ACCEPT_ALL_ROYALE_LICENSES === 'true')
+{
+FlatUI.downloadFlatUI();
+}
+else {
+FlatUI.prompt();
+}
 };
\ No newline at end of file

-- 
To stop receiving notification emails like this one, please contact
bigosma...@apache.org.