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

[Carlos Rovira]

Hi Alex,

2018-06-04 20:15 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> At this point, I think I've addressed all of the compiler issues that
> result in unnecessary output or processing.  If Harbs is finished with the
> framework changes, then I think we can try building Jewel with and without
> Basic and see if there are still issues.
>

I'll give it a try and see. But If we get things working ok, I still expect
we can move things from what we call currently Basic to it's own SWC (TLCs,
CSS and direct related beads)
I still have to make a small list example like Harbs requested me for this.


> I have to say that my understanding of your responses seem counter to how
> the main patterns in Royale's composition-based frameworks are supposed to
> work.  Here are some of the disconnects as I see them.
>

I think we really have the same goals in mind and there's only one point
that I'm not like (make Jewel extend a library with Basic TLCs, direct
beads and CSS).


>
> 1. Jewel Views, Models, Controllers and other beads should not be tied to
> Jewel TLCs.  TLCs are intended to be example compositions of beads.  See
> the "Exploded Component" section of "Terminology and Concepts".
>

Right, I still need to get to this point and check this along with SWF
version. This days I was concentrating in get IE11 work. Right now is
almost done, and only need to solve 2 problems (Slider and SVG colors) to
get that part complete.


> 2. Jewel Views should not be tied to Jewel Models.   Jewel may not even
> need its own Models for many controls.  The default TextButton model just
> has text and html properties.  There shouldn't be anything
> component-set-specific about such a model.
>

Right. You said that because you saw some incorrect relationship in the
actual code? if so we need to fix that.


> 3. Folks are encouraged to create compositions from beads at all levels of
> the framework, from all component sets, in order to maximize code reuse.
> So, if you want to split Basic beads into a separate SWC from Basic TLCs,
> you must also agree to split Jewel beads into a separate SWC away from
> Jewel TLCs.


Yes, I don't want beads in Jewel of general purpose. If I find someone I'll
move to the shared lib. This days I removed some that was copied temporal
(i.e MultilineLabel), and modified other beads that was just copied until
now (layout beads, now has a different code with CSS handling, and still
need more work). But I have still more code that should be moved as we
finishing this discussion or even removed.


>That way, folks who compose Jewel beads into another component set will
> enjoy the same benefits you are claiming will happen if we split Basic
> beads from Basic TLCs.
>

Right


> 4. Because there are different levels of complexity, it does not make
> sense to try to make one universal library of re-usable pieces.  Also,
> because we want third-parties to have a viable ecosystem for their
> components, we want to make sure that composition works well in a
> decentralized organizational model.
>

Right


> 5. Everything in Royale, even the TLCs need to be reusable.  The MXML
> Component model requires it, especially of TLCs.
>
> I noticed just now that Jewel does not yet have any "composite" components
> (meaning, components composed of other components).  You may want to work
> on Jewel DataGrid, for example, and have it use the Express type-agnostic
> DataGridModel.  It might help illustrate how different levels of bead
> complexity should work.
>

Maybe Jewel List is the only composite component in Jewel right now right?

I need to finish some few things and then will handle this ok?

Thanks


>
> My 2 cents,
> -Alex
>
> On 6/1/18, 1:26 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> Hi Alex,
>
> 2018-06-01 8:08 GMT+02:00 Alex Harui :
> >
> >
> > Key word here is *optional* not *mandatory*. Take this in mind,
> since
> > while
> > I have the option to use it or not, I even should have the
> option to
> > link
> > it or not, since there's no obligation or requeriment to use.
> >
> > Everything is currently optional the way we have it, but the
> principle of
> > code re-use is primary.
>
>
> I think here can't agree. Until the refactor, I couldn't get rid off
> all
> the Basic things I didn't want. Rigth now is truly optional. In all
> possible views (code, css and library linking), while still you can
> take
> the old route as well. Everybody wins here.
>
>
> > Copying code to avoid a project dependency is not a recommended
> practice.
> >
>
> If I copy code is to change it. In the final picture you should never
> see
> the same code. For example yesterday I notice the existence of
> UIDUtils,
> that was almost the same code than RPCUIutils, so I removed the later.
> This
> days I plan to work on jewel layouts. This code is already different,
> but
> it will be even more, more CSS 

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

[Alex Harui]

Hi Carlos,

At this point, I think I've addressed all of the compiler issues that result in 
unnecessary output or processing.  If Harbs is finished with the framework 
changes, then I think we can try building Jewel with and without Basic and see 
if there are still issues.

I have to say that my understanding of your responses seem counter to how the 
main patterns in Royale's composition-based frameworks are supposed to work.  
Here are some of the disconnects as I see them.

1. Jewel Views, Models, Controllers and other beads should not be tied to Jewel 
TLCs.  TLCs are intended to be example compositions of beads.  See the 
"Exploded Component" section of "Terminology and Concepts".
2. Jewel Views should not be tied to Jewel Models.   Jewel may not even need 
its own Models for many controls.  The default TextButton model just has text 
and html properties.  There shouldn't be anything component-set-specific about 
such a model.
3. Folks are encouraged to create compositions from beads at all levels of the 
framework, from all component sets, in order to maximize code reuse.  So, if 
you want to split Basic beads into a separate SWC from Basic TLCs, you must 
also agree to split Jewel beads into a separate SWC away from Jewel TLCs.   
That way, folks who compose Jewel beads into another component set will enjoy 
the same benefits you are claiming will happen if we split Basic beads from 
Basic TLCs.
4. Because there are different levels of complexity, it does not make sense to 
try to make one universal library of re-usable pieces.  Also, because we want 
third-parties to have a viable ecosystem for their components, we want to make 
sure that composition works well in a decentralized organizational model.
5. Everything in Royale, even the TLCs need to be reusable.  The MXML Component 
model requires it, especially of TLCs.

I noticed just now that Jewel does not yet have any "composite" components 
(meaning, components composed of other components).  You may want to work on 
Jewel DataGrid, for example, and have it use the Express type-agnostic 
DataGridModel.  It might help illustrate how different levels of bead 
complexity should work.

My 2 cents,
-Alex

On 6/1/18, 1:26 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Alex,

2018-06-01 8:08 GMT+02:00 Alex Harui :
>
>
> Key word here is *optional* not *mandatory*. Take this in mind, since
> while
> I have the option to use it or not, I even should have the option to
> link
> it or not, since there's no obligation or requeriment to use.
>
> Everything is currently optional the way we have it, but the principle of
> code re-use is primary.


I think here can't agree. Until the refactor, I couldn't get rid off all
the Basic things I didn't want. Rigth now is truly optional. In all
possible views (code, css and library linking), while still you can take
the old route as well. Everybody wins here.


> Copying code to avoid a project dependency is not a recommended practice.
>

If I copy code is to change it. In the final picture you should never see
the same code. For example yesterday I notice the existence of UIDUtils,
that was almost the same code than RPCUIutils, so I removed the later. This
days I plan to work on jewel layouts. This code is already different, but
it will be even more, more CSS based and with more features. But it started
as a copy of similar layout code in Basic. I think that's a normal process.


>
> The Emulation set will use Basic beads for models and controllers and lots
> of other things, if the simple implementations suffice.
>

I think this will be difficult or at least I don't see how that will work.
If MXRoyale Button wants to have the Jewel visuals, it will need Jewel
Button, not Basic Button, and the Jewel Theme. In general, Jewel controls
and components setup a concrete visual structure through "createElementwith
a concrete style structure that MXRoyale will need to replicate in code. So
Basic seems very far from this requirement. for complex components where
views are in place is more natural to use Jewel parts than go Basic. For
example Slider in Basic has a different approach than in Jewel, so trying
to make the visuals in Jewel work with Basic won't work.

I think to make this happen we should think not in actual Basic or Jewel
but in only one unified set that can rely less in createElement and more in
view implementations so we can have separated SWCs with Basic and Jewel
views.


> I mentioned this before.  The DataGridModel in Express is type-agnostic
> (dataProvider is Object) whereas in Basic is assumes the dataProvider is 
an
> Array.  And you can configure the Basic one to use different dataProviders
> of different types.  That's on purpose, for PAYG 

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

[Carlos Rovira]

Hi Harbs,

ok, I'll try to make a brief list of some of the classes involved so you
and others can have a better understanding of how things can be
restructured so we get best of both worlds. Hope to make this today.

thanks

Carlos

2018-06-02 21:36 GMT+02:00 Harbs :

> Hi Carlos,
>
> I think our wires are still crossed. Rather than me trying to address your
> points below, I think we still need to work on definitions. Let me try like
> this:
>
> A Jewel dependency on “Foundation” is OK for you, but a dependency on
> “Basic” is not. Right?
>
> In your view, which files in the Basic project make it “Basic” rather than
> “Foundation”? Put another way: Which files can we remove from Basic to make
> it “Foundation”?
>
> If we can narrow this down to a list of files which you believe make a
> dependency “bad”, I think that focuses the issue a lot better. We don’t
> need a full list of files at the moment, but a sampling of the files that
> you view as “bad dependencies” would make it much clearer for me (and
> others). If you prefer, I could compose a list of files myself, but I’d
> like to hear from you what you think.
>
> Thanks,
> Harbs
>
> > On Jun 1, 2018, at 5:55 PM, Carlos Rovira 
> wrote:
> >
> > Hi Harbs,
> >
> > 2018-06-01 13:07 GMT+02:00 Harbs :
> >
> >>
> >> We both agree that Jewel should have a dependency on “Foundation” or
> >> “Basic”. The only question is TLCs. What practical difference does this
> >> point have?
> >>
> >>
> > All thoughts about why not make TLCs and CSS was exposed several times. I
> > think you already know what I think about it. Don't think write about it
> > one more time have sense.
> > I think you don't expose opposite arguments. Maybe this part is in a
> field
> > dominated by a mixture of technical issues and how each of us likes to
> > codify things and for this reason is hard to reach consensus. I believe
> > that your vision may be correct, but I personally see more benefits in
> > which I am defending. If I must to choose only on arguments or
> evidences, I
> > think the way I'm proposing should be the way to go.
> >
> >
> >
> >>>
> 
>  I’d like to propose the following way forward.
> 
>  1. Both Basic (Foundation) pieces and Basic TLCs should have the same
>  package paths and namespaces.
> 
> >>>
> >>> Don't think so. If you want to promote reusable pieces, the refactor of
> >>> names should make them go to a different package other than Basic. It's
> >>> like to propose to put on a jewel package would be a bad decision. In
> the
> >>> refactor I was for "core", since the common pieces was in Core. So I
> >> think
> >>> it will depend on the name of the library to choose. For me Basic is a
> >> good
> >>> name for Basic UI Set since clearly states what all the code there do.
> I
> >>> still think Foundation is a good name, but if you don't like, I think
> you
> >>> should propose other one that seems more appropriate.
> >>
> >> I really don’t care very much what the project name is. “Base” “Basic”
> and
> >> “Foundation” are all good. To me they all mean the same thing.
> >
> >
> > I really see a tangible difference between "foundation" pieces to use all
> > over other royale parts and "basic" pieces that are the most basic or
> base
> > representation while express or jewel are more complex and pursue
> different
> > complex scenarios (so is basic vs complex).
> >
> >
> >> I’d prefer to stick with Basic because I don’t see a gain in renaming
> it.
> >> Foundation is a “long” name. I don’t see a reason to make the name
> longer.
> >> I feel very strongly that the TLCs should have the same paths and
> >> namespaces as the rest of Basic.
> >
> > I consider Basic TLCs a part of the Basic concept. Even if Jewel doesn’t
> >> end up using it, other component sets likely will. Creating a new
> package
> >> path and namespace serves no function and makes things more difficult.
> Why
> >> go there?
> >>
> >
> > ok, for this is not crucial, is only something that the other name like
> me
> > more and fit for me more, but in this part I'm ok if finaly we need to go
> > with "basic". In every negotiation we can't get *all*
> >
> >
> >
> >>
> >>>
>  2. By doing this, it will be very painless to pull Basic TLCs out of
> >> Basic
>  into a separate project or merge it back in. (i.e. BasicComponents)
> >> (Either
>  now, or in the future.)
> 
> >>>
> >>> I think we must be doing it moving little by little and ensuring after
> a
> >>> little refactor all continues working.
> >>
> >> Moving what? I don’t think moving the entire list of TLCs (i.e. what is
> >> used in the Basic CSS) is more than a few hours of work.
> >>
> >
> > In fact the initial refactor took me 2 days of about 10-12 work hours to
> > complete. This will take a time to do it, but it can be done without
> > problem with patience and perseverance.
> >
> >>
> >> Basic *is* that shared library. To prevent linking to Basic (TLCs), we
> can
> >> move the Basic TLCs out of Basic 

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

[Harbs]

Hi Carlos,

I think our wires are still crossed. Rather than me trying to address your 
points below, I think we still need to work on definitions. Let me try like 
this:

A Jewel dependency on “Foundation” is OK for you, but a dependency on “Basic” 
is not. Right?

In your view, which files in the Basic project make it “Basic” rather than 
“Foundation”? Put another way: Which files can we remove from Basic to make it 
“Foundation”?

If we can narrow this down to a list of files which you believe make a 
dependency “bad”, I think that focuses the issue a lot better. We don’t need a 
full list of files at the moment, but a sampling of the files that you view as 
“bad dependencies” would make it much clearer for me (and others). If you 
prefer, I could compose a list of files myself, but I’d like to hear from you 
what you think.

Thanks,
Harbs

> On Jun 1, 2018, at 5:55 PM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> 2018-06-01 13:07 GMT+02:00 Harbs :
> 
>> 
>> We both agree that Jewel should have a dependency on “Foundation” or
>> “Basic”. The only question is TLCs. What practical difference does this
>> point have?
>> 
>> 
> All thoughts about why not make TLCs and CSS was exposed several times. I
> think you already know what I think about it. Don't think write about it
> one more time have sense.
> I think you don't expose opposite arguments. Maybe this part is in a field
> dominated by a mixture of technical issues and how each of us likes to
> codify things and for this reason is hard to reach consensus. I believe
> that your vision may be correct, but I personally see more benefits in
> which I am defending. If I must to choose only on arguments or evidences, I
> think the way I'm proposing should be the way to go.
> 
> 
> 
>>> 
 
 I’d like to propose the following way forward.
 
 1. Both Basic (Foundation) pieces and Basic TLCs should have the same
 package paths and namespaces.
 
>>> 
>>> Don't think so. If you want to promote reusable pieces, the refactor of
>>> names should make them go to a different package other than Basic. It's
>>> like to propose to put on a jewel package would be a bad decision. In the
>>> refactor I was for "core", since the common pieces was in Core. So I
>> think
>>> it will depend on the name of the library to choose. For me Basic is a
>> good
>>> name for Basic UI Set since clearly states what all the code there do. I
>>> still think Foundation is a good name, but if you don't like, I think you
>>> should propose other one that seems more appropriate.
>> 
>> I really don’t care very much what the project name is. “Base” “Basic” and
>> “Foundation” are all good. To me they all mean the same thing.
> 
> 
> I really see a tangible difference between "foundation" pieces to use all
> over other royale parts and "basic" pieces that are the most basic or base
> representation while express or jewel are more complex and pursue different
> complex scenarios (so is basic vs complex).
> 
> 
>> I’d prefer to stick with Basic because I don’t see a gain in renaming it.
>> Foundation is a “long” name. I don’t see a reason to make the name longer.
>> I feel very strongly that the TLCs should have the same paths and
>> namespaces as the rest of Basic.
> 
> I consider Basic TLCs a part of the Basic concept. Even if Jewel doesn’t
>> end up using it, other component sets likely will. Creating a new package
>> path and namespace serves no function and makes things more difficult. Why
>> go there?
>> 
> 
> ok, for this is not crucial, is only something that the other name like me
> more and fit for me more, but in this part I'm ok if finaly we need to go
> with "basic". In every negotiation we can't get *all*
> 
> 
> 
>> 
>>> 
 2. By doing this, it will be very painless to pull Basic TLCs out of
>> Basic
 into a separate project or merge it back in. (i.e. BasicComponents)
>> (Either
 now, or in the future.)
 
>>> 
>>> I think we must be doing it moving little by little and ensuring after a
>>> little refactor all continues working.
>> 
>> Moving what? I don’t think moving the entire list of TLCs (i.e. what is
>> used in the Basic CSS) is more than a few hours of work.
>> 
> 
> In fact the initial refactor took me 2 days of about 10-12 work hours to
> complete. This will take a time to do it, but it can be done without
> problem with patience and perseverance.
> 
>> 
>> Basic *is* that shared library. To prevent linking to Basic (TLCs), we can
>> move the Basic TLCs out of Basic *at any time*. I don’t see why we need to
>> *do anything* right now (except get everything working for a release).
>> Jewel apps might be slightly larger for a month or two until we get this
>> sorted out, but what’s the rush?
>> 
> 
> Harbs, I completely disagree with that path. Is to come back to insert
> entropy and bad practices again, or go to backwards. For me this point is
> crucial. Again, we must see what points are very important  and for me this
> is not important, 

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

[Carlos Rovira]

Hi Harbs,

2018-06-01 13:07 GMT+02:00 Harbs :

>
> We both agree that Jewel should have a dependency on “Foundation” or
> “Basic”. The only question is TLCs. What practical difference does this
> point have?
>
>
All thoughts about why not make TLCs and CSS was exposed several times. I
think you already know what I think about it. Don't think write about it
one more time have sense.
I think you don't expose opposite arguments. Maybe this part is in a field
dominated by a mixture of technical issues and how each of us likes to
codify things and for this reason is hard to reach consensus. I believe
that your vision may be correct, but I personally see more benefits in
which I am defending. If I must to choose only on arguments or evidences, I
think the way I'm proposing should be the way to go.



> >
> >>
> >> I’d like to propose the following way forward.
> >>
> >> 1. Both Basic (Foundation) pieces and Basic TLCs should have the same
> >> package paths and namespaces.
> >>
> >
> > Don't think so. If you want to promote reusable pieces, the refactor of
> > names should make them go to a different package other than Basic. It's
> > like to propose to put on a jewel package would be a bad decision. In the
> > refactor I was for "core", since the common pieces was in Core. So I
> think
> > it will depend on the name of the library to choose. For me Basic is a
> good
> > name for Basic UI Set since clearly states what all the code there do. I
> > still think Foundation is a good name, but if you don't like, I think you
> > should propose other one that seems more appropriate.
>
> I really don’t care very much what the project name is. “Base” “Basic” and
> “Foundation” are all good. To me they all mean the same thing.


I really see a tangible difference between "foundation" pieces to use all
over other royale parts and "basic" pieces that are the most basic or base
representation while express or jewel are more complex and pursue different
complex scenarios (so is basic vs complex).


> I’d prefer to stick with Basic because I don’t see a gain in renaming it.
> Foundation is a “long” name. I don’t see a reason to make the name longer.
> I feel very strongly that the TLCs should have the same paths and
> namespaces as the rest of Basic.

I consider Basic TLCs a part of the Basic concept. Even if Jewel doesn’t
> end up using it, other component sets likely will. Creating a new package
> path and namespace serves no function and makes things more difficult. Why
> go there?
>

ok, for this is not crucial, is only something that the other name like me
more and fit for me more, but in this part I'm ok if finaly we need to go
with "basic". In every negotiation we can't get *all*



>
> >
> >> 2. By doing this, it will be very painless to pull Basic TLCs out of
> Basic
> >> into a separate project or merge it back in. (i.e. BasicComponents)
> (Either
> >> now, or in the future.)
> >>
> >
> > I think we must be doing it moving little by little and ensuring after a
> > little refactor all continues working.
>
> Moving what? I don’t think moving the entire list of TLCs (i.e. what is
> used in the Basic CSS) is more than a few hours of work.
>

In fact the initial refactor took me 2 days of about 10-12 work hours to
complete. This will take a time to do it, but it can be done without
problem with patience and perseverance.

>
> Basic *is* that shared library. To prevent linking to Basic (TLCs), we can
> move the Basic TLCs out of Basic *at any time*. I don’t see why we need to
> *do anything* right now (except get everything working for a release).
> Jewel apps might be slightly larger for a month or two until we get this
> sorted out, but what’s the rush?
>

Harbs, I completely disagree with that path. Is to come back to insert
entropy and bad practices again, or go to backwards. For me this point is
crucial. Again, we must see what points are very important  and for me this
is not important, is crucial. Think that if you don't like my path, you
always can have again Core - Basic, and I should have Core - Foundation -
Jewel. We will have duplicated code, and will have 2 valid options  living
together, but I don't see other way.


>
> Just consider Basic “Foundation” and ignore all the TLCs for the time
> being. If it’s the right thing to move the TLCs out, we can do that later.
>
>
I think the best path to make us all happy is to set up a new "foundation"
or (whatever the name you want) and be moving things there.
This way, I don't have to link Basic and live 1-2-3 months with the
problem,and we all can move things little by little without problem. This
paths makes the same that you want, but without introducing the problem
again. Can you consider that path?


> Because I don’t think that removing the dependency is the right thing to
> do. Again, whether I’m right or wrong will become clearer as Jewel gets
> completed. If I’m wrong, I’ll be happy to pull out the Basic TLCs myself.
>

But Harbs, I think that we actually 

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

[Harbs]

Hi Carlos,

Comments inline.

> 
> 4. Methodology: Royale should not impose linking of libraries, other that
> Language, Test and Core. I think yes. Alex and you think no.

We both agree that Jewel should have a dependency on “Foundation” or “Basic”. 
The only question is TLCs. What practical difference does this point have?

> 
>> 
>> I’d like to propose the following way forward.
>> 
>> 1. Both Basic (Foundation) pieces and Basic TLCs should have the same
>> package paths and namespaces.
>> 
> 
> Don't think so. If you want to promote reusable pieces, the refactor of
> names should make them go to a different package other than Basic. It's
> like to propose to put on a jewel package would be a bad decision. In the
> refactor I was for "core", since the common pieces was in Core. So I think
> it will depend on the name of the library to choose. For me Basic is a good
> name for Basic UI Set since clearly states what all the code there do. I
> still think Foundation is a good name, but if you don't like, I think you
> should propose other one that seems more appropriate.

I really don’t care very much what the project name is. “Base” “Basic” and 
“Foundation” are all good. To me they all mean the same thing. I’d prefer to 
stick with Basic because I don’t see a gain in renaming it. Foundation is a 
“long” name. I don’t see a reason to make the name longer. I feel very strongly 
that the TLCs should have the same paths and namespaces as the rest of Basic. I 
consider Basic TLCs a part of the Basic concept. Even if Jewel doesn’t end up 
using it, other component sets likely will. Creating a new package path and 
namespace serves no function and makes things more difficult. Why go there?

> 
>> 2. By doing this, it will be very painless to pull Basic TLCs out of Basic
>> into a separate project or merge it back in. (i.e. BasicComponents) (Either
>> now, or in the future.)
>> 
> 
> I think we must be doing it moving little by little and ensuring after a
> little refactor all continues working.

Moving what? I don’t think moving the entire list of TLCs (i.e. what is used in 
the Basic CSS) is more than a few hours of work.

> 
>> 3. Give Alex and me an opportunity to fix all issues and demonstrate that
>> there will be no tax by making Basic TLCs a dependency.
>> 
> 
> Here we have a problem. I think we need to fix things and that should make
> many problems are gone. But although the problems are gone, we have a
> different approach in how to build Jewel components for you Jewel Button
> extends Basic Button, for me Jewel Button extends UIBase... how can we
> overcome it?
> For me your option is less flexible than mine, and I give you many
> arguments, while I don't see any arguments in favor of making Jewel extend
> Basic TLCs
> I think that's the problem here.

I think I understand your arguments, but it does not feel like you understand 
mine. I think that by actually doing the work, the arguments will become 
clearer. Again: I’m *not* proposing that Jewel should extend *all* of Basic 
TLCs. I’m suggesting that it’s appropriate for it to extend *some* of them. I 
think time will show whether I’m right or wrong. What is the harm in letting 
time tell who’s right?

> 
>> 4. Let’s complete Jewel and see wether there is a reason to use the
>> TLCs/CSS.
>> 
> 
> But, in my previous email I said that If I want to continue working in
> Jewel components I need to continue moving things to a library shared.

Basic *is* that shared library. To prevent linking to Basic (TLCs), we can move 
the Basic TLCs out of Basic *at any time*. I don’t see why we need to *do 
anything* right now (except get everything working for a release). Jewel apps 
might be slightly larger for a month or two until we get this sorted out, but 
what’s the rush?

> So to complete since I don't consider the option of linking Basic how can I
> perform the completion? Coming code to Jewel? Is not an option for any of us
> Moving to Core? I think we are still discussing what to do. I only can
> create Foundation lib and move there, while keeping the same in Basic
> temporarily and link Foundation
> to Jewel.
> 
> If you have some additional way to do this that not implies link Basic let
> me know.

Just consider Basic “Foundation” and ignore all the TLCs for the time being. If 
it’s the right thing to move the TLCs out, we can do that later.

> 
>> 5. Let’s do research on whether CSS processing during compilation is an
>> issue and try and figure out our options if it is.
>> 
> 
> Imagine you get to fix bugs and fix current CSS so you get rid of all the
> current problemsThen you prefer to continue in the same way that
> already was clearly problematic, and will bring more problems later? don't
> understand why...when you have a simpler and better way that is removing
> the dependency and it's the most easy and quick way and will preserver the
> integrity always in the future.

Because I don’t think that removing the dependency is the right 

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

[Carlos Rovira]

Hi Harbs

2018-06-01 11:03 GMT+02:00 Harbs :

> Hi Carlos,
>
> Let me try and summarize in a nutshell the difference of opinion.
>
> 1. Should Jewel need/use Basic TLCs and CSS? You think no. Alex and I
> think yes.
> 2. Can we reach a point that by fixing all issues, there will be no
> runtime penalty of making Basic TLCs a dependency? You think no. Alex and I
> think yes.
> 3. Is there an issue with having to process Basic CSS during compilation
> and if yes can this be avoided? No-one has data on this yet. You think
> likely yes. I think likely no. Neither one of us really know the answer to
> this question.
>
> I think that’s the sum total of the disagreement here. Agree?
>

4. Methodology: Royale should not impose linking of libraries, other that
Language, Test and Core. I think yes. Alex and you think no.


>
> I’d like to propose the following way forward.
>
> 1. Both Basic (Foundation) pieces and Basic TLCs should have the same
> package paths and namespaces.
>

Don't think so. If you want to promote reusable pieces, the refactor of
names should make them go to a different package other than Basic. It's
like to propose to put on a jewel package would be a bad decision. In the
refactor I was for "core", since the common pieces was in Core. So I think
it will depend on the name of the library to choose. For me Basic is a good
name for Basic UI Set since clearly states what all the code there do. I
still think Foundation is a good name, but if you don't like, I think you
should propose other one that seems more appropriate.


> 2. By doing this, it will be very painless to pull Basic TLCs out of Basic
> into a separate project or merge it back in. (i.e. BasicComponents) (Either
> now, or in the future.)
>

I think we must be doing it moving little by little and ensuring after a
little refactor all continues working.


> 3. Give Alex and me an opportunity to fix all issues and demonstrate that
> there will be no tax by making Basic TLCs a dependency.
>

Here we have a problem. I think we need to fix things and that should make
many problems are gone. But although the problems are gone, we have a
different approach in how to build Jewel components for you Jewel Button
extends Basic Button, for me Jewel Button extends UIBase... how can we
overcome it?
For me your option is less flexible than mine, and I give you many
arguments, while I don't see any arguments in favor of making Jewel extend
Basic TLCs
I think that's the problem here.


> 4. Let’s complete Jewel and see wether there is a reason to use the
> TLCs/CSS.
>

But, in my previous email I said that If I want to continue working in
Jewel components I need to continue moving things to a library shared.
So to complete since I don't consider the option of linking Basic how can I
perform the completion? Coming code to Jewel? Is not an option for any of us
Moving to Core? I think we are still discussing what to do. I only can
create Foundation lib and move there, while keeping the same in Basic
temporarily and link Foundation
to Jewel.

If you have some additional way to do this that not implies link Basic let
me know.


> 5. Let’s do research on whether CSS processing during compilation is an
> issue and try and figure out our options if it is.
>

Imagine you get to fix bugs and fix current CSS so you get rid of all the
current problemsThen you prefer to continue in the same way that
already was clearly problematic, and will bring more problems later? don't
understand why...when you have a simpler and better way that is removing
the dependency and it's the most easy and quick way and will preserver the
integrity always in the future.


> 6. If we can’t make all the pieces of Basic truly optional, I’ll help you
> pull the Basic TLCs and CSS out into a separate project.
>
>
Ok, my only concern here is how to do this plan, since I see many problems
that only can be making just what I can avoid.


> Would this be acceptable?
>
> Thanks,
> Harbs
>
> > On Jun 1, 2018, at 11:25 AM, Carlos Rovira 
> wrote:
> >
> > Hi Alex,
> >
> > 2018-06-01 8:08 GMT+02:00 Alex Harui :
> >>
> >>
> >>Key word here is *optional* not *mandatory*. Take this in mind, since
> >> while
> >>I have the option to use it or not, I even should have the option to
> >> link
> >>it or not, since there's no obligation or requeriment to use.
> >>
> >> Everything is currently optional the way we have it, but the principle
> of
> >> code re-use is primary.
> >
> >
> > I think here can't agree. Until the refactor, I couldn't get rid off all
> > the Basic things I didn't want. Rigth now is truly optional. In all
> > possible views (code, css and library linking), while still you can take
> > the old route as well. Everybody wins here.
> >
> >
> >> Copying code to avoid a project dependency is not a recommended
> practice.
> >>
> >
> > If I copy code is to change it. In the final picture you should never see
> > the same code. For example yesterday I notice the existence of 

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

[Harbs]

Hi Carlos,

Let me try and summarize in a nutshell the difference of opinion.

1. Should Jewel need/use Basic TLCs and CSS? You think no. Alex and I think yes.
2. Can we reach a point that by fixing all issues, there will be no runtime 
penalty of making Basic TLCs a dependency? You think no. Alex and I think yes.
3. Is there an issue with having to process Basic CSS during compilation and if 
yes can this be avoided? No-one has data on this yet. You think likely yes. I 
think likely no. Neither one of us really know the answer to this question.

I think that’s the sum total of the disagreement here. Agree?

I’d like to propose the following way forward.

1. Both Basic (Foundation) pieces and Basic TLCs should have the same package 
paths and namespaces.
2. By doing this, it will be very painless to pull Basic TLCs out of Basic into 
a separate project or merge it back in. (i.e. BasicComponents) (Either now, or 
in the future.)
3. Give Alex and me an opportunity to fix all issues and demonstrate that there 
will be no tax by making Basic TLCs a dependency.
4. Let’s complete Jewel and see wether there is a reason to use the TLCs/CSS.
5. Let’s do research on whether CSS processing during compilation is an issue 
and try and figure out our options if it is.
6. If we can’t make all the pieces of Basic truly optional, I’ll help you pull 
the Basic TLCs and CSS out into a separate project.

Would this be acceptable?

Thanks,
Harbs

> On Jun 1, 2018, at 11:25 AM, Carlos Rovira  wrote:
> 
> Hi Alex,
> 
> 2018-06-01 8:08 GMT+02:00 Alex Harui :
>> 
>> 
>>Key word here is *optional* not *mandatory*. Take this in mind, since
>> while
>>I have the option to use it or not, I even should have the option to
>> link
>>it or not, since there's no obligation or requeriment to use.
>> 
>> Everything is currently optional the way we have it, but the principle of
>> code re-use is primary.
> 
> 
> I think here can't agree. Until the refactor, I couldn't get rid off all
> the Basic things I didn't want. Rigth now is truly optional. In all
> possible views (code, css and library linking), while still you can take
> the old route as well. Everybody wins here.
> 
> 
>> Copying code to avoid a project dependency is not a recommended practice.
>> 
> 
> If I copy code is to change it. In the final picture you should never see
> the same code. For example yesterday I notice the existence of UIDUtils,
> that was almost the same code than RPCUIutils, so I removed the later. This
> days I plan to work on jewel layouts. This code is already different, but
> it will be even more, more CSS based and with more features. But it started
> as a copy of similar layout code in Basic. I think that's a normal process.
> 
> 
>> 
>> The Emulation set will use Basic beads for models and controllers and lots
>> of other things, if the simple implementations suffice.
>> 
> 
> I think this will be difficult or at least I don't see how that will work.
> If MXRoyale Button wants to have the Jewel visuals, it will need Jewel
> Button, not Basic Button, and the Jewel Theme. In general, Jewel controls
> and components setup a concrete visual structure through "createElementwith
> a concrete style structure that MXRoyale will need to replicate in code. So
> Basic seems very far from this requirement. for complex components where
> views are in place is more natural to use Jewel parts than go Basic. For
> example Slider in Basic has a different approach than in Jewel, so trying
> to make the visuals in Jewel work with Basic won't work.
> 
> I think to make this happen we should think not in actual Basic or Jewel
> but in only one unified set that can rely less in createElement and more in
> view implementations so we can have separated SWCs with Basic and Jewel
> views.
> 
> 
>> I mentioned this before.  The DataGridModel in Express is type-agnostic
>> (dataProvider is Object) whereas in Basic is assumes the dataProvider is an
>> Array.  And you can configure the Basic one to use different dataProviders
>> of different types.  That's on purpose, for PAYG (no extra code to handle
>> different types) and to help folks ensure type-safety.  But our users want
>> less configuration so you can pass "anything" into Express DataGrid's
>> dataProvider, just like Flex.
>> 
> 
> In Jewel, List has the problem that ICollectionView was not sufficient, so
> it has an extension of that class to use ArrayList that seems to be the
> normal use case.
> But people can override that bead for general use or in a particular case.
> 
> 
>>Doubling no, jut one: Foundation - Basic. The rest is up to
>> discussion, but
>>since are not required right now (are already not linked or mandatory)
>> like
>>MDL, CreateJS, and more, I'm fine with it. I recommend in the future
>>refactor as well, but that should be made by volunteers if they want
>> 
>> I think that's inconsistent.  If you agree above that some other component
>> set can re-use Jewel Views, then you 

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

[Carlos Rovira]

Hi Alex,

2018-06-01 8:08 GMT+02:00 Alex Harui :
>
>
> Key word here is *optional* not *mandatory*. Take this in mind, since
> while
> I have the option to use it or not, I even should have the option to
> link
> it or not, since there's no obligation or requeriment to use.
>
> Everything is currently optional the way we have it, but the principle of
> code re-use is primary.


I think here can't agree. Until the refactor, I couldn't get rid off all
the Basic things I didn't want. Rigth now is truly optional. In all
possible views (code, css and library linking), while still you can take
the old route as well. Everybody wins here.


> Copying code to avoid a project dependency is not a recommended practice.
>

If I copy code is to change it. In the final picture you should never see
the same code. For example yesterday I notice the existence of UIDUtils,
that was almost the same code than RPCUIutils, so I removed the later. This
days I plan to work on jewel layouts. This code is already different, but
it will be even more, more CSS based and with more features. But it started
as a copy of similar layout code in Basic. I think that's a normal process.


>
> The Emulation set will use Basic beads for models and controllers and lots
> of other things, if the simple implementations suffice.
>

I think this will be difficult or at least I don't see how that will work.
If MXRoyale Button wants to have the Jewel visuals, it will need Jewel
Button, not Basic Button, and the Jewel Theme. In general, Jewel controls
and components setup a concrete visual structure through "createElementwith
a concrete style structure that MXRoyale will need to replicate in code. So
Basic seems very far from this requirement. for complex components where
views are in place is more natural to use Jewel parts than go Basic. For
example Slider in Basic has a different approach than in Jewel, so trying
to make the visuals in Jewel work with Basic won't work.

I think to make this happen we should think not in actual Basic or Jewel
but in only one unified set that can rely less in createElement and more in
view implementations so we can have separated SWCs with Basic and Jewel
views.


> I mentioned this before.  The DataGridModel in Express is type-agnostic
> (dataProvider is Object) whereas in Basic is assumes the dataProvider is an
> Array.  And you can configure the Basic one to use different dataProviders
> of different types.  That's on purpose, for PAYG (no extra code to handle
> different types) and to help folks ensure type-safety.  But our users want
> less configuration so you can pass "anything" into Express DataGrid's
> dataProvider, just like Flex.
>

In Jewel, List has the problem that ICollectionView was not sufficient, so
it has an extension of that class to use ArrayList that seems to be the
normal use case.
But people can override that bead for general use or in a particular case.


> Doubling no, jut one: Foundation - Basic. The rest is up to
> discussion, but
> since are not required right now (are already not linked or mandatory)
> like
> MDL, CreateJS, and more, I'm fine with it. I recommend in the future
> refactor as well, but that should be made by volunteers if they want
>
> I think that's inconsistent.  If you agree above that some other component
> set can re-use Jewel Views, then you will need to break Jewel beads out
> into a separate SWC as well according to your arguments.  And that will
> double the number of SWCs.  Instead, I think we have ways to use the
> current organization to address your concerns about extra CSS processing.
>
>

I think there's a misunderstanding here. Let's see If I can explain what I
really want to mean: Right now Basic has all code needed to build a UI Set
plus, the concrete implementation of that UI Set plus a CSS that wires all
of it in a concrete waty. I think that's not right. If you extract all
reusable code to Foundation library, you'll get with a library (Basic) with
just TLCs and CSS, and that library will have exact same pieces than
(Jewel), TLCs of that concrete implementation that are not reusable at all,
and CSS that wires a concrete setup of beads (in Core, Foundation and the
particular UI Set). As we said MDL or CreateJS are not our main target, so
other volunteers should take that into account if they want or leave it as
is, since the new setup supports it, while the old one is more restrictive
and we have no option to setup one wat or the other.


> But links all existing available libraries? when you program in C++ you
> link what you need. So in Royale there's no point to link a Basic UI
> Set
> (TLCs and CSS) if I'm going to not use it, but use another one.
>
> The user is in complete control over the number of SWCs that get read in,
> even for Ant, IDEs and command-line users.


That's not true in the old setup. The compiler process *reads* all CSS and
if we have not bugs nothing will end there. And more important, I 

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

[Alex Harui]

I'm replying to my post again even though it isn't the latest.At the end I 
address what I think is a misconception that I saw in those more recent posts.

>   We want these beads, even high level beads, to be re-usable in multiple
> components sets.


Key word here is *optional* not *mandatory*. Take this in mind, since while
I have the option to use it or not, I even should have the option to link
it or not, since there's no obligation or requeriment to use.

Everything is currently optional the way we have it, but the principle of code 
re-use is primary.  Copying code to avoid a project dependency is not a 
recommended practice.

> There may be a SuperJewel someday or variants on Jewel with completely
> different names that borrow beads from Jewel under the principle of
> re-using code.


That will requiere that SuperJewel links Jewel to use it, as well Express
need to link Basic. CreateJS does need to link Jewel, that will be
pointless.


> The Emulation set will probably use Jewel views.


Hope so, so MXRoyale will link Jewel since it needs, while Basic not since
it never will use it.

The Emulation set will use Basic beads for models and controllers and lots of 
other things, if the simple implementations suffice.

> Our users have asked for our component sets to require little
> configuration, so Jewel should re-use Express beads.
>

Can give an example of a reusable Express bead in Jewel. FWIK Express is an
aggregation of Basic UI Set, so it makes less need of configuration in
final code, so a Button can integrate Disabled bead. Don't have in mind a
reusable case of Express in Jewel, since Jewel doesn't use Basic at all.

I mentioned this before.  The DataGridModel in Express is type-agnostic 
(dataProvider is Object) whereas in Basic is assumes the dataProvider is an 
Array.  And you can configure the Basic one to use different dataProviders of 
different types.  That's on purpose, for PAYG (no extra code to handle 
different types) and to help folks ensure type-safety.  But our users want less 
configuration so you can pass "anything" into Express DataGrid's dataProvider, 
just like Flex.

>
> I think you are making the argument for doubling the number of SWCs so
> that beads go in a SWC and TLCs that use those beads go in a separate SWC.


Doubling no, jut one: Foundation - Basic. The rest is up to discussion, but
since are not required right now (are already not linked or mandatory) like
MDL, CreateJS, and more, I'm fine with it. I recommend in the future
refactor as well, but that should be made by volunteers if they want

I think that's inconsistent.  If you agree above that some other component set 
can re-use Jewel Views, then you will need to break Jewel beads out into a 
separate SWC as well according to your arguments.  And that will double the 
number of SWCs.  Instead, I think we have ways to use the current organization 
to address your concerns about extra CSS processing.


> There isn't an Apache Commons analogy for that since JARs are dynamically
> linked.  But in statically-linked libraries like C/C++ on Windows, the
> compiler does visit entire libraries and only links in what is needed.
>

But links all existing available libraries? when you program in C++ you
link what you need. So in Royale there's no point to link a Basic UI Set
(TLCs and CSS) if I'm going to not use it, but use another one.
   
The user is in complete control over the number of SWCs that get read in, even 
for Ant, IDEs and command-line users.  The compiler only reads in the SWCs it 
is told to read in.  The default royale-config.xml currently uses a wildcard.  
Will it always?  Maybe not if we someday have enough SWCs that reading them all 
in becomes a problem.   If you specify the exact set of SWCs that you would in 
a Maven pom, you will enjoy the same benefits of the compiler only reading 
those SWCs, if any.  It is simply a trade-off of configuration effort vs 
compile-time.  Also having more SWCs get loaded should mean more options 
offered in code-hinting which is, IMO a good thing for now, but probably not in 
the future.  So, don't be worried about how many SWCs get read in.  Users can 
control that.

I am going to try to move the exclude-defaults-css to the loading phase instead 
of the output phase.  I think once I finish that and Harbs finishes removing 
class selectors we can see if there are any remaining issues or concerns with 
the current set of libraries.

HTH,
-Alex

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

[Carlos Rovira]

Hi Harbs

2018-05-31 15:10 GMT+02:00 Harbs :

> I’m not sure if we’re communicating.
>
> Composite TLCs have many pieces and only some of them are related to View.
> DataGrid has 5 class reference and only one is IBeadView. DataGrid uses
> DataGridColumnList which has 9 class references. One is view and another
> which might (or might not) need replacement is layout. Other than these
> classes, the whole component should just work as-is in Jewel. All you need
> is to swap out the IBeadView and/or part of the view.
>

What I said is that we'll need at least "DataGrid" in Jewel SWC, then most
of the pieces in Basic will be reused (so I expect it to be in a shared
SWC, what I call Foundation). Then DataGridColumnList will be needed in
Jewel as well, but extending jewel List. DataGridButtonBar will extend
ButtonBar from Jewel, when this exits.
For example IDataGridColumn will be taken from Basic as well DataGridModel.
DataGridView will be implemented in Jewel
So, all that I can reuse, will be reused. No sense to duplicate code if can
avoid that.
So as you see is not the whole component, is not possible, but I think a
decent part will be shared.


>
> We *would* need to make sure that the swapped view classes are not
> imported unnecessarily.


That is easy to do making separation.
The opposite will be really hard since you'll find here and there points
hidden. I didn't see many problems until current separation shows the
problems in compilation.
I think that can only be accomplished by separation for sure. If not is a
finger to the wind ;)


> (I’m not sure if they are or not.) If they are, I think it’s clear that is
> a bug which needs to be fixed no-matter. Defaults should not be imported if
> overridden by applications.
>

Right bugs must be fixed, but a fixed bug doesn't mind we should avoid
setup things in the right way. We should want to pursue both.


>
> Maybe we should wait on this decision until Jewel is more complete? It’s
> possible that you are right and none of the TLCs will end up in Jewel. It’s
> possible I’m right and they will. I don’t see how restructuring Basic is
> necessary until we’re sure of the outcome of that.
>

The problem I see is that If I want to work on the next component, I'll
need to move things from Basic to Core, or make the intermediate Foundation
library, if not I'll be duplicating code that is not what we want. The good
point is that making Foundation SWC and moving pieces to it as I work on
Jewel should not impact current state of Royale, we only need to add the
dependency. The rename we plan to do is what will cause users to update
code.





>
> Thoughts?
> Harbs
>
> > On May 31, 2018, at 2:10 PM, Carlos Rovira 
> wrote:
> >
> >> 2, Composite TLCs are components such as ComboBox, DataGrid, possibly
> >> ImageButon etc. The components are basically UIBase components which
> >> describe how the pieces are wired together. The views are separate
> >> components that are declared. For these TLCs, there shouldn’t be a need
> to
> >> duplicate the classes or subclass the classes in Jewel at all. It
> should be
> >> possible to simply use Basic or Express composite TLCs and simply
> declare a
> >> Jewel view to use with them.
> >>
> >>
> > yes, if you are seeing that the compositing TLCs are Jewel TLCs. For
> > example, ComboBox will compose a Jewel Button not Basic Button, to comply
> > with the overall set and purpose. As well will compose a TextInput and a
> > List from Jewel, not from Basic. Take into account that the first thing a
> > Jewel TLC (basic or complex) will do is set typeNames in constructor to
> > "jewel XXX", and then define "component parts" like button:Button (of
> Jewel
> > set).
> >
> > Image Button will as well composite a Jewel Button. DataGrid is a complex
> > TLC that will be using jewel TLCs and other build blocks currently in
> > Basic, that should move to Foundation (or whatever we want to call to
> > "reusable library with common code and beads").
> >
> > What is clear is that all pieces that are reusable in ComboBox, DataGrid
> or
> > ImageButton will be used to create those components in Jewel, as many as
> we
> > can.
> > All those components will have its own Jewel view to make its own
> visuals,
> > like SliderView in jewel needs that code that is different to basic one
> > since it "fills" the bar as we move the thumb.
> >
> >
> >
> >> Is there an issue that I’m missing here?
> >>
> >> Harbs
> >>
> >>> On May 31, 2018, at 12:12 PM, Carlos Rovira 
> >> wrote:
> >>>
> >>> Hi Harbs,
> >>>
> >>> concreting more over if Jewel should or not extend Basic TLCs. That I
> >> think
> >>> is the real point now to discuss. I'm sure it should not be the case.
> To
> >>> sum to all that I exposed, it was not clearly sufficient enough (that I
> >>> think it should be). Why I want all the class definitions overhead it
> >> will
> >>> cause?
> >>>
> >>> Why have the basic Button file with all the class text definitions and
> >> then
> >>> the jewel Button 

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

[Harbs]

I’m not sure if we’re communicating.

Composite TLCs have many pieces and only some of them are related to View. 
DataGrid has 5 class reference and only one is IBeadView. DataGrid uses 
DataGridColumnList which has 9 class references. One is view and another which 
might (or might not) need replacement is layout. Other than these classes, the 
whole component should just work as-is in Jewel. All you need is to swap out 
the IBeadView and/or part of the view.

We *would* need to make sure that the swapped view classes are not imported 
unnecessarily. (I’m not sure if they are or not.) If they are, I think it’s 
clear that is a bug which needs to be fixed no-matter. Defaults should not be 
imported if overridden by applications.

Maybe we should wait on this decision until Jewel is more complete? It’s 
possible that you are right and none of the TLCs will end up in Jewel. It’s 
possible I’m right and they will. I don’t see how restructuring Basic is 
necessary until we’re sure of the outcome of that.

Thoughts?
Harbs

> On May 31, 2018, at 2:10 PM, Carlos Rovira  wrote:
> 
>> 2, Composite TLCs are components such as ComboBox, DataGrid, possibly
>> ImageButon etc. The components are basically UIBase components which
>> describe how the pieces are wired together. The views are separate
>> components that are declared. For these TLCs, there shouldn’t be a need to
>> duplicate the classes or subclass the classes in Jewel at all. It should be
>> possible to simply use Basic or Express composite TLCs and simply declare a
>> Jewel view to use with them.
>> 
>> 
> yes, if you are seeing that the compositing TLCs are Jewel TLCs. For
> example, ComboBox will compose a Jewel Button not Basic Button, to comply
> with the overall set and purpose. As well will compose a TextInput and a
> List from Jewel, not from Basic. Take into account that the first thing a
> Jewel TLC (basic or complex) will do is set typeNames in constructor to
> "jewel XXX", and then define "component parts" like button:Button (of Jewel
> set).
> 
> Image Button will as well composite a Jewel Button. DataGrid is a complex
> TLC that will be using jewel TLCs and other build blocks currently in
> Basic, that should move to Foundation (or whatever we want to call to
> "reusable library with common code and beads").
> 
> What is clear is that all pieces that are reusable in ComboBox, DataGrid or
> ImageButton will be used to create those components in Jewel, as many as we
> can.
> All those components will have its own Jewel view to make its own visuals,
> like SliderView in jewel needs that code that is different to basic one
> since it "fills" the bar as we move the thumb.
> 
> 
> 
>> Is there an issue that I’m missing here?
>> 
>> Harbs
>> 
>>> On May 31, 2018, at 12:12 PM, Carlos Rovira 
>> wrote:
>>> 
>>> Hi Harbs,
>>> 
>>> concreting more over if Jewel should or not extend Basic TLCs. That I
>> think
>>> is the real point now to discuss. I'm sure it should not be the case. To
>>> sum to all that I exposed, it was not clearly sufficient enough (that I
>>> think it should be). Why I want all the class definitions overhead it
>> will
>>> cause?
>>> 
>>> Why have the basic Button file with all the class text definitions and
>> then
>>> the jewel Button file with all the definitions there? Think that we don't
>>> get anything profitable from all that overhead. I think that reusable
>> code
>>> are pieces to construct, but not pieces designed to be final in some
>> case.
>>> So to build a house I use bricks, cement, beams, and so on, but then I
>>> don't use the house to make a castle.
>>> 
>>> Moreover, think that Basic needs to change some component part...then
>> maybe
>>> Jewel can't do that... that's a huge problem. So think that in the house
>> I
>>> want to change a window from a place to another, then the castle will
>> need
>>> to live with that without any reason and possibility to not be affected.
>>> 
>>> You must to recognize that although the theory here is good (remember
>> that
>>> I started to be aligned with that), the reality is not the same.
>>> 
>>> My experience in many things in life make think that not all is 100%
>> black
>>> or white. I think is great the philosophy we have on PAYG, beads and
>> reuse,
>>> but I the case of TLCs and see that as something optionally extendible,
>> but
>>> not mandatory. Or in other words TLCs are almost a leaf usable component
>>> that is mainly designed with a concrete end or use, and work great in
>>> aggregation (i.e: Express), but should not be part of any mandatory use.
>>> It's building blocks, in opposite, (the bricks) need to be enforced to
>>> reuse as much as we can.
>>> 
>>> Hope this additional vision will help on the overall discussion.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 2018-05-31 10:05 GMT+02:00 Harbs :
>>> 
 Comments inline.
 
> On May 31, 2018, at 10:44 AM, Carlos Rovira 
 wrote:
> 
> I think there's a cost, don't know if the cost is higher or lower.
 

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

[Carlos Rovira]

Hi,

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

> To me, there are two classes of TLCs.
>
> 1. Simple TLCs are components such as Button, Checkbox, DropDownList etc.
> Which are designed to represent a single HTML element. For these components
> I completely understand and agree with your decision to *NOT* subclass
> Basic TLCs. The styling paradigm is different. We don’t want to bring in
> the superclass CSS, etc. We are in agreement here.
>

Right, agree too


>
> 2, Composite TLCs are components such as ComboBox, DataGrid, possibly
> ImageButon etc. The components are basically UIBase components which
> describe how the pieces are wired together. The views are separate
> components that are declared. For these TLCs, there shouldn’t be a need to
> duplicate the classes or subclass the classes in Jewel at all. It should be
> possible to simply use Basic or Express composite TLCs and simply declare a
> Jewel view to use with them.
>
>
yes, if you are seeing that the compositing TLCs are Jewel TLCs. For
example, ComboBox will compose a Jewel Button not Basic Button, to comply
with the overall set and purpose. As well will compose a TextInput and a
List from Jewel, not from Basic. Take into account that the first thing a
Jewel TLC (basic or complex) will do is set typeNames in constructor to
"jewel XXX", and then define "component parts" like button:Button (of Jewel
set).

Image Button will as well composite a Jewel Button. DataGrid is a complex
TLC that will be using jewel TLCs and other build blocks currently in
Basic, that should move to Foundation (or whatever we want to call to
"reusable library with common code and beads").

What is clear is that all pieces that are reusable in ComboBox, DataGrid or
ImageButton will be used to create those components in Jewel, as many as we
can.
All those components will have its own Jewel view to make its own visuals,
like SliderView in jewel needs that code that is different to basic one
since it "fills" the bar as we move the thumb.



> Is there an issue that I’m missing here?
>
> Harbs
>
> > On May 31, 2018, at 12:12 PM, Carlos Rovira 
> wrote:
> >
> > Hi Harbs,
> >
> > concreting more over if Jewel should or not extend Basic TLCs. That I
> think
> > is the real point now to discuss. I'm sure it should not be the case. To
> > sum to all that I exposed, it was not clearly sufficient enough (that I
> > think it should be). Why I want all the class definitions overhead it
> will
> > cause?
> >
> > Why have the basic Button file with all the class text definitions and
> then
> > the jewel Button file with all the definitions there? Think that we don't
> > get anything profitable from all that overhead. I think that reusable
> code
> > are pieces to construct, but not pieces designed to be final in some
> case.
> > So to build a house I use bricks, cement, beams, and so on, but then I
> > don't use the house to make a castle.
> >
> > Moreover, think that Basic needs to change some component part...then
> maybe
> > Jewel can't do that... that's a huge problem. So think that in the house
> I
> > want to change a window from a place to another, then the castle will
> need
> > to live with that without any reason and possibility to not be affected.
> >
> > You must to recognize that although the theory here is good (remember
> that
> > I started to be aligned with that), the reality is not the same.
> >
> > My experience in many things in life make think that not all is 100%
> black
> > or white. I think is great the philosophy we have on PAYG, beads and
> reuse,
> > but I the case of TLCs and see that as something optionally extendible,
> but
> > not mandatory. Or in other words TLCs are almost a leaf usable component
> > that is mainly designed with a concrete end or use, and work great in
> > aggregation (i.e: Express), but should not be part of any mandatory use.
> > It's building blocks, in opposite, (the bricks) need to be enforced to
> > reuse as much as we can.
> >
> > Hope this additional vision will help on the overall discussion.
> >
> >
> >
> >
> >
> > 2018-05-31 10:05 GMT+02:00 Harbs :
> >
> >> Comments inline.
> >>
> >>> On May 31, 2018, at 10:44 AM, Carlos Rovira 
> >> wrote:
> >>>
> >>> I think there's a cost, don't know if the cost is higher or lower.
> >>
> >> My question is whether we would actually be avoiding this cost by
> pulling
> >> the CSS out of Basic. I don’t know the answer to this question. I
> suspect
> >> that the compiler needs to analyze all the CSS files in every swc in the
> >> libs folder whether they are used or not. If that’s the case, there’s
> >> nothing to gain by pulling out the CSS for at least 90% of the use
> cases of
> >> Royale. Almost all Royale users will have the full lib of swcs.
> >>
> >>> To me is
> >>> not only the cost, is about as well as methodology. For me is incorrect
> >> to
> >>> have a CSS always be compiled, no matter what kind of application I'll
> be
> >>> constructing, even if nothing of that CSS goes into the 

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

[Harbs]

To me, there are two classes of TLCs.

1. Simple TLCs are components such as Button, Checkbox, DropDownList etc. Which 
are designed to represent a single HTML element. For these components I 
completely understand and agree with your decision to *NOT* subclass Basic 
TLCs. The styling paradigm is different. We don’t want to bring in the 
superclass CSS, etc. We are in agreement here.

2, Composite TLCs are components such as ComboBox, DataGrid, possibly 
ImageButon etc. The components are basically UIBase components which describe 
how the pieces are wired together. The views are separate components that are 
declared. For these TLCs, there shouldn’t be a need to duplicate the classes or 
subclass the classes in Jewel at all. It should be possible to simply use Basic 
or Express composite TLCs and simply declare a Jewel view to use with them.

Is there an issue that I’m missing here?

Harbs

> On May 31, 2018, at 12:12 PM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> concreting more over if Jewel should or not extend Basic TLCs. That I think
> is the real point now to discuss. I'm sure it should not be the case. To
> sum to all that I exposed, it was not clearly sufficient enough (that I
> think it should be). Why I want all the class definitions overhead it will
> cause?
> 
> Why have the basic Button file with all the class text definitions and then
> the jewel Button file with all the definitions there? Think that we don't
> get anything profitable from all that overhead. I think that reusable code
> are pieces to construct, but not pieces designed to be final in some case.
> So to build a house I use bricks, cement, beams, and so on, but then I
> don't use the house to make a castle.
> 
> Moreover, think that Basic needs to change some component part...then maybe
> Jewel can't do that... that's a huge problem. So think that in the house I
> want to change a window from a place to another, then the castle will need
> to live with that without any reason and possibility to not be affected.
> 
> You must to recognize that although the theory here is good (remember that
> I started to be aligned with that), the reality is not the same.
> 
> My experience in many things in life make think that not all is 100% black
> or white. I think is great the philosophy we have on PAYG, beads and reuse,
> but I the case of TLCs and see that as something optionally extendible, but
> not mandatory. Or in other words TLCs are almost a leaf usable component
> that is mainly designed with a concrete end or use, and work great in
> aggregation (i.e: Express), but should not be part of any mandatory use.
> It's building blocks, in opposite, (the bricks) need to be enforced to
> reuse as much as we can.
> 
> Hope this additional vision will help on the overall discussion.
> 
> 
> 
> 
> 
> 2018-05-31 10:05 GMT+02:00 Harbs :
> 
>> Comments inline.
>> 
>>> On May 31, 2018, at 10:44 AM, Carlos Rovira 
>> wrote:
>>> 
>>> I think there's a cost, don't know if the cost is higher or lower.
>> 
>> My question is whether we would actually be avoiding this cost by pulling
>> the CSS out of Basic. I don’t know the answer to this question. I suspect
>> that the compiler needs to analyze all the CSS files in every swc in the
>> libs folder whether they are used or not. If that’s the case, there’s
>> nothing to gain by pulling out the CSS for at least 90% of the use cases of
>> Royale. Almost all Royale users will have the full lib of swcs.
>> 
>>> To me is
>>> not only the cost, is about as well as methodology. For me is incorrect
>> to
>>> have a CSS always be compiled, no matter what kind of application I'll be
>>> constructing, even if nothing of that CSS goes into the final
>> Application.
>>> You're making a useless compilation, that can introduce bugs or not, or
>> you
>>> must keep and eye always that is not doing wrong things. If you don't put
>>> that CSS in mandatory SWC, your problems are all gone. I think CSS should
>>> be *always* in optional SWCs. For me maybe this is the most important
>>> concept or rule we should follow.
>> 
>> In theory, I agree with you. In practice, I’m not so sure.
>> 
>> The problem with pulling the TLC components out of Basic is that it
>> requires a separate dependency for use. That makes more work for someone
>> using Maven (for example). Also the likelihood of NONE of the TLCs to be
>> used by other component sets is slim. I believe that Basic (or Express)
>> composite components (such as ComboBox, DataGrid, etc.) should be used in
>> Jewel and just the views should be swapped out. Dictating that Jewel can’t
>> use Basic TLCs simply on principle is something I have a hard time with.
>> 
>> If using them would have a concrete negative effect on an app, I agree
>> that it would be a problem, but I think we’ve determined that to not be the
>> case.
>> 
>> Thanks,
>> Harbs
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

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

[Carlos Rovira]

Hi Harbs,

concreting more over if Jewel should or not extend Basic TLCs. That I think
is the real point now to discuss. I'm sure it should not be the case. To
sum to all that I exposed, it was not clearly sufficient enough (that I
think it should be). Why I want all the class definitions overhead it will
cause?

Why have the basic Button file with all the class text definitions and then
the jewel Button file with all the definitions there? Think that we don't
get anything profitable from all that overhead. I think that reusable code
are pieces to construct, but not pieces designed to be final in some case.
So to build a house I use bricks, cement, beams, and so on, but then I
don't use the house to make a castle.

Moreover, think that Basic needs to change some component part...then maybe
Jewel can't do that... that's a huge problem. So think that in the house I
want to change a window from a place to another, then the castle will need
to live with that without any reason and possibility to not be affected.

You must to recognize that although the theory here is good (remember that
I started to be aligned with that), the reality is not the same.

My experience in many things in life make think that not all is 100% black
or white. I think is great the philosophy we have on PAYG, beads and reuse,
but I the case of TLCs and see that as something optionally extendible, but
not mandatory. Or in other words TLCs are almost a leaf usable component
that is mainly designed with a concrete end or use, and work great in
aggregation (i.e: Express), but should not be part of any mandatory use.
It's building blocks, in opposite, (the bricks) need to be enforced to
reuse as much as we can.

Hope this additional vision will help on the overall discussion.





2018-05-31 10:05 GMT+02:00 Harbs :

> Comments inline.
>
> > On May 31, 2018, at 10:44 AM, Carlos Rovira 
> wrote:
> >
> > I think there's a cost, don't know if the cost is higher or lower.
>
> My question is whether we would actually be avoiding this cost by pulling
> the CSS out of Basic. I don’t know the answer to this question. I suspect
> that the compiler needs to analyze all the CSS files in every swc in the
> libs folder whether they are used or not. If that’s the case, there’s
> nothing to gain by pulling out the CSS for at least 90% of the use cases of
> Royale. Almost all Royale users will have the full lib of swcs.
>
> > To me is
> > not only the cost, is about as well as methodology. For me is incorrect
> to
> > have a CSS always be compiled, no matter what kind of application I'll be
> > constructing, even if nothing of that CSS goes into the final
> Application.
> > You're making a useless compilation, that can introduce bugs or not, or
> you
> > must keep and eye always that is not doing wrong things. If you don't put
> > that CSS in mandatory SWC, your problems are all gone. I think CSS should
> > be *always* in optional SWCs. For me maybe this is the most important
> > concept or rule we should follow.
>
> In theory, I agree with you. In practice, I’m not so sure.
>
> The problem with pulling the TLC components out of Basic is that it
> requires a separate dependency for use. That makes more work for someone
> using Maven (for example). Also the likelihood of NONE of the TLCs to be
> used by other component sets is slim. I believe that Basic (or Express)
> composite components (such as ComboBox, DataGrid, etc.) should be used in
> Jewel and just the views should be swapped out. Dictating that Jewel can’t
> use Basic TLCs simply on principle is something I have a hard time with.
>
> If using them would have a concrete negative effect on an app, I agree
> that it would be a problem, but I think we’ve determined that to not be the
> case.
>
> Thanks,
> Harbs
>
>


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

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

[Harbs]

Comments inline.

> On May 31, 2018, at 10:44 AM, Carlos Rovira  wrote:
> 
> I think there's a cost, don't know if the cost is higher or lower.

My question is whether we would actually be avoiding this cost by pulling the 
CSS out of Basic. I don’t know the answer to this question. I suspect that the 
compiler needs to analyze all the CSS files in every swc in the libs folder 
whether they are used or not. If that’s the case, there’s nothing to gain by 
pulling out the CSS for at least 90% of the use cases of Royale. Almost all 
Royale users will have the full lib of swcs.

> To me is
> not only the cost, is about as well as methodology. For me is incorrect to
> have a CSS always be compiled, no matter what kind of application I'll be
> constructing, even if nothing of that CSS goes into the final Application.
> You're making a useless compilation, that can introduce bugs or not, or you
> must keep and eye always that is not doing wrong things. If you don't put
> that CSS in mandatory SWC, your problems are all gone. I think CSS should
> be *always* in optional SWCs. For me maybe this is the most important
> concept or rule we should follow.

In theory, I agree with you. In practice, I’m not so sure.

The problem with pulling the TLC components out of Basic is that it requires a 
separate dependency for use. That makes more work for someone using Maven (for 
example). Also the likelihood of NONE of the TLCs to be used by other component 
sets is slim. I believe that Basic (or Express) composite components (such as 
ComboBox, DataGrid, etc.) should be used in Jewel and just the views should be 
swapped out. Dictating that Jewel can’t use Basic TLCs simply on principle is 
something I have a hard time with.

If using them would have a concrete negative effect on an app, I agree that it 
would be a problem, but I think we’ve determined that to not be the case.

Thanks,
Harbs

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

[Carlos Rovira]

I think there's a cost, don't know if the cost is higher or lower. To me is
not only the cost, is about as well as methodology. For me is incorrect to
have a CSS always be compiled, no matter what kind of application I'll be
constructing, even if nothing of that CSS goes into the final Application.
You're making a useless compilation, that can introduce bugs or not, or you
must keep and eye always that is not doing wrong things. If you don't put
that CSS in mandatory SWC, your problems are all gone. I think CSS should
be *always* in optional SWCs. For me maybe this is the most important
concept or rule we should follow.

2018-05-31 9:05 GMT+02:00 Harbs :

> The point of analyzing css is one I hadn’t thought of.
>
> I’m a bit unclear on how the compiler deals with Framework CSS files. How
> does the compiler know which CSS files it needs to examine?
>
> Most compiler methods use royalelib which points to a folder with all the
> Royale swcs. Does it make a difference whether a specific swc is actually
> used?
>
> Unless you are using Maven, the full set of framework libs will always be
> downloaded. If Maven caches a particular sac, would that be in the royale
> lib path as well?
>
> What is the performance hit on analyzing a swc css file? If we’re talking
> a few ms or less, I don’t think it’s worth worrying about.
>
> Thanks,
> Harbs
>
> > On May 31, 2018, at 9:02 AM, Carlos Rovira 
> wrote:
> >
> >> I see a claim that there is a problem because of the compiler parsing a
> >> CSS file from a SWC where that CSS will not be used.  Is there proof
> that
> >> it is a significant performance problem?  Such a claim should be backed
> by
> >> data from an experiment by making the Basic defaults.css one blank line
> and
> >> see if compile time of a Jewel-only example speeds up in a significant
> >> way.  Also, we already have an -exclude-defaults-css-files option.  It
> >> currently does not prevent parsing of the CSS file, but we could make it
> >> so.
> >
> >
> > I don't say it was a performance issue, I said that is no point in
> process
> > a CSS that will never be use.
> > As well if exclude option continues parsing the CSS, seems a bit
> incomplete
> > right?
>
>


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

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

[Carlos Rovira]

great thanks! :)

2018-05-31 8:50 GMT+02:00 Harbs :

> I’m planning on working on this.
>
> I think it’s very solvable.
>
> > On May 31, 2018, at 9:02 AM, Carlos Rovira 
> wrote:
> >
> >>
> >> I believe we still need a volunteer to change the royale-asjs code to
> >> eliminate use of class selectors in its defaults.css files.
> >>
> >
> > I think this should be done by someone like Peter that is more aware of
> the
> > implications on that part.
>
>


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

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

[Harbs]

The point of analyzing css is one I hadn’t thought of.

I’m a bit unclear on how the compiler deals with Framework CSS files. How does 
the compiler know which CSS files it needs to examine?

Most compiler methods use royalelib which points to a folder with all the 
Royale swcs. Does it make a difference whether a specific swc is actually used?

Unless you are using Maven, the full set of framework libs will always be 
downloaded. If Maven caches a particular sac, would that be in the royale lib 
path as well?

What is the performance hit on analyzing a swc css file? If we’re talking a few 
ms or less, I don’t think it’s worth worrying about.

Thanks,
Harbs

> On May 31, 2018, at 9:02 AM, Carlos Rovira  wrote:
> 
>> I see a claim that there is a problem because of the compiler parsing a
>> CSS file from a SWC where that CSS will not be used.  Is there proof that
>> it is a significant performance problem?  Such a claim should be backed by
>> data from an experiment by making the Basic defaults.css one blank line and
>> see if compile time of a Jewel-only example speeds up in a significant
>> way.  Also, we already have an -exclude-defaults-css-files option.  It
>> currently does not prevent parsing of the CSS file, but we could make it
>> so.
> 
> 
> I don't say it was a performance issue, I said that is no point in process
> a CSS that will never be use.
> As well if exclude option continues parsing the CSS, seems a bit incomplete
> right?

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

[Harbs]

I’m planning on working on this.

I think it’s very solvable.

> On May 31, 2018, at 9:02 AM, Carlos Rovira  wrote:
> 
>> 
>> I believe we still need a volunteer to change the royale-asjs code to
>> eliminate use of class selectors in its defaults.css files.
>> 
> 
> I think this should be done by someone like Peter that is more aware of the
> implications on that part.

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

[Alex Harui]

Hi Carlos, 

I'm replying to all posts on this thread since my last post.

I see a claim that there is a problem because of the compiler parsing a CSS 
file from a SWC where that CSS will not be used.  Is there proof that it is a 
significant performance problem?  Such a claim should be backed by data from an 
experiment by making the Basic defaults.css one blank line and see if compile 
time of a Jewel-only example speeds up in a significant way.  Also, we already 
have an -exclude-defaults-css-files option.  It currently does not prevent 
parsing of the CSS file, but we could make it so.  As of last week or so, I 
believe the royale-compiler develop branch contains all fixes that caused 
unused selectors from themes ending up in the final app.  I believe we still 
need a volunteer to change the royale-asjs code to eliminate use of class 
selectors in its defaults.css files.

In a composition-based component framework, a dependency graph that looks like 
it is hierarchical should not be a goal.  We want these beads, even high level 
beads, to be re-usable in multiple components sets.  There may be a SuperJewel 
someday or variants on Jewel with completely different names that borrow beads 
from Jewel under the principle of re-using code.  The Emulation set will 
probably use Jewel views.  Our users have asked for our component sets to 
require little configuration, so Jewel should re-use Express beads.

The beads should be collected into SWCs that organize what they do, much like 
Apache Commons.  I don’t think Java projects try to only use one Apache Commons 
JAR because of a cleaner dependency graph.

I think you are making the argument for doubling the number of SWCs so that 
beads go in a SWC and TLCs that use those beads go in a separate SWC.  If 
that's what folks want to do, that's fine, but I don't think that will be the 
right decision.  It will mean you have to list two things in each pom.xml 
instead of one.  It will take longer for component developers to go back and 
fix something in the bead project and then in the TLC project.  Third-parties 
have to deploy two SWCs.  Folks can't just grab a SWC and use it, they have to 
grab two.

Again think about the analogy of Apache Commons.  It is not one giant library, 
but a set of libraries.  And for sure, if you only use one method out of seven 
different Commons libraries the compiler spent time reading the entirety of 
those 7 libraries, but you don't want to make the libraries too fine-grained 
either.  Libraries are organized by common traits to help users figure out 
which ones to use, not an attempt to save compile time.

The key is that things not needed don't end up in the output.  There isn't an 
Apache Commons analogy for that since JARs are dynamically linked.  But in 
statically-linked libraries like C/C++ on Windows, the compiler does visit 
entire libraries and only links in what is needed.

I did notice a good point about code hinting in the IDEs.  IMO, the new IDEs 
will need to have smarter filtering of the options.  We need to think big, 
where lots of people are putting lots of SWCs on the various library-paths.  
Those of us who are currently committers are likely to only write a small 
fraction of the SWCs in the world in Royale is successful.  Unlike Flex, where 
we tried to get everyone to use MX or Spark, folks should have many more 
choices.   Flash Builder already has the option of disabling SWCs in a 
library-path.  I would encourage the IDE vendors to do the same.  And also 
realize that the MXML manifests allow mapping of a bead from one SWC into 
another MXML namespace, so I think folks should be encouraged to filter by 
typing the prefix of their active MXML namespaces first and then "Button".

Core used to contain UIBase, ListBase, GroupBase and some other base 
implementations of interfaces.  Then they moved to Basic during the wrapped 
Sprite experiment and never moved back.  So, I didn't have any problem with 
them moving back just now.  The reason they were in Core was to serve as a 
starting point for TLCs in other component sets.  Again, the key principle is 
code reuse.  If someone wants to do something very different and unrelated to 
the Flex-like nature of our main component sets, they can use those base 
classes.  But if more folks want to keep them in Basic I'm fine with that.

One closing comment:  The reason I think we are picky about the code in Jewel 
is because we want it to be the flagship component set for Royale (and I think 
we all thank you for getting the visuals to look so good) and thus it "must" 
display our recommended practices.  MDL and CreateJS will not receive the same 
scrutiny.  Anyone is welcome to create some other component set that isn't PAYG 
at all.  But the ones we are promoting as examples (Basic, Express, Jewel) 
should reflect our best practices.

My 2 cents,
-Alex



On 5/29/18, 10:52 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Alex,

   

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

[Carlos Rovira]

2018-05-30 16:59 GMT+02:00 Harbs :

> Before we go on, I just want to comment on this.
>
> First of all, Piotr regularly comments on code that I (and others) commit.
> He has very often raised good points which prompted me to fix things that
> would have otherwise gone unnoticed. I appreciate it very much. Alex has
> called me out on many issues as well. It causes me to better think about
> the code I write. I wouldn’t want it any other way.
>

I must say that I appreciate it as well. A lot. I think conversation to
raise points and make it better is always good. What I don't like is where
comment does not bring nothing new, but questions the validity of it. In
other words. If someone makes a new feature and people comment to say "what
if we do this or that", I think is very positive. If you comment to say
nothing that sums, I think it makes the opposite: it substract. So I use to
comment if I can help to improve, but if I can give some better point over
what people have done, I think is better not say anything since in that
case that devalues the work of another.


>
> We *should* be looking at each other's code. That’s what “Commit Then
> Review” is all about. If we have to hesitate before we point things out or
> if we get defensive when others ask us to do things differently than we
> thought to do at first, the quality of our work will suffer.
>

Agree


>
> Additionally, we’re not talking about looking at small changes with a
> magnifying glass here. We’re talking about major changes to the existing
> architecture of the framework. They might be warranted, but they might not.
> Discussing all the pertinent points is crucial to getting it right. If it
> takes more time, then that’s the cost of working together to reach
> consensus. Speed of coding might suffer a bit, but it will strengthen us as
> a community which is way more important. I want us *all* to come away from
> this discussion feeling like we're making the right decisions.
>

I think so, I think you did a good job here making a good analysis and
bringing good points. My vision is that the overall result has gained from
the sum of all views, since no body is right or wrong, and we can think
differently since we are different, and although we pursue the same goal we
can reach that goal taking different ways, so we must to be tolerant if
other work on something and we are not totally in favor of the way taken,
the other option is to make all the work alone, but that's would take as
all our lifes ;), and sure it would be not as better as joining forces.


>
> Are we on the same page here? I think this is important.
>

Totally for sure :)

thanks


>
> Thanks,
> Harbs
>
> > On May 30, 2018, at 5:17 PM, Carlos Rovira 
> wrote:
> >
> > I think so... but hope this resolves soon, I think this discussions
> should
> > be more agile and we shouldn't be looking with magnifying glass others
> > changes.
> > For example, I trust changes done by Alex, Piotr and yoursdo you
> think
> > I'm analyzing Combobox changes...no, don't understand a month of
> discussion
> > something that should be more coding than writing mails. So hope we'll be
> > getting to a close too :)
>
>


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

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

[Harbs]

Before we go on, I just want to comment on this.

First of all, Piotr regularly comments on code that I (and others) commit. He 
has very often raised good points which prompted me to fix things that would 
have otherwise gone unnoticed. I appreciate it very much. Alex has called me 
out on many issues as well. It causes me to better think about the code I 
write. I wouldn’t want it any other way.

We *should* be looking at each other's code. That’s what “Commit Then Review” 
is all about. If we have to hesitate before we point things out or if we get 
defensive when others ask us to do things differently than we thought to do at 
first, the quality of our work will suffer.

Additionally, we’re not talking about looking at small changes with a 
magnifying glass here. We’re talking about major changes to the existing 
architecture of the framework. They might be warranted, but they might not. 
Discussing all the pertinent points is crucial to getting it right. If it takes 
more time, then that’s the cost of working together to reach consensus. Speed 
of coding might suffer a bit, but it will strengthen us as a community which is 
way more important. I want us *all* to come away from this discussion feeling 
like we're making the right decisions.

Are we on the same page here? I think this is important.

Thanks,
Harbs

> On May 30, 2018, at 5:17 PM, Carlos Rovira  wrote:
> 
> I think so... but hope this resolves soon, I think this discussions should
> be more agile and we shouldn't be looking with magnifying glass others
> changes.
> For example, I trust changes done by Alex, Piotr and yoursdo you think
> I'm analyzing Combobox changes...no, don't understand a month of discussion
> something that should be more coding than writing mails. So hope we'll be
> getting to a close too :)

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

[Carlos Rovira]

Hi Harbs,

2018-05-30 15:26 GMT+02:00 Harbs :

> I’m taking out two snippets from what you write that I think might help
> bring us closer:
> >
> > Right, that should go to Foundation, not Basic
>
> What is the difference between “Foundation” and “Basic” other than name?
> We already have “Foundation”, but we call it “Basic”.
>

If you want we can callit Basic and BasicUI or something, I choose
Foundation since for me fits perfectly with what does, but the name is
secondary.


>
> If I’m understanding you correctly, the only difference between them is
> defaults.css and basic.css in themes. Other than that *everything* in Basic
> could be considered “Foundation”. Even top level components in Basic could
> be considered “Foundation” because they are designed to be bare-bones. Any
> components that don’t fit that description in Basic need to be fixed.
>

CSS is main point, but as well Button, Slider, TextInput. All leaf
implementations that make Basic to be Basic, and that are not needed by
other UI sets like Jewel.
MDL or CreateJS still needs them, so it can link Basic UI SWC, or make the
same Jewel has done. Since this is now optional and not mandatory.


>
> Why are we making such a big deal over two css files? Right now, they are
> causing inflated application sizes. But we’ve determined that to be a bug
> In Basic. We need to fix the bug regardless. As long as they don’t cause
> the application size to increase (and I’m proposing they shouldn’t), why do
> we care?


Since is not only CSS, and is absurd make people using Jewel to invest time
processing all CSS files that he will never use. I think there's plenty of
technical things I put on the table that this dependency fix, while the old
one doesn't.


> I don’t think we care that much whether we call it “Basic” or
> “Foundation”. Right?
>

Right! It's only a name I bring to make my explanation more easy to follow.
In this point I'm very flexible. I prefer Foundation since I think fits
better, while Basic seems to me "the most basic implementation", but, for
me the name is not blocking.
The only point blocking (for me) of all points we discussed this month is
trying to make Jewel link Basic.


>
>
>
> >>
> >> I think we have a disconnect here.
> >>
> >> Let’s take UIBase for example. UIBase has a lot of opinions on how
> things
> >> should be implemented. It gets its children from HTML nodes. It assumes
> >> that layout parents are not necessarily the immediate ones. It makes
> >> assumptions on what events need to be dispatched. etc. I don’t think
> that
> >> UIBase and friends belong in Core. In fact not every IUIBase even
> currently
> >> in the app are UIBase subclasses. IUIBase belongs in Core because it
> >> defines the function of a IUIBase. UIBase does not because it makes
> >> implementation assumptions.
> >>
> >
> > Here you and Alex think differently. I put UIBase in Core since was what
> > Alex suggested. Finaly I think we all think almost the same, but is
> > impossible to agree in 100% of things.
>
> Maybe, maybe not. I don’t remember Alex suggesting this, but I could have
> missed it. I don’t think there is any absolute right and wrong here, but we
> *do* need definitions we can all agree on. If UIBase (for example) should
> go in Core, then we need a definition that we can agree on and document
> which fits that and makes it clear exactly what should and what shouldn’t
> go in Core.
>

If you want I can search for it. I think it was about 2 months or so when
he point that UIBase should go to Core, and then in the same days, we
discussed as well about making component to not extend Basic ones, that was
that make me remove Basic dependency from Jewel.

Moreover, when I moved UIBase to Core no body was surprised since it was
just proposed and validated by Alex.


>
> > What we need to do is to move forward and continue build. We need to
> think
> > about what is important for each one so we can get the best of us (not
> > 100%). I for example was more for Core - Jewel, then you proposed
> > Foundation (not me, it was you, remember? I only put a name that seems
> > appropriate to me), so for me is ok.
>
> I was actually proposing something slightly different. I was proposing
> pulling the top level components of Basic (or CSS) into a separate library.
> I was only proposing that if we can’t fix the CSS issues which I think we
> can.
>

I think we should do both, but separation make fixing bugs not so crucial
and as well make all better, since we promote "options" and not
"obligations", so that makes Royale more flexible and powerful.


>
> >
> > What I'll never be in agreement is in having CSS that is processing bead
> > linking as a mandatory dependency for all the technical reasons exposed
>
> I completely agree with you on this. I thought that was clear from the CSS
> discussion.
>

So for making this possible, I doubt it could be done only by bug fixing,
and although you get to fix all bugs...think about processing all that CSS
for 

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

[Harbs]

I’m taking out two snippets from what you write that I think might help bring 
us closer:
> 
> Right, that should go to Foundation, not Basic

What is the difference between “Foundation” and “Basic” other than name? We 
already have “Foundation”, but we call it “Basic”.

If I’m understanding you correctly, the only difference between them is 
defaults.css and basic.css in themes. Other than that *everything* in Basic 
could be considered “Foundation”. Even top level components in Basic could be 
considered “Foundation” because they are designed to be bare-bones. Any 
components that don’t fit that description in Basic need to be fixed.

Why are we making such a big deal over two css files? Right now, they are 
causing inflated application sizes. But we’ve determined that to be a bug In 
Basic. We need to fix the bug regardless. As long as they don’t cause the 
application size to increase (and I’m proposing they shouldn’t), why do we 
care? I don’t think we care that much whether we call it “Basic” or 
“Foundation”. Right?



>> 
>> I think we have a disconnect here.
>> 
>> Let’s take UIBase for example. UIBase has a lot of opinions on how things
>> should be implemented. It gets its children from HTML nodes. It assumes
>> that layout parents are not necessarily the immediate ones. It makes
>> assumptions on what events need to be dispatched. etc. I don’t think that
>> UIBase and friends belong in Core. In fact not every IUIBase even currently
>> in the app are UIBase subclasses. IUIBase belongs in Core because it
>> defines the function of a IUIBase. UIBase does not because it makes
>> implementation assumptions.
>> 
> 
> Here you and Alex think differently. I put UIBase in Core since was what
> Alex suggested. Finaly I think we all think almost the same, but is
> impossible to agree in 100% of things.

Maybe, maybe not. I don’t remember Alex suggesting this, but I could have 
missed it. I don’t think there is any absolute right and wrong here, but we 
*do* need definitions we can all agree on. If UIBase (for example) should go in 
Core, then we need a definition that we can agree on and document which fits 
that and makes it clear exactly what should and what shouldn’t go in Core.

> What we need to do is to move forward and continue build. We need to think
> about what is important for each one so we can get the best of us (not
> 100%). I for example was more for Core - Jewel, then you proposed
> Foundation (not me, it was you, remember? I only put a name that seems
> appropriate to me), so for me is ok.

I was actually proposing something slightly different. I was proposing pulling 
the top level components of Basic (or CSS) into a separate library. I was only 
proposing that if we can’t fix the CSS issues which I think we can.

> 
> What I'll never be in agreement is in having CSS that is processing bead
> linking as a mandatory dependency for all the technical reasons exposed

I completely agree with you on this. I thought that was clear from the CSS 
discussion.

> I think that is not in opposite of the rest of things you want, only for
> one of them, make all UI sets extend Basic classes, but I have a design
> rule in Jewel that is not extend Basic classes, so how we deal with that?

Basic classes, or Basic Top Level Components? I don’t see any reason why you 
should be avoiding anything other than TLCs which are specified in CSS and has 
different typeNames than Jewel ones.

> Should I continue as Piotr proposed in a fork and abandone Royale as others
> did? Or can we go forward and take the best of what all think?

Definitely work this through. :-) I think we can come to an agreement. I think 
we’re not so far apart.

Thanks,
Harbs

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

[Piotr Zarzycki]

Hi,

Just respond to that part.

"Moreover, in the IDE if you hit CTRL+SPACE, when using Jewel, do you want
to see 5-6 Button references off all linked UI sets? I don't think so
I want the IDE to be quick, and to show only what I chooses, the Jewel
Button, an not lots of options that I don't choose."

You will always see all Buttons in IDE VSCode and Moonshine because you are
pointing whole SDK.
You won't avoid that part. No matter whether you have Basic or not in Jewel.

However we will have in VSCode and Moonshine prefixes j:Button, js:Button.

Thanks,
Piotr

On Wed, May 30, 2018, 1:32 PM Carlos Rovira  wrote:

> Hi Harbs,
>
> 2018-05-30 11:49 GMT+02:00 Harbs :
>
> > I’m responding to this email because it has the most points I want to
> > respond to.
> >
> > I’m pulling out the particular quotes that I think are most relevant to
> > the discussion.
> >
> > >
> > >> 2. A “base” component set to use (or partially use) for composition.
> > >>
> > >
> > > Take into account that Jewel does not subclass any component in Basic.
> > MDL
> > > should not do it, since extend a control from basic really does not
> bring
> > > it nothing. I did in that way since at that time I was young in
> creating
> > UI
> > > sets, but I never was completely happy of that way. But, again, both
> > models
> > > make possible to extend a set and create a new one from that point, but
> > > yours make that mandatory, so for me less flexible.
> >
> > I don’t understand what you mean by less flexible. I think it’s more so.
> > You say that Jewel is not using Basic, but I don’t see that. I work much
> > better with concrete examples, so let me try:
> >
> > 1. Jewel currently has 8 model classes which are copies from Basic.
> Models
> > should be component set agnostic and if we need to copy them from one
> > component set to another, we’re doing something wrong. These models
> should
> > be either in Basic or some other “Foundation” lib.
> >
>
> Right, that should go to Foundation, not Basic, for all the models to
> share, others are now copies, but not in the future. Take into account that
> right now I did some copies just to put in place things, but this
> disscussion makes me stop my development flow.
>
>
> > 2. Controllers. I think you copied controllers as well. Controllers might
> > also be in a “foundation” lib, but that “feels” like less of a good fit.
> >
>
> Right
>
>
> > 3. Beads. Right now, the only bead I see is TextPrompt. I don’t see any
> > reason to copy that. It’s also dependent on the implementation of the
> > component set, so putting that in “foundation” does not feel right.
> >
>
> Right...so you see know the problem, don't understand why you want we pass
> all through Basic...you're describing the problem in your own words :?
>
>
> > 4. Right now, Jewel does not have many composite components, so there’s
> > very little in terms of components that it can use from Basic. However,
> as
> > that is built out, I think it will make more sense to use Basic
> components.
> > Most of the Basic components are built with separate views. This is very
> > important for the more complex ones. I’m going to focus on a few specific
> > components to try and make my point.
> >a. List. Even a component such as List seems like it would make more
> > sense to use the Basic one. The only reason I can see to use a different
> > class is to prevent basic List css and to set the correct typeNames. The
> > actual appearance of the list is handled by the view which should likely
> be
> > different in Jewel. How can we use a Basic List? Possibly we will be able
> > to improve the compiler to be smarter about how it pulls in CSS. Possibly
> > we should have a ListBase which contains almost all the code and the List
> > in each component set subclasses that.
> >b. ComboBox. Right now combobox is a bit broken architecturally. I’m
> > working on fixing it, but it’s conceptually a composite component
> > containing a button, a component which displays the selected item and
> > possibly take input, and a List for the dropdown. Ideally, different
> > component sets should use the ComboBox component as-is, and specify
> > different components for the pieces of the view.
> >c. DataGrid. Rebuilding the entire DataGrid hierarchy for separate
> > component sets seems very wasteful and error-prone. The visuals of the
> data
> > grid should just be declared and reuse existing pieces of the (Jewel)
> > component set.
> >
> > To me, the primary problem with creating a “Foundation” lib is that it’s
> > going to be very difficult to decide what goes in there. It feels like it
> > will lead to less organization instead of more. It’s also a lot of work
> and
> > I don’t see any gain.
> >
>
> ok , you're proposing another different direction that is not the old one
> nor the current one. It could be valid, but I already discussed this with
> Alex about 1-2 months ago.
> For example, components has a createElement that is part of the main
> 

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

[Carlos Rovira]

Hi Harbs,

2018-05-30 11:49 GMT+02:00 Harbs :

> I’m responding to this email because it has the most points I want to
> respond to.
>
> I’m pulling out the particular quotes that I think are most relevant to
> the discussion.
>
> >
> >> 2. A “base” component set to use (or partially use) for composition.
> >>
> >
> > Take into account that Jewel does not subclass any component in Basic.
> MDL
> > should not do it, since extend a control from basic really does not bring
> > it nothing. I did in that way since at that time I was young in creating
> UI
> > sets, but I never was completely happy of that way. But, again, both
> models
> > make possible to extend a set and create a new one from that point, but
> > yours make that mandatory, so for me less flexible.
>
> I don’t understand what you mean by less flexible. I think it’s more so.
> You say that Jewel is not using Basic, but I don’t see that. I work much
> better with concrete examples, so let me try:
>
> 1. Jewel currently has 8 model classes which are copies from Basic. Models
> should be component set agnostic and if we need to copy them from one
> component set to another, we’re doing something wrong. These models should
> be either in Basic or some other “Foundation” lib.
>

Right, that should go to Foundation, not Basic, for all the models to
share, others are now copies, but not in the future. Take into account that
right now I did some copies just to put in place things, but this
disscussion makes me stop my development flow.


> 2. Controllers. I think you copied controllers as well. Controllers might
> also be in a “foundation” lib, but that “feels” like less of a good fit.
>

Right


> 3. Beads. Right now, the only bead I see is TextPrompt. I don’t see any
> reason to copy that. It’s also dependent on the implementation of the
> component set, so putting that in “foundation” does not feel right.
>

Right...so you see know the problem, don't understand why you want we pass
all through Basic...you're describing the problem in your own words :?


> 4. Right now, Jewel does not have many composite components, so there’s
> very little in terms of components that it can use from Basic. However, as
> that is built out, I think it will make more sense to use Basic components.
> Most of the Basic components are built with separate views. This is very
> important for the more complex ones. I’m going to focus on a few specific
> components to try and make my point.
>a. List. Even a component such as List seems like it would make more
> sense to use the Basic one. The only reason I can see to use a different
> class is to prevent basic List css and to set the correct typeNames. The
> actual appearance of the list is handled by the view which should likely be
> different in Jewel. How can we use a Basic List? Possibly we will be able
> to improve the compiler to be smarter about how it pulls in CSS. Possibly
> we should have a ListBase which contains almost all the code and the List
> in each component set subclasses that.
>b. ComboBox. Right now combobox is a bit broken architecturally. I’m
> working on fixing it, but it’s conceptually a composite component
> containing a button, a component which displays the selected item and
> possibly take input, and a List for the dropdown. Ideally, different
> component sets should use the ComboBox component as-is, and specify
> different components for the pieces of the view.
>c. DataGrid. Rebuilding the entire DataGrid hierarchy for separate
> component sets seems very wasteful and error-prone. The visuals of the data
> grid should just be declared and reuse existing pieces of the (Jewel)
> component set.
>
> To me, the primary problem with creating a “Foundation” lib is that it’s
> going to be very difficult to decide what goes in there. It feels like it
> will lead to less organization instead of more. It’s also a lot of work and
> I don’t see any gain.
>

ok , you're proposing another different direction that is not the old one
nor the current one. It could be valid, but I already discussed this with
Alex about 1-2 months ago.
For example, components has a createElement that is part of the main
component class, then we have a view. For Alex, the createElement use to be
sufficient in Basic and most of time if creates (in HTML) a tag. In Jewel
we use to need some html tags to create the desired visuals. So, what you
propose is another valid way: Not have component sets, but only one and
then "decorate" it with different view beads. So a CheckBox in basic will
use a simple input while in jewel the view will be composed of about three
tags.

In that case, with only one set, and here's a key point, we need the CSS as
well not to be in the component set (the CSS that wires all beads) but in
an optional library for this to work. So people that wants Jewel visuals
will take the library that has that CSS and people that want Basic will
choose a different library.

Take into account that both ways always 

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

[Harbs]

I’m responding to this email because it has the most points I want to respond 
to.

I’m pulling out the particular quotes that I think are most relevant to the 
discussion.

> 
>> 2. A “base” component set to use (or partially use) for composition.
>> 
> 
> Take into account that Jewel does not subclass any component in Basic. MDL
> should not do it, since extend a control from basic really does not bring
> it nothing. I did in that way since at that time I was young in creating UI
> sets, but I never was completely happy of that way. But, again, both models
> make possible to extend a set and create a new one from that point, but
> yours make that mandatory, so for me less flexible.

I don’t understand what you mean by less flexible. I think it’s more so. You 
say that Jewel is not using Basic, but I don’t see that. I work much better 
with concrete examples, so let me try:

1. Jewel currently has 8 model classes which are copies from Basic. Models 
should be component set agnostic and if we need to copy them from one component 
set to another, we’re doing something wrong. These models should be either in 
Basic or some other “Foundation” lib.
2. Controllers. I think you copied controllers as well. Controllers might also 
be in a “foundation” lib, but that “feels” like less of a good fit.
3. Beads. Right now, the only bead I see is TextPrompt. I don’t see any reason 
to copy that. It’s also dependent on the implementation of the component set, 
so putting that in “foundation” does not feel right.
4. Right now, Jewel does not have many composite components, so there’s very 
little in terms of components that it can use from Basic. However, as that is 
built out, I think it will make more sense to use Basic components. Most of the 
Basic components are built with separate views. This is very important for the 
more complex ones. I’m going to focus on a few specific components to try and 
make my point.
   a. List. Even a component such as List seems like it would make more sense 
to use the Basic one. The only reason I can see to use a different class is to 
prevent basic List css and to set the correct typeNames. The actual appearance 
of the list is handled by the view which should likely be different in Jewel. 
How can we use a Basic List? Possibly we will be able to improve the compiler 
to be smarter about how it pulls in CSS. Possibly we should have a ListBase 
which contains almost all the code and the List in each component set 
subclasses that.
   b. ComboBox. Right now combobox is a bit broken architecturally. I’m working 
on fixing it, but it’s conceptually a composite component containing a button, 
a component which displays the selected item and possibly take input, and a 
List for the dropdown. Ideally, different component sets should use the 
ComboBox component as-is, and specify different components for the pieces of 
the view.
   c. DataGrid. Rebuilding the entire DataGrid hierarchy for separate component 
sets seems very wasteful and error-prone. The visuals of the data grid should 
just be declared and reuse existing pieces of the (Jewel) component set.

To me, the primary problem with creating a “Foundation” lib is that it’s going 
to be very difficult to decide what goes in there. It feels like it will lead 
to less organization instead of more. It’s also a lot of work and I don’t see 
any gain.

> 
>> 3. A logical place to put shared beads.
>> 
> 
> This is resolved with "Foundation" library. Finaly we'll be doing the same,
> using a common library that reuse beads.

Agreed. But I’m trying to understand what the advantage of a new library is 
over just keeping Basic. I’m still not understanding you on this point.

>> 
>> What is gained by removing that dependency?
>> 
> 
> Well, while both versions brings the same benefits, as I tried to respond
> in the responses to that 3 points, I think separate beads and coming code
> in Foundation makes Royale more flexible. I talk about this several times,
> and I think advantages are clearly shown in the schema image, but I'll try
> to summarize it again:
> 
> What improvements we get? (I'm supposing we have Foundation library with
> beads and common code previously in Basic, and some now in Core, and think
> that Basic ui set for me is only the controls and components and the css,
> not the beads and code that will be in Foundation)

We already finished discussing the CSS issues. I thought we all agreed that 
there are bugs there that need to be fixed. I completely agree with you that 
Jewel should not suffer inflation because of Basic. If we fix the bugs in Basic 
I don’t think it will.

> 1.- Without Basic, or any mandatory UI sets, we remove the processing of
> the CSS beads file that is part of every UI set. This is critical, since
> far beyond compiler bugs, we don't want our app to process a file that wire
> a lots of beads, since the right bead file to process is only the UI Set
> the user wants to use.
>  1.a-If you want to use Jewel, 

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

[Carlos Rovira]

Hi Alex,

2018-05-30 5:53 GMT+02:00 Alex Harui :

> FWIW, I think there is still a disconnect here.


Right, I think we are mostly on consensus about refactoring names and
packages and how to deal with CSS names, but the final point (maybe most
important) is about the dependency library that I think is very important.


> After looking at Carlos's diagram with a Foundation layer, maybe the
> confusion is around how to think about Composition-based instead of
> Inheritance-based components.


maybe this is the problem


>   There should be no desire to make every component set use only things
> from a single "foundation" layer.  That's why I wanted to close on the
> discussion about using Express beads in Jewel.


So that's exactly my concern here. As you said, we don't need every
component set to use a concrete layer, but in the old set up and for Harbs
diagram, we are forcing every single user to do that, and even worse, we
are putting a CSS configuration processing in the middle and making all
apps pas through it. And I write many points about the disadvantages of
doing that. So I think we are saying the same.



> So maybe we should put this thread on pause and finish up that discussion.
>

I think we are reaching to a close here, don't see the need to make a
pause. More over, we have many users out there that wants to try Jewel and
they are waiting for the 0.9.3 release to put blog examples in practice. I
think we are gaining some momentum out there, and that was hard work to
reach to that. We are pausing this efforts and if we don't feed the
external communication, that will end reverting that effort. So I think is
better to go forward and solve this problem. We are about a month stuck
here, and that's not good for the project IMHO.


>
> Couple of other thoughts:
>
> -There should be beads of varying complexity, from small, simple (Basic),
> to more powerful or type-agnostic (Express).  This latter category of beads
> don't belong in a "foundation" layer as they are a layer above the Basic
> ones.


Again we are saying the same, the latter beads, the concrete
implementations of controls and components, and the CSS that wires all,
should go to its own optional library (i.e: Basic, Jewel,...) for the user
to choose the one to use without obligation for our part.


> Yet Component Sets are welcome and even encouraged to leverage these more
> complex beads.  Our users have asked for that.
>

Right.


>
> - As Harbs is saying, and I said earlier, Core is intended to be
> implementation-agnostic and identify the parts/roles in the framework.
> Basic beads, especially the Container beads, are a specific implementation,
> knowing that SWF and JS are the outputs.  Who knows what will be required
> in the implementation of component sets for other outputs.
>

I'm as well aligned with this. This is ok with the new dependency of
libraries

IMHO, we have consensus in all the things discussed in the other threads,
and regarding dependency of libraries, I see for this email that Alex and I
are saying the same and only need to know about Harbs.

Maybe since both ways do the same, the question you must to answer yourself
is: Do I want to have all the same benefits from old configuration, plus
new flexibility ones? hope the answer will be yes

thanks




>
> My 2 cents,
> -Alex
>
> On 5/29/18, 11:02 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> Hi
>
> 2018-05-29 17:44 GMT+02:00 Harbs :.
> >
> >
> > OK. I define Core a bit differently. Core defines the *architecture*
> or
> > “scaffolding” of a Royale application. I don’t believe a Royale
> application
> > can be compiled from Core alone.
> >
> > Core is assumed to be a prerequisite for almost all other Royale libs
> > (except Testing and Language). It should not have dependencies on
> other
> > libraries or particular implementation details.
> >
> >
> Right, I was not taking into account Language and Testing since for me
> is
> even more "platform" or event more "atomic", but in essence we are
> talking
> the same here.
>
> >> 4. What are the advantages and disadvantages of making Basic a
> dependency
> > >> for other component sets?
> > >>
> > >
> > > I think this is mostly explained here, and a image use to be
> better than
> > > thousand words, but the image mix graphs and explanations:
> > > https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fsnag.gy%2FDbH4iG.jpg=02%7C01%7Caharui%40adobe.com%
> 7C42db7d68cb1f48b59d7208d5c58e630d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636632137691163168=A1StIlX4vcrkQ%
> 2F8EF7o8SPoGD28pmyHp6amM%2BzYQqNI%3D=0  protection.outlook.com/?url=https%3A%2F%2Fsnag.gy%
> 2FDbH4iG.jpg=02%7C01%7Caharui%40adobe.com%
> 7C42db7d68cb1f48b59d7208d5c58e630d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636632137691173177=IKoHqY9iflgHix7NbSbw1mO9wptThn
> LbFv7tLFIE4DU%3D=0>
> 

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

[Alex Harui]

FWIW, I think there is still a disconnect here.  After looking at Carlos's 
diagram with a Foundation layer, maybe the confusion is around how to think 
about Composition-based instead of Inheritance-based components.  There should 
be no desire to make every component set use only things from a single 
"foundation" layer.  That's why I wanted to close on the discussion about using 
Express beads in Jewel.  So maybe we should put this thread on pause and finish 
up that discussion.

Couple of other thoughts:

-There should be beads of varying complexity, from small, simple (Basic), to 
more powerful or type-agnostic (Express).  This latter category of beads don't 
belong in a "foundation" layer as they are a layer above the Basic ones.  Yet 
Component Sets are welcome and even encouraged to leverage these more complex 
beads.  Our users have asked for that.

- As Harbs is saying, and I said earlier, Core is intended to be 
implementation-agnostic and identify the parts/roles in the framework.  Basic 
beads, especially the Container beads, are a specific implementation, knowing 
that SWF and JS are the outputs.  Who knows what will be required in the 
implementation of component sets for other outputs.

My 2 cents,
-Alex

On 5/29/18, 11:02 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi

2018-05-29 17:44 GMT+02:00 Harbs :.
>
>
> OK. I define Core a bit differently. Core defines the *architecture* or
> “scaffolding” of a Royale application. I don’t believe a Royale 
application
> can be compiled from Core alone.
>
> Core is assumed to be a prerequisite for almost all other Royale libs
> (except Testing and Language). It should not have dependencies on other
> libraries or particular implementation details.
>
>
Right, I was not taking into account Language and Testing since for me is
even more "platform" or event more "atomic", but in essence we are talking
the same here.

>> 4. What are the advantages and disadvantages of making Basic a dependency
> >> for other component sets?
> >>
> >
> > I think this is mostly explained here, and a image use to be better than
> > thousand words, but the image mix graphs and explanations:
> > 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsnag.gy%2FDbH4iG.jpg=02%7C01%7Caharui%40adobe.com%7C42db7d68cb1f48b59d7208d5c58e630d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636632137691163168=A1StIlX4vcrkQ%2F8EF7o8SPoGD28pmyHp6amM%2BzYQqNI%3D=0
 

>
> Here is what the dependencies are currently:
> 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2F8n3dxgv45qus3jp%2Froyale.png%3Fdl%3D0=02%7C01%7Caharui%40adobe.com%7C42db7d68cb1f48b59d7208d5c58e630d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636632137691173177=Umo%2F2xF%2FrfGZNybFfc%2FwbtkOr8UnRvVwKhlF6wblr9o%3D=0
>
>
good to see how you see it.


> I don’t understand the point of changing the dependencies around.
>
> To me the advantages of making Basic a dependency is:
>
> 1. A clearer (to me), flatter dependency tree.
>

your's a mine seems to be equally flatter for me.


> 2. A “base” component set to use (or partially use) for composition.
>

Take into account that Jewel does not subclass any component in Basic. MDL
should not do it, since extend a control from basic really does not bring
it nothing. I did in that way since at that time I was young in creating UI
sets, but I never was completely happy of that way. But, again, both models
make possible to extend a set and create a new one from that point, but
yours make that mandatory, so for me less flexible.


> 3. A logical place to put shared beads.
>

This is resolved with "Foundation" library. Finaly we'll be doing the same,
using a common library that reuse beads.

>
> What is gained by removing that dependency?
>

Well, while both versions brings the same benefits, as I tried to respond
in the responses to that 3 points, I think separate beads and coming code
in Foundation makes Royale more flexible. I talk about this several times,
and I think advantages are clearly shown in the schema image, but I'll try
to summarize it again:

What improvements we get? (I'm supposing we have Foundation library with
beads and common code previously in Basic, and some now in Core, and think
that Basic ui set for me is only the controls and components and the css,
not the beads and code that will be in Foundation)

1.- Without Basic, or any mandatory 

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

[Harbs]

> On May 29, 2018, at 5:34 PM, Carlos Rovira  wrote:
> 
> Hi
> 
> 2018-05-29 16:00 GMT+02:00 Harbs  >:
>> 
>> 
>> 1. How do we define what is “Core"?
>> 
> 
> *Core*: This classes are needed to build a Royale
> 
> Application. All pieces here are required. No CSS is present here
> 
> to wire any concrete relationship between pieces, as well avoiding
> 
> possible inclussions of CSS rules and/or bugs in a final App.

OK. I define Core a bit differently. Core defines the *architecture* or 
“scaffolding” of a Royale application. I don’t believe a Royale application can 
be compiled from Core alone.

Core is assumed to be a prerequisite for almost all other Royale libs (except 
Testing and Language). It should not have dependencies on other libraries or 
particular implementation details.


>> 2. Should package names match the project names?
>> 
> 
> Normaly this is true always. Don't recall libraries with mixed package
> names.
> Some exceptions: Network has "net", but this is normal for less verbosity.

I’m not sure about this. I think It might be beneficial to discuss particulars 
to weigh the pros and cons on this. I don’t know where stand myself.

> 
>> 3. Do we care to try and make package names shorter (i..e limit the level
>> of folders)?
>> 
> 
> Yes, if we can, but in the case os beads, since we'll be using mostly on
> mxml, we put shorter class name over package levels. Even on AS3 in this
> case is better a longer import than multiple longer class names use.

I think I agree with this.

>> 4. What are the advantages and disadvantages of making Basic a dependency
>> for other component sets?
>> 
> 
> I think this is mostly explained here, and a image use to be better than
> thousand words, but the image mix graphs and explanations:
> https://snag.gy/DbH4iG.jpg 

Here is what the dependencies are currently:
https://www.dropbox.com/s/8n3dxgv45qus3jp/royale.png?dl=0

I don’t understand the point of changing the dependencies around.

To me the advantages of making Basic a dependency is:

1. A clearer (to me), flatter dependency tree.
2. A “base” component set to use (or partially use) for composition.
3. A logical place to put shared beads.

What is gained by removing that dependency?

> 
>> 5. A question which might follow the ones above are whether we should add
>> a new package. I’d rather wait to discuss this until we have some clarity
>> on the ones above.
>> 
> 
> mmm...you mean to say "package" or new "library" (maybe you refer to
> "Foundation" here)

Yes. Or something else.

Thanks,
Harbs

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

[Carlos Rovira]

Hi

2018-05-29 16:00 GMT+02:00 Harbs :
>
>
> 1. How do we define what is “Core"?
>

*Core*: This classes are needed to build a Royale

Application. All pieces here are required. No CSS is present here

to wire any concrete relationship between pieces, as well avoiding

possible inclussions of CSS rules and/or bugs in a final App.


> 2. Should package names match the project names?
>

Normaly this is true always. Don't recall libraries with mixed package
names.
Some exceptions: Network has "net", but this is normal for less verbosity.


> 3. Do we care to try and make package names shorter (i..e limit the level
> of folders)?
>

Yes, if we can, but in the case os beads, since we'll be using mostly on
mxml, we put shorter class name over package levels. Even on AS3 in this
case is better a longer import than multiple longer class names use.


> 4. What are the advantages and disadvantages of making Basic a dependency
> for other component sets?
>

I think this is mostly explained here, and a image use to be better than
thousand words, but the image mix graphs and explanations:
https://snag.gy/DbH4iG.jpg


> 5. A question which might follow the ones above are whether we should add
> a new package. I’d rather wait to discuss this until we have some clarity
> on the ones above.
>

mmm...you mean to say "package" or new "library" (maybe you refer to
"Foundation" here)


>
> Can you think of any other questions we should be asking ourselves?
>

Not for now.

Thanks

Carlos



>
> Thanks,
> Harbs
>
> > On May 29, 2018, at 4:41 PM, Carlos Rovira 
> wrote:
> >
> > Hi,
> >
> > completely.
> >
> > two things:
> >
> > 1. I propose in the new Discussion thread to make that work myself, but
> we
> > can do together. I think the best way is to rename and move things in
> > chunks so we make this in various steps, testing builds not break, and so
> > onthis will take some days to reach a good shape.
> > 2. I already said my work was totally incomplete. But as we need this
> > discussion I didn't do more but fixing build.
> >
> >
> > 2018-05-29 15:13 GMT+02:00 Harbs :
> >>
> >>> 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.
> >>
> >> I agree with this completely. Carlos, do you agree as well? (I would be
> >> willing to help out with a rename, but I want to make sure it doesn't
> cause
> >> too much disruption.
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On May 23, 2018, at 12:43 AM, Alex Harui 
> >> wrote:
> >>>
> >>> Hi Carlos,
> >>>
> >>> I guess I don't understand why separating beads from TLCs is better.
> >> How will that make things better for users or other component set
> >> developers?  That would effectively double the number of SWCs and each
> TLC
> >> SWC will need its bead SWC.  That doesn't sound like a good thing to me,
> >> but if that's what other folks want to do, that's fine with me.
> >>>
> >>> I was just looking through the classes in Jewel.  It looks like JeweL
> >> doesn't have a DataGrid yet..  When it does, I would think you will
> want to
> >> use the DataGridModel from Express as it handles both Arrays and
> >> ICollectionViews.  We will probably create a similar model bead that
> takes
> >> both ICollectionViews and Arrays for Lists and put that in Express as
> >> well.  Then we might decide that is better for Jewel to use that model
> >> instead.  Or maybe we'll decide to create a JewelExpress set that has
> those
> >> more general models that don't require as much configuration.  Anyway, I
> >> hope you agree that at some point, these more general models will be
> used
> >> by Express and some flavor of Jewel.  I don't think this general model
> >> should go in Core, or Basic (or some new category called Foundation).
> And
> >> at that point, Jewel or JewelExpress is going to re-use that code in
> >> Express.
> >>>
> >>> Component sets are encouraged to re-use existing code from any other
> SWC
> >> since I think we've agreed that re-use is important.
> >>>
> >>> My 2 cents,
> >>> -Alex
> >>>
> >>> On 5/21/18, 11:16 AM, "carlos.rov...@gmail.com  >> carlos.rov...@gmail.com> on behalf of Carlos Rovira" <
> >> carlos.rov...@gmail.com  on behalf of
> >> carlosrov...@apache.org > wrote:
> >>>
> >>>   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
> >>>   

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

[Harbs]

Perfect.

I think we did a great job on the css part of this discussion. Let’s see if we 
ca come to a meeting of the minds on the rest. :-)

Let’s try and figure out what we all agree and don’t agree on.

The important pieces I see are:

1. How do we define what is “Core"?
2. Should package names match the project names?
3. Do we care to try and make package names shorter (i..e limit the level of 
folders)?
4. What are the advantages and disadvantages of making Basic a dependency for 
other component sets?
5. A question which might follow the ones above are whether we should add a new 
package. I’d rather wait to discuss this until we have some clarity on the ones 
above.

Can you think of any other questions we should be asking ourselves?

Thanks,
Harbs

> On May 29, 2018, at 4:41 PM, Carlos Rovira  wrote:
> 
> Hi,
> 
> completely.
> 
> two things:
> 
> 1. I propose in the new Discussion thread to make that work myself, but we
> can do together. I think the best way is to rename and move things in
> chunks so we make this in various steps, testing builds not break, and so
> onthis will take some days to reach a good shape.
> 2. I already said my work was totally incomplete. But as we need this
> discussion I didn't do more but fixing build.
> 
> 
> 2018-05-29 15:13 GMT+02:00 Harbs :
>> 
>>> 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.
>> 
>> I agree with this completely. Carlos, do you agree as well? (I would be
>> willing to help out with a rename, but I want to make sure it doesn't cause
>> too much disruption.
>> 
>> Thanks,
>> Harbs
>> 
>>> On May 23, 2018, at 12:43 AM, Alex Harui 
>> wrote:
>>> 
>>> Hi Carlos,
>>> 
>>> I guess I don't understand why separating beads from TLCs is better.
>> How will that make things better for users or other component set
>> developers?  That would effectively double the number of SWCs and each TLC
>> SWC will need its bead SWC.  That doesn't sound like a good thing to me,
>> but if that's what other folks want to do, that's fine with me.
>>> 
>>> I was just looking through the classes in Jewel.  It looks like JeweL
>> doesn't have a DataGrid yet..  When it does, I would think you will want to
>> use the DataGridModel from Express as it handles both Arrays and
>> ICollectionViews.  We will probably create a similar model bead that takes
>> both ICollectionViews and Arrays for Lists and put that in Express as
>> well.  Then we might decide that is better for Jewel to use that model
>> instead.  Or maybe we'll decide to create a JewelExpress set that has those
>> more general models that don't require as much configuration.  Anyway, I
>> hope you agree that at some point, these more general models will be used
>> by Express and some flavor of Jewel.  I don't think this general model
>> should go in Core, or Basic (or some new category called Foundation).  And
>> at that point, Jewel or JewelExpress is going to re-use that code in
>> Express.
>>> 
>>> Component sets are encouraged to re-use existing code from any other SWC
>> since I think we've agreed that re-use is important.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 5/21/18, 11:16 AM, "carlos.rov...@gmail.com > carlos.rov...@gmail.com> on behalf of Carlos Rovira" <
>> carlos.rov...@gmail.com  on behalf of
>> carlosrov...@apache.org > wrote:
>>> 
>>>   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
>>> 

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

[Harbs]

Sorry for my delayed response to all of this. I’ve been kind of out of it…

Can we try and get clear on the problems? I’d really like to figure out what we 
agree on before we try to nail down a solution.

I’d like to start with Alex’s list:
> 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.

I agree with this completely. Carlos, do you agree as well? (I would be willing 
to help out with a rename, but I want to make sure it doesn't cause too much 
disruption.

Thanks,
Harbs

> On May 23, 2018, at 12:43 AM, Alex Harui  wrote:
> 
> Hi Carlos,
> 
> I guess I don't understand why separating beads from TLCs is better.  How 
> will that make things better for users or other component set developers?  
> That would effectively double the number of SWCs and each TLC SWC will need 
> its bead SWC.  That doesn't sound like a good thing to me, but if that's what 
> other folks want to do, that's fine with me.
> 
> I was just looking through the classes in Jewel.  It looks like JeweL doesn't 
> have a DataGrid yet..  When it does, I would think you will want to use the 
> DataGridModel from Express as it handles both Arrays and ICollectionViews.  
> We will probably create a similar model bead that takes both ICollectionViews 
> and Arrays for Lists and put that in Express as well.  Then we might decide 
> that is better for Jewel to use that model instead.  Or maybe we'll decide to 
> create a JewelExpress set that has those more general models that don't 
> require as much configuration.  Anyway, I hope you agree that at some point, 
> these more general models will be used by Express and some flavor of Jewel.  
> I don't think this general model should go in Core, or Basic (or some new 
> category called Foundation).  And at that point, Jewel or JewelExpress is 
> going to re-use that code in Express.
> 
> Component sets are encouraged to re-use existing code from any other SWC 
> since I think we've agreed that re-use is important.
> 
> My 2 cents,
> -Alex
> 
> On 5/21/18, 11:16 AM, "carlos.rov...@gmail.com 
>  on behalf of Carlos Rovira" 
> mailto:carlos.rov...@gmail.com> on behalf of 
> carlosrov...@apache.org > wrote:
> 
>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 

Re: 0.9.3 Release

[Carlos Rovira]

Hi Om,

there's many changes since 0.9.2, so I was thinking the same as you. We
don't need to go to 0.9.4, we can skip to 0.9.5 or as you say, 0.10.0

thanks

2018-05-26 15:20 GMT+02:00 OmPrakash Muppirala :

> I just remembered that we have already pushed a 0.9.3 release to npm.  We
> will not be able to re release that version.  Perhaps we just skip to 0.9.4
> version next?
>
> Or even 0.10.0?
>
> Thanks,
> Om
>
> On Sat, May 26, 2018, 12:17 AM Carlos Rovira 
> wrote:
>
> > Thanks Alex,
> >
> > I committed as well some poms that needed change from 0.9.4 to 0.9.3
> > snapshot. We'll need to check why this ones are not update to the new
> > version when doing a prepare release.
> >
> > I'll try as well to summarize briefly the discussion about reorganization
> > so people could check easily the main points of what we are discussing,
> > hope that helps to take decisions and go forward
> >
> > Thanks
> >
> > Carlos
> >
> >
> >
> > 2018-05-25 21:37 GMT+02:00 Alex Harui :
> >
> > > In case folks are wondering, I deleted the release/0.9.3 branches from
> > all
> > > 3 repos.  There have been changes made in each of the branches since
> the
> > > branches were cut and there were also issues with the royale-compiler
> and
> > > royale-typedefs branches not having synced version numbers to their
> > develop
> > > branches.
> > >
> > > I see a vote thread opened today on Maven's lists for the SCM plug in.
> > >
> > > AIUI, we are on hold for a release unless we get general consensus to
> > what
> > > commit hash to release from for royale-asjs.
> > >
> > > -Alex
> > >
> > > On 5/17/18, 3:02 AM, "carlos.rov...@gmail.com on behalf of Carlos
> > > Rovira" 
> > > wrote:
> > >
> > > The minimun change is to see package names change.
> > > Take into account that all is building and working ok. Only we have
> > > problems in jsonly build since is only depends on ANT (what I think
> > is
> > > not
> > > good, since is missing maven build), in
> > "/mustella/tests/basicTests/".
> > > Looking at what's happening in that part will solve the build.
> > >
> > > 2018-05-17 11:40 GMT+02:00 Harbs :
> > >
> > > > You are right. I missed this.
> > > >
> > > > What is the minimum change necessary to get this to work?
> > > >
> > > > > On May 17, 2018, at 12:24 PM, Carlos Rovira <
> > > carlosrov...@apache.org>
> > > > wrote:
> > > > >
> > > > >  I think you missed one important point I
> > > > > posted in other email: All blog post samples posted that are
> > using
> > > the
> > > > > actual names, packages and namespaces. If you release 0.9.3
> > > without all
> > > > > that, we can destroy out credibility since in all posts we
> have:
> > > > >
> > > > > "The example uses the new Jewel UI set that supports themes.
> > Jewel
> > > will
> > > > be
> > > > > available in the forthcoming 0.9.3 release of Royale. In the
> > > meanwhile
> > > > you
> > > > > can find it in the develop branch."
> > > > >
> > > > > and the code is tailored with the actual api.
> > > > >
> > > > > For that reason, I think is important to hold 0.9.3 until it
> can
> > > ship
> > > > with
> > > > > all that we are promising in website and social networks for
> the
> > > latest 2
> > > > > months. I think this is crucial.
> > > >
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > https://na01.safelinks.protection.outlook.com/?url=
> > > http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com
> %
> > > 7C9a61c338f4554b04aa9008d5bbdd5762%7Cfa7b1b5a7b34438794aed2c178de
> > > cee1%7C0%7C0%7C636621481721528268=6FoSfupJoaFpfsqJcJ7HtHNpRoQluG
> > > Uzh6hlM21AH20%3D=0
> > >
> > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>



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

Re: 0.9.3 Release

[Carlos Rovira]

Thanks Alex,

I committed as well some poms that needed change from 0.9.4 to 0.9.3
snapshot. We'll need to check why this ones are not update to the new
version when doing a prepare release.

I'll try as well to summarize briefly the discussion about reorganization
so people could check easily the main points of what we are discussing,
hope that helps to take decisions and go forward

Thanks

Carlos



2018-05-25 21:37 GMT+02:00 Alex Harui :

> In case folks are wondering, I deleted the release/0.9.3 branches from all
> 3 repos.  There have been changes made in each of the branches since the
> branches were cut and there were also issues with the royale-compiler and
> royale-typedefs branches not having synced version numbers to their develop
> branches.
>
> I see a vote thread opened today on Maven's lists for the SCM plug in.
>
> AIUI, we are on hold for a release unless we get general consensus to what
> commit hash to release from for royale-asjs.
>
> -Alex
>
> On 5/17/18, 3:02 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> The minimun change is to see package names change.
> Take into account that all is building and working ok. Only we have
> problems in jsonly build since is only depends on ANT (what I think is
> not
> good, since is missing maven build), in "/mustella/tests/basicTests/".
> Looking at what's happening in that part will solve the build.
>
> 2018-05-17 11:40 GMT+02:00 Harbs :
>
> > You are right. I missed this.
> >
> > What is the minimum change necessary to get this to work?
> >
> > > On May 17, 2018, at 12:24 PM, Carlos Rovira <
> carlosrov...@apache.org>
> > wrote:
> > >
> > >  I think you missed one important point I
> > > posted in other email: All blog post samples posted that are using
> the
> > > actual names, packages and namespaces. If you release 0.9.3
> without all
> > > that, we can destroy out credibility since in all posts we have:
> > >
> > > "The example uses the new Jewel UI set that supports themes. Jewel
> will
> > be
> > > available in the forthcoming 0.9.3 release of Royale. In the
> meanwhile
> > you
> > > can find it in the develop branch."
> > >
> > > and the code is tailored with the actual api.
> > >
> > > For that reason, I think is important to hold 0.9.3 until it can
> ship
> > with
> > > all that we are promising in website and social networks for the
> latest 2
> > > months. I think this is crucial.
> >
> >
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C9a61c338f4554b04aa9008d5bbdd5762%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621481721528268=6FoSfupJoaFpfsqJcJ7HtHNpRoQluG
> Uzh6hlM21AH20%3D=0
>
>
>


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

Re: 0.9.3 Release

[Alex Harui]

In case folks are wondering, I deleted the release/0.9.3 branches from all 3 
repos.  There have been changes made in each of the branches since the branches 
were cut and there were also issues with the royale-compiler and 
royale-typedefs branches not having synced version numbers to their develop 
branches.

I see a vote thread opened today on Maven's lists for the SCM plug in.

AIUI, we are on hold for a release unless we get general consensus to what 
commit hash to release from for royale-asjs.

-Alex

On 5/17/18, 3:02 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

The minimun change is to see package names change.
Take into account that all is building and working ok. Only we have
problems in jsonly build since is only depends on ANT (what I think is not
good, since is missing maven build), in "/mustella/tests/basicTests/".
Looking at what's happening in that part will solve the build.

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

> You are right. I missed this.
>
> What is the minimum change necessary to get this to work?
>
> > On May 17, 2018, at 12:24 PM, Carlos Rovira 
> wrote:
> >
> >  I think you missed one important point I
> > posted in other email: All blog post samples posted that are using the
> > actual names, packages and namespaces. If you release 0.9.3 without all
> > that, we can destroy out credibility since in all posts we have:
> >
> > "The example uses the new Jewel UI set that supports themes. Jewel will
> be
> > available in the forthcoming 0.9.3 release of Royale. In the meanwhile
> you
> > can find it in the develop branch."
> >
> > and the code is tailored with the actual api.
> >
> > For that reason, I think is important to hold 0.9.3 until it can ship
> with
> > all that we are promising in website and social networks for the latest 
2
> > months. I think this is crucial.
>
>


-- 
Carlos Rovira

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C9a61c338f4554b04aa9008d5bbdd5762%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636621481721528268=6FoSfupJoaFpfsqJcJ7HtHNpRoQluGUzh6hlM21AH20%3D=0

Re: Should Jewel default to Express Beads? (was Re: [Discussion] Package change names (was Re: 0.9.3 Release))

[Alex Harui]

Hi Carlos,

Express is not an attempt to emulate Flex APIs.  The Emulation Components are.  
Express is merely designed to pre-compose more beads with less strong-typing in 
the data handling, in response to user feedback we received.  That's why I 
think Jewel should compose Express beads, in order to respond to our users.

Hopefully we will hear from others.

Thanks,
-Alex

On 5/24/18, 3:43 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Alex,

I think Jewel born from Basic and started doing the same as Basic do in
order to develop the view, CSS, etc... then is evolving to something that
is usable directly. For example: in the beginning there was Button and
TextButton like in Basic, then I find that only Button (with text property)
was needed since is what we already use it 99% of the time. In the other
hand, things like "Disabled" is already written as a bead since is a
behavior that is needed sometimes. I'm trying to balance so maybe the
response is that is not white, but is not back. So I think is not exactly a
Express set when all is preconfigured. I must say that I'm still learning
from developing Jewel and I'm testing things and sometimes I refactor to
what seems a better solution. In the end I use to think in how the code
finaly looks, and if is usable, flexible and how simple is to write it. So
like in many other fields, iteration over an idea and decision based on
empiric testing use to end in the best solution.

I think Express use to tend mostly to what Flex was, and I think not all in
flex was good, so I hope Jewel could get some things equal, but be better
in other fields. For example, I never liked Validation in Flex, I think is
too tied to the view controls, while Validation should validate date, so be
tied to models instead. As well loved the way this was implemented in
GraniteDS with Metadata, maybe this could be bring to Jewel in bead form,
we'll see when we come to that point.

Other case I'm finding now is for example how to deal with incoming
collections from a Server. In Basic List controls manage ICollectionView,
so we can do what we did in Flex storing data in ArrayLists or instead,
store in simple Array and then making a SingleSelectionArrayListModel,
since normaly that would be what people will use. So people can plug
directly their Array to list.dataprovider, and the control will knows how
to consume the Array. In this case Jewel can give a preselected bead
configuration that should be the use in mostly all cases, since the actual
SingleSelectionCollectionViewModel in Basic is not usable unless
application developers store make a conversion of the incoming Array to
ArrayList to feed the control.

So, in resume I think Jewel is right now in a middle step between Basic and
Express in terms of low-high configuration



2018-05-24 21:48 GMT+02:00 Alex Harui :

> Changing subject in case people have stopped reading.
>
> I think the question in the subject should be decided before we continue
> the package name discussion.  After thinking about it more, I really do
> think that Jewel should default to using Express beads (which might also
> mean that we need to create a few more Express beads).My reasoning is
> that we've already heard from users that a "high-configuration" component
> set like Basic was a pain to work with, which is why started creating a
> "low-configuration" set with Express.  It doesn't make sense to go back to
> "high-configuration" in Jewel.  Jewel should be the one component set 
folks
> use to get to know Royale and it should have both a good default
> look-and-feel (which Carlos has done) but also be "low-configuration".
>  Jewel has enough CSS and complex Views that we shouldn't be worried about
> trying to make Jewel lighter by not using Express beads.  Folks can
> optimize by swapping out beads as needed.
>
> Thoughts?
> -Alex
>
> On 5/22/18, 3:59 PM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> Hi Alex,
>
> I think we are saying the same in essence.
>
> I want to reuse beads. So lets take "TextPrompt" bead and have only
> one in
> all Royale (always that make the same of course), think that is in a
> library called "Foundation" that depends from Core but is not core.
> Seems
> "Foundation" is a name less confusing than Basic. All UI sets, link
> this
> foundation library and take what they want from it. Normally all UI
> sets
> will borrow "TextPrompt" bead. The same with the pieces in you 
DataGrid
>   

Re: Should Jewel default to Express Beads? (was Re: [Discussion] Package change names (was Re: 0.9.3 Release))

[Carlos Rovira]

Hi Alex,

I think Jewel born from Basic and started doing the same as Basic do in
order to develop the view, CSS, etc... then is evolving to something that
is usable directly. For example: in the beginning there was Button and
TextButton like in Basic, then I find that only Button (with text property)
was needed since is what we already use it 99% of the time. In the other
hand, things like "Disabled" is already written as a bead since is a
behavior that is needed sometimes. I'm trying to balance so maybe the
response is that is not white, but is not back. So I think is not exactly a
Express set when all is preconfigured. I must say that I'm still learning
from developing Jewel and I'm testing things and sometimes I refactor to
what seems a better solution. In the end I use to think in how the code
finaly looks, and if is usable, flexible and how simple is to write it. So
like in many other fields, iteration over an idea and decision based on
empiric testing use to end in the best solution.

I think Express use to tend mostly to what Flex was, and I think not all in
flex was good, so I hope Jewel could get some things equal, but be better
in other fields. For example, I never liked Validation in Flex, I think is
too tied to the view controls, while Validation should validate date, so be
tied to models instead. As well loved the way this was implemented in
GraniteDS with Metadata, maybe this could be bring to Jewel in bead form,
we'll see when we come to that point.

Other case I'm finding now is for example how to deal with incoming
collections from a Server. In Basic List controls manage ICollectionView,
so we can do what we did in Flex storing data in ArrayLists or instead,
store in simple Array and then making a SingleSelectionArrayListModel,
since normaly that would be what people will use. So people can plug
directly their Array to list.dataprovider, and the control will knows how
to consume the Array. In this case Jewel can give a preselected bead
configuration that should be the use in mostly all cases, since the actual
SingleSelectionCollectionViewModel in Basic is not usable unless
application developers store make a conversion of the incoming Array to
ArrayList to feed the control.

So, in resume I think Jewel is right now in a middle step between Basic and
Express in terms of low-high configuration



2018-05-24 21:48 GMT+02:00 Alex Harui :

> Changing subject in case people have stopped reading.
>
> I think the question in the subject should be decided before we continue
> the package name discussion.  After thinking about it more, I really do
> think that Jewel should default to using Express beads (which might also
> mean that we need to create a few more Express beads).My reasoning is
> that we've already heard from users that a "high-configuration" component
> set like Basic was a pain to work with, which is why started creating a
> "low-configuration" set with Express.  It doesn't make sense to go back to
> "high-configuration" in Jewel.  Jewel should be the one component set folks
> use to get to know Royale and it should have both a good default
> look-and-feel (which Carlos has done) but also be "low-configuration".
>  Jewel has enough CSS and complex Views that we shouldn't be worried about
> trying to make Jewel lighter by not using Express beads.  Folks can
> optimize by swapping out beads as needed.
>
> Thoughts?
> -Alex
>
> On 5/22/18, 3:59 PM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> Hi Alex,
>
> I think we are saying the same in essence.
>
> I want to reuse beads. So lets take "TextPrompt" bead and have only
> one in
> all Royale (always that make the same of course), think that is in a
> library called "Foundation" that depends from Core but is not core.
> Seems
> "Foundation" is a name less confusing than Basic. All UI sets, link
> this
> foundation library and take what they want from it. Normally all UI
> sets
> will borrow "TextPrompt" bead. The same with the pieces in you DataGrid
> example.
>
> In the other hand, UI sets has its own implementation of "Button" (and
> the
> rest of components), and the CSS that wires all the beads used in that
> concrete Button, and the rest of controls and components in that UI
> Set. I
> think we all said that we want to reuse, but we don't want to use a CSS
> from other UI set. So this concrete implementations of controls and
> components and the CSS should go in each library, and so we'll have
> Basic,
> Jewel, MDL, CreateJS,...
>
> Have sense to have Basic CSS and controls in Foundation? for me
> clearly no,
> since Jewel will not use it at all. Will use Foundation classes, (in
> your
> example DataGrid pieces to reuse almost all of it). Will use the CSS
> that
> wires all beads used in Basic, clearly not. So the code that goes in
> each

Should Jewel default to Express Beads? (was Re: [Discussion] Package change names (was Re: 0.9.3 Release))

[Alex Harui]

Changing subject in case people have stopped reading.

I think the question in the subject should be decided before we continue the 
package name discussion.  After thinking about it more, I really do think that 
Jewel should default to using Express beads (which might also mean that we need 
to create a few more Express beads).My reasoning is that we've already 
heard from users that a "high-configuration" component set like Basic was a 
pain to work with, which is why started creating a "low-configuration" set with 
Express.  It doesn't make sense to go back to "high-configuration" in Jewel.  
Jewel should be the one component set folks use to get to know Royale and it 
should have both a good default look-and-feel (which Carlos has done) but also 
be "low-configuration".   Jewel has enough CSS and complex Views that we 
shouldn't be worried about trying to make Jewel lighter by not using Express 
beads.  Folks can optimize by swapping out beads as needed.

Thoughts?
-Alex

On 5/22/18, 3:59 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Alex,

I think we are saying the same in essence.

I want to reuse beads. So lets take "TextPrompt" bead and have only one in
all Royale (always that make the same of course), think that is in a
library called "Foundation" that depends from Core but is not core. Seems
"Foundation" is a name less confusing than Basic. All UI sets, link this
foundation library and take what they want from it. Normally all UI sets
will borrow "TextPrompt" bead. The same with the pieces in you DataGrid
example.

In the other hand, UI sets has its own implementation of "Button" (and the
rest of components), and the CSS that wires all the beads used in that
concrete Button, and the rest of controls and components in that UI Set. I
think we all said that we want to reuse, but we don't want to use a CSS
from other UI set. So this concrete implementations of controls and
components and the CSS should go in each library, and so we'll have Basic,
Jewel, MDL, CreateJS,...

Have sense to have Basic CSS and controls in Foundation? for me clearly no,
since Jewel will not use it at all. Will use Foundation classes, (in your
example DataGrid pieces to reuse almost all of it). Will use the CSS that
wires all beads used in Basic, clearly not. So the code that goes in each
UI set library is clearly not reusable at all, and we don't want the
compiler to take extra time processing the CSS that wires all beads from a
UI Set that will not be used right?.

The opposite will be "lets take all ui set implementations (Basic, Jewel,
MDL, CreateJS,...) and mix altogether in a unique Foundation library with
all control and components implementations and all the CSSs that wires the
beads". Make this sense? For me clearly not. Moreover, in this case why
have libraries for Network, Binding, Collections...? Hope this extreme case
showcased makes more sense to explain.

If we want to reuse lets go and reuse, I'm all for it, but we shouldn't
have the CSS that binds all together for a UI Set that will not be used
since doesn't support anything in the normal use. And all of this even if
we get rid of the current bugs that brings lots of things to the final bake.

I think a library or SWC is in essence a reusable piece, but we not link
all existing SWC for all projects since we know we'll not using *all*
available SWCs we have, and since we don't want the compiler process all
CSSs in all that libraries all the time, since is time consuming. For this
reason we create the current SWC libraries, since if people will not use
Network, they normally don't link, if they use Basic, but not Jewel, MDL,
and CreateJS, those are not linked.

Finaly, if I'll not use Basic...then I don't want to be obligated to link
Basic (basic controls, and CSS) but I want to link Foundation since are the
reusable pieces in all Royale UI Sets.

Hope this explanation make more sense.

Thanks

Carlos







2018-05-22 23:43 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> I guess I don't understand why separating beads from TLCs is better.  How
> will that make things better for users or other component set developers?
> That would effectively double the number of SWCs and each TLC SWC will 
need
> its bead SWC.  That doesn't sound like a good thing to me, but if that's
> what other folks want to do, that's fine with me.
>
> I was just looking through the classes in Jewel.  It looks like JeweL
> doesn't have a DataGrid yet..  When it does, I would think you will want 
to
> use the DataGridModel from Express as it handles both Arrays and
> 

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

[Carlos Rovira]

Hi Alex,

I think we are saying the same in essence.

I want to reuse beads. So lets take "TextPrompt" bead and have only one in
all Royale (always that make the same of course), think that is in a
library called "Foundation" that depends from Core but is not core. Seems
"Foundation" is a name less confusing than Basic. All UI sets, link this
foundation library and take what they want from it. Normally all UI sets
will borrow "TextPrompt" bead. The same with the pieces in you DataGrid
example.

In the other hand, UI sets has its own implementation of "Button" (and the
rest of components), and the CSS that wires all the beads used in that
concrete Button, and the rest of controls and components in that UI Set. I
think we all said that we want to reuse, but we don't want to use a CSS
from other UI set. So this concrete implementations of controls and
components and the CSS should go in each library, and so we'll have Basic,
Jewel, MDL, CreateJS,...

Have sense to have Basic CSS and controls in Foundation? for me clearly no,
since Jewel will not use it at all. Will use Foundation classes, (in your
example DataGrid pieces to reuse almost all of it). Will use the CSS that
wires all beads used in Basic, clearly not. So the code that goes in each
UI set library is clearly not reusable at all, and we don't want the
compiler to take extra time processing the CSS that wires all beads from a
UI Set that will not be used right?.

The opposite will be "lets take all ui set implementations (Basic, Jewel,
MDL, CreateJS,...) and mix altogether in a unique Foundation library with
all control and components implementations and all the CSSs that wires the
beads". Make this sense? For me clearly not. Moreover, in this case why
have libraries for Network, Binding, Collections...? Hope this extreme case
showcased makes more sense to explain.

If we want to reuse lets go and reuse, I'm all for it, but we shouldn't
have the CSS that binds all together for a UI Set that will not be used
since doesn't support anything in the normal use. And all of this even if
we get rid of the current bugs that brings lots of things to the final bake.

I think a library or SWC is in essence a reusable piece, but we not link
all existing SWC for all projects since we know we'll not using *all*
available SWCs we have, and since we don't want the compiler process all
CSSs in all that libraries all the time, since is time consuming. For this
reason we create the current SWC libraries, since if people will not use
Network, they normally don't link, if they use Basic, but not Jewel, MDL,
and CreateJS, those are not linked.

Finaly, if I'll not use Basic...then I don't want to be obligated to link
Basic (basic controls, and CSS) but I want to link Foundation since are the
reusable pieces in all Royale UI Sets.

Hope this explanation make more sense.

Thanks

Carlos







2018-05-22 23:43 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> I guess I don't understand why separating beads from TLCs is better.  How
> will that make things better for users or other component set developers?
> That would effectively double the number of SWCs and each TLC SWC will need
> its bead SWC.  That doesn't sound like a good thing to me, but if that's
> what other folks want to do, that's fine with me.
>
> I was just looking through the classes in Jewel.  It looks like JeweL
> doesn't have a DataGrid yet..  When it does, I would think you will want to
> use the DataGridModel from Express as it handles both Arrays and
> ICollectionViews.  We will probably create a similar model bead that takes
> both ICollectionViews and Arrays for Lists and put that in Express as
> well.  Then we might decide that is better for Jewel to use that model
> instead.  Or maybe we'll decide to create a JewelExpress set that has those
> more general models that don't require as much configuration.  Anyway, I
> hope you agree that at some point, these more general models will be used
> by Express and some flavor of Jewel.  I don't think this general model
> should go in Core, or Basic (or some new category called Foundation).  And
> at that point, Jewel or JewelExpress is going to re-use that code in
> Express.
>
> Component sets are encouraged to re-use existing code from any other SWC
> since I think we've agreed that re-use is important.
>
> My 2 cents,
> -Alex
>
> On 5/21/18, 11:16 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> 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 

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

[Alex Harui]

Hi Carlos,

I guess I don't understand why separating beads from TLCs is better.  How will 
that make things better for users or other component set developers?  That 
would effectively double the number of SWCs and each TLC SWC will need its bead 
SWC.  That doesn't sound like a good thing to me, but if that's what other 
folks want to do, that's fine with me.

I was just looking through the classes in Jewel.  It looks like JeweL doesn't 
have a DataGrid yet..  When it does, I would think you will want to use the 
DataGridModel from Express as it handles both Arrays and ICollectionViews.  We 
will probably create a similar model bead that takes both ICollectionViews and 
Arrays for Lists and put that in Express as well.  Then we might decide that is 
better for Jewel to use that model instead.  Or maybe we'll decide to create a 
JewelExpress set that has those more general models that don't require as much 
configuration.  Anyway, I hope you agree that at some point, these more general 
models will be used by Express and some flavor of Jewel.  I don't think this 
general model should go in Core, or Basic (or some new category called 
Foundation).  And at that point, Jewel or JewelExpress is going to re-use that 
code in Express.

Component sets are encouraged to re-use existing code from any other SWC since 
I think we've agreed that re-use is important.

My 2 cents,
-Alex

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

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 

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: [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: 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: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

[Carlos Rovira]

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] http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/
> 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:
> >> > > 
> >> > >  Hi,
> >> > > 
> >> > >  I think seems something valid, maybe we should think more about
> >> > > >> possible
> >> > >  colateral issue of that method. You should look as well at a
> >> thread
> >> > > >> where
> >> > >  Alex proposed as well some valid options
> >> > > 
> >> > >  2018-05-17 15:04 GMT+02:00 Harbs :
> >> > > 
> >> > > > I just had another thought which might be even more flexible:
> >> > > >
> >> > > > Maybe the compile could parse @includes from CSS and insert
> >> them as
> >> > > >>> links
> >> > > > in the header HTML automatically.
> >> > > >
> >> > > > Thanks,
> >> > > > Harbs
> >> > > >
> >> > > >> On May 17, 2018, at 3:52 PM, Carlos Rovira <
> >> > carlosrov...@apache.org>
> >> > > > wrote:
> >> > > >>
> >> > > >>>
> >> > > >>> Another angle on this problem might be to allow adding links
> >> via
> >> > the
> >> > > >>> compiler automatically. Not sure exactly what form that
> might
> >> > take
> >> > > 

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

[Carlos Rovira]

Hi Piotr,

I never deal with ANT, I left this for others to contribute that build, as
well sometimes I contribute the maven build when others only do the ANT one.

I suppose that Alex make Jewel-Dark-NoFlat-Emphasized-Blue-Theme works, but
only do that one, when we tried Jewel + That theme and reported that he
tried successfully.

Can you complete the rest of theme builds?

Thanks

Carlos


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] http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/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:
> > > > 
> > > >  Hi,
> > > > 
> > > >  I think seems something valid, maybe we should think more about
> > > > >> possible
> > > >  colateral issue of that method. You should look as well at a
> > thread
> > > > >> where
> > > >  Alex proposed as well some valid options
> > > > 
> > > >  2018-05-17 15:04 GMT+02:00 Harbs :
> > > > 
> > > > > I just had another thought which might be even more flexible:
> > > > >
> > > > > Maybe the compile could parse @includes from CSS and insert
> them
> > as
> > > > >>> links
> > > > > in the header HTML automatically.
> > > > >
> > > > > Thanks,
> > > > > Harbs
> > > > >
> > > > >> On May 17, 2018, at 3:52 PM, Carlos Rovira <
> > > carlosrov...@apache.org>
> > > > > wrote:
> > > > >>
> > > > >>>
> > > > >>> Another angle on this problem might be to allow adding links
> > via
> > > the
> > > > >>> compiler automatically. Not sure exactly what form that might
> > > take
> > > > > though.
> > > > >>>
> > > > >>>
> > > > >> This was something Alex propose, something in the line of
> @media
> > > > >> -royale-swf, but with fonts, I think that is the right way.
> > > > >> For now we can stick with the html template but that should be
> > > > >>> temporal.
> > > > >
> > > > >
> > > > 
> > > > 
> > > >  --
> > > >  Carlos Rovira
> > > >  http://about.me/carlosrovira
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Carlos Rovira
> > > > >> http://about.me/carlosrovira
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Piotr Zarzycki
> > > > >
> > > > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > > > *
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: 

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

[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] http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/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:
>> > > 
>> > >  Hi,
>> > > 
>> > >  I think seems something valid, maybe we should think more about
>> > > >> possible
>> > >  colateral issue of that method. You should look as well at a
>> thread
>> > > >> where
>> > >  Alex proposed as well some valid options
>> > > 
>> > >  2018-05-17 15:04 GMT+02:00 Harbs :
>> > > 
>> > > > I just had another thought which might be even more flexible:
>> > > >
>> > > > Maybe the compile could parse @includes from CSS and insert
>> them as
>> > > >>> links
>> > > > in the header HTML automatically.
>> > > >
>> > > > Thanks,
>> > > > Harbs
>> > > >
>> > > >> On May 17, 2018, at 3:52 PM, Carlos Rovira <
>> > carlosrov...@apache.org>
>> > > > wrote:
>> > > >>
>> > > >>>
>> > > >>> Another angle on this problem might be to allow adding links
>> via
>> > the
>> > > >>> compiler automatically. Not sure exactly what form that might
>> > take
>> > > > though.
>> > > >>>
>> > > >>>
>> > > >> This was something Alex propose, something in the line of
>> @media
>> > > >> -royale-swf, but with fonts, I think that is the right way.
>> > > >> For now we can stick with the html template but that should be
>> > > >>> temporal.
>> > > >
>> > > >
>> > > 
>> > > 
>> > >  --
>> > >  Carlos Rovira
>> > >  http://about.me/carlosrovira
>> > > >>>
>> > > >>>
>> > > >>
>> > > >>
>> > > >> --
>> > > >> Carlos Rovira
>> > > >> http://about.me/carlosrovira
>> > > >>
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > >
>> > > > Piotr Zarzycki
>> > > >
>> > > > Patreon: 

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

[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] http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/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:
> > > 
> > >  Hi,
> > > 
> > >  I think seems something valid, maybe we should think more about
> > > >> possible
> > >  colateral issue of that method. You should look as well at a
> thread
> > > >> where
> > >  Alex proposed as well some valid options
> > > 
> > >  2018-05-17 15:04 GMT+02:00 Harbs :
> > > 
> > > > I just had another thought which might be even more flexible:
> > > >
> > > > Maybe the compile could parse @includes from CSS and insert them
> as
> > > >>> links
> > > > in the header HTML automatically.
> > > >
> > > > Thanks,
> > > > Harbs
> > > >
> > > >> On May 17, 2018, at 3:52 PM, Carlos Rovira <
> > carlosrov...@apache.org>
> > > > wrote:
> > > >>
> > > >>>
> > > >>> Another angle on this problem might be to allow adding links
> via
> > the
> > > >>> compiler automatically. Not sure exactly what form that might
> > take
> > > > though.
> > > >>>
> > > >>>
> > > >> This was something Alex propose, something in the line of @media
> > > >> -royale-swf, but with fonts, I think that is the right way.
> > > >> For now we can stick with the html template but that should be
> > > >>> temporal.
> > > >
> > > >
> > > 
> > > 
> > >  --
> > >  Carlos Rovira
> > >  http://about.me/carlosrovira
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Carlos Rovira
> > > >> http://about.me/carlosrovira
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Piotr Zarzycki
> > > >
> > > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > > *
> > >
> > >
> >
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

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

[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 
> 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  >
> > >>> wrote:
> > 
> >  Hi,
> > 
> >  I think seems something valid, maybe we should think more about
> > >> possible
> >  colateral issue of that method. You should look as well at a thread
> > >> where
> >  Alex proposed as well some valid options
> > 
> >  2018-05-17 15:04 GMT+02:00 Harbs :
> > 
> > > I just had another thought which might be even more flexible:
> > >
> > > Maybe the compile could parse @includes from CSS and insert them as
> > >>> links
> > > in the header HTML automatically.
> > >
> > > Thanks,
> > > Harbs
> > >
> > >> On May 17, 2018, at 3:52 PM, Carlos Rovira <
> carlosrov...@apache.org>
> > > wrote:
> > >>
> > >>>
> > >>> Another angle on this problem might be to allow adding links via
> the
> > >>> compiler automatically. Not sure exactly what form that might
> take
> > > though.
> > >>>
> > >>>
> > >> This was something Alex propose, something in the line of @media
> > >> -royale-swf, but with fonts, I think that is the right way.
> > >> For now we can stick with the html template but that should be
> > >>> temporal.
> > >
> > >
> > 
> > 
> >  --
> >  Carlos Rovira
> >  http://about.me/carlosrovira
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >> Carlos Rovira
> > >> http://about.me/carlosrovira
> > >>
> > >
> > >
> > >
> > > --
> > >
> > > Piotr Zarzycki
> > >
> > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > *
> >
> >
>



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

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

[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  
> > 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 
> >>> wrote:
>  
>  Hi,
>  
>  I think seems something valid, maybe we should think more about
> >> possible
>  colateral issue of that method. You should look as well at a thread
> >> where
>  Alex proposed as well some valid options
>  
>  2018-05-17 15:04 GMT+02:00 Harbs :
>  
> > I just had another thought which might be even more flexible:
> > 
> > Maybe the compile could parse @includes from CSS and insert them as
> >>> links
> > in the header HTML automatically.
> > 
> > Thanks,
> > Harbs
> > 
> >> On May 17, 2018, at 3:52 PM, Carlos Rovira 
> > wrote:
> >> 
> >>> 
> >>> Another angle on this problem might be to allow adding links via the
> >>> compiler automatically. Not sure exactly what form that might take
> > though.
> >>> 
> >>> 
> >> This was something Alex propose, something in the line of @media
> >> -royale-swf, but with fonts, I think that is the right way.
> >> For now we can stick with the html template but that should be
> >>> temporal.
> > 
> > 
>  
>  
>  --
>  Carlos Rovira
>  http://about.me/carlosrovira
> >>> 
> >>> 
> >> 
> >> 
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >> 
> > 
> > 
> > 
> > -- 
> > 
> > Piotr Zarzycki
> > 
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > *
> 
> 

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

[Carlos Rovira]

what was the way FlashBuilder or IntelliJ work about this?
I assume that if Maven is using this is since the compiler supports it, so
-theme should work, and IDEs should leverage that compiler argument.
Hope Alex could throw some light on this, I remember he tries Jewel some
weeks ago successfully (I think with ANT)

2018-05-18 15:05 GMT+02:00 Harbs :

> 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 
> 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 
> >>> wrote:
> 
>  Hi,
> 
>  I think seems something valid, maybe we should think more about
> >> possible
>  colateral issue of that method. You should look as well at a thread
> >> where
>  Alex proposed as well some valid options
> 
>  2018-05-17 15:04 GMT+02:00 Harbs :
> 
> > I just had another thought which might be even more flexible:
> >
> > Maybe the compile could parse @includes from CSS and insert them as
> >>> links
> > in the header HTML automatically.
> >
> > Thanks,
> > Harbs
> >
> >> On May 17, 2018, at 3:52 PM, Carlos Rovira  >
> > wrote:
> >>
> >>>
> >>> Another angle on this problem might be to allow adding links via
> the
> >>> compiler automatically. Not sure exactly what form that might take
> > though.
> >>>
> >>>
> >> This was something Alex propose, something in the line of @media
> >> -royale-swf, but with fonts, I think that is the right way.
> >> For now we can stick with the html template but that should be
> >>> temporal.
> >
> >
> 
> 
>  --
>  Carlos Rovira
>  http://about.me/carlosrovira
> >>>
> >>>
> >>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >>
> >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > *
>
>


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

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

[Harbs]

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  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 
>>> wrote:
 
 Hi,
 
 I think seems something valid, maybe we should think more about
>> possible
 colateral issue of that method. You should look as well at a thread
>> where
 Alex proposed as well some valid options
 
 2018-05-17 15:04 GMT+02:00 Harbs :
 
> I just had another thought which might be even more flexible:
> 
> Maybe the compile could parse @includes from CSS and insert them as
>>> links
> in the header HTML automatically.
> 
> Thanks,
> Harbs
> 
>> On May 17, 2018, at 3:52 PM, Carlos Rovira 
> wrote:
>> 
>>> 
>>> Another angle on this problem might be to allow adding links via the
>>> compiler automatically. Not sure exactly what form that might take
> though.
>>> 
>>> 
>> This was something Alex propose, something in the line of @media
>> -royale-swf, but with fonts, I think that is the right way.
>> For now we can stick with the html template but that should be
>>> temporal.
> 
> 
 
 
 --
 Carlos Rovira
 http://about.me/carlosrovira
>>> 
>>> 
>> 
>> 
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>> 
> 
> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> *

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

[Piotr Zarzycki]

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 
> > wrote:
> > >
> > > Hi,
> > >
> > > I think seems something valid, maybe we should think more about
> possible
> > > colateral issue of that method. You should look as well at a thread
> where
> > > Alex proposed as well some valid options
> > >
> > > 2018-05-17 15:04 GMT+02:00 Harbs :
> > >
> > >> I just had another thought which might be even more flexible:
> > >>
> > >> Maybe the compile could parse @includes from CSS and insert them as
> > links
> > >> in the header HTML automatically.
> > >>
> > >> Thanks,
> > >> Harbs
> > >>
> > >>> On May 17, 2018, at 3:52 PM, Carlos Rovira 
> > >> wrote:
> > >>>
> > 
> >  Another angle on this problem might be to allow adding links via the
> >  compiler automatically. Not sure exactly what form that might take
> > >> though.
> > 
> > 
> > >>> This was something Alex propose, something in the line of @media
> > >>> -royale-swf, but with fonts, I think that is the right way.
> > >>> For now we can stick with the html template but that should be
> > temporal.
> > >>
> > >>
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

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

[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 
> wrote:
> >
> > Hi,
> >
> > I think seems something valid, maybe we should think more about possible
> > colateral issue of that method. You should look as well at a thread where
> > Alex proposed as well some valid options
> >
> > 2018-05-17 15:04 GMT+02:00 Harbs :
> >
> >> I just had another thought which might be even more flexible:
> >>
> >> Maybe the compile could parse @includes from CSS and insert them as
> links
> >> in the header HTML automatically.
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On May 17, 2018, at 3:52 PM, Carlos Rovira 
> >> wrote:
> >>>
> 
>  Another angle on this problem might be to allow adding links via the
>  compiler automatically. Not sure exactly what form that might take
> >> though.
> 
> 
> >>> This was something Alex propose, something in the line of @media
> >>> -royale-swf, but with fonts, I think that is the right way.
> >>> For now we can stick with the html template but that should be
> temporal.
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

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

[Harbs]

What was the subject?

> On May 17, 2018, at 4:08 PM, Carlos Rovira  wrote:
> 
> Hi,
> 
> I think seems something valid, maybe we should think more about possible
> colateral issue of that method. You should look as well at a thread where
> Alex proposed as well some valid options
> 
> 2018-05-17 15:04 GMT+02:00 Harbs :
> 
>> I just had another thought which might be even more flexible:
>> 
>> Maybe the compile could parse @includes from CSS and insert them as links
>> in the header HTML automatically.
>> 
>> Thanks,
>> Harbs
>> 
>>> On May 17, 2018, at 3:52 PM, Carlos Rovira 
>> wrote:
>>> 
 
 Another angle on this problem might be to allow adding links via the
 compiler automatically. Not sure exactly what form that might take
>> though.
 
 
>>> This was something Alex propose, something in the line of @media
>>> -royale-swf, but with fonts, I think that is the right way.
>>> For now we can stick with the html template but that should be temporal.
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

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

[Carlos Rovira]

Hi,

I think seems something valid, maybe we should think more about possible
colateral issue of that method. You should look as well at a thread where
Alex proposed as well some valid options

2018-05-17 15:04 GMT+02:00 Harbs :

> I just had another thought which might be even more flexible:
>
> Maybe the compile could parse @includes from CSS and insert them as links
> in the header HTML automatically.
>
> Thanks,
> Harbs
>
> > On May 17, 2018, at 3:52 PM, Carlos Rovira 
> wrote:
> >
> >>
> >> Another angle on this problem might be to allow adding links via the
> >> compiler automatically. Not sure exactly what form that might take
> though.
> >>
> >>
> > This was something Alex propose, something in the line of @media
> > -royale-swf, but with fonts, I think that is the right way.
> > For now we can stick with the html template but that should be temporal.
>
>


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

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

[Harbs]

I just had another thought which might be even more flexible:

Maybe the compile could parse @includes from CSS and insert them as links in 
the header HTML automatically.

Thanks,
Harbs

> On May 17, 2018, at 3:52 PM, Carlos Rovira  wrote:
> 
>> 
>> Another angle on this problem might be to allow adding links via the
>> compiler automatically. Not sure exactly what form that might take though.
>> 
>> 
> This was something Alex propose, something in the line of @media
> -royale-swf, but with fonts, I think that is the right way.
> For now we can stick with the html template but that should be temporal.

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

[Carlos Rovira]

Hi Harbs

2018-05-17 14:40 GMT+02:00 Harbs :

> Interesting.
>
> Why is deferred loading a problem? Adding the font to the header should
> have the same effect. Shouldn’t it?
>

No, this way seems to end with the browser capability to load resources in
parallel.


>
> I don’t think we want font flicker anyway.
>
> FWIW, the @import can be added to the theme files by a script too.
>
> I’d be interested in knowing what kind of performance hit @import has
> relative to a standard link. I think avoiding html template is a good thing.
>
> Another angle on this problem might be to allow adding links via the
> compiler automatically. Not sure exactly what form that might take though.
>
>
This was something Alex propose, something in the line of @media
-royale-swf, but with fonts, I think that is the right way.
For now we can stick with the html template but that should be temporal.



> My $0.02,
> Harbs
>
> > On May 17, 2018, at 3:16 PM, Carlos Rovira 
> wrote:
> >
> > we have a bug:
> >
> > https://github.com/apache/royale-compiler/issues/28
> >
> > but as well @import is something we should run away from [1]
> >
> > "You shoud avoid the use of @import because it will defer the loading of
> > the included resource until the file is fetched."
> >
> > [1]
> > https://stackoverflow.com/questions/14676613/how-to-
> import-google-web-font-in-css-file
> >
> >
> > 2018-05-17 14:11 GMT+02:00 Harbs :
> >
> >> More specifically, I believe including this in the css would negate the
> >> need for an HTML template:
> >>
> >> @import url('https://fonts.googleapis.com/css?family=Lato:400,700’);
> >>
> >>> On May 17, 2018, at 3:04 PM, Harbs  wrote:
> >>>
> >>> Why not just include the font in the CSS file?[1]
> >>>
> >>> [1]https://css-tricks.com/snippets/css/using-font-face/ <
> >> https://css-tricks.com/snippets/css/using-font-face/>
>  On May 17, 2018, at 2:57 PM, Carlos Rovira  >> > wrote:
> 
>  One more thing, we have as in MDL the use of an html template:
> 
>  
>  ${basedir}/target/javascript/bin/js-debug/jewel-example-
> >> index-template.html
>  
> 
>  but only to get the FONT:
> 
>  https://fonts.googleapis.com/css?family=Lato:400,700 <
> >> https://fonts.googleapis.com/css?family=Lato:400,700>" rel=
>  "stylesheet">
> >>>
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

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

[Harbs]

Interesting. 

Why is deferred loading a problem? Adding the font to the header should have 
the same effect. Shouldn’t it?

I don’t think we want font flicker anyway.

FWIW, the @import can be added to the theme files by a script too.

I’d be interested in knowing what kind of performance hit @import has relative 
to a standard link. I think avoiding html template is a good thing.

Another angle on this problem might be to allow adding links via the compiler 
automatically. Not sure exactly what form that might take though.

My $0.02,
Harbs

> On May 17, 2018, at 3:16 PM, Carlos Rovira  wrote:
> 
> we have a bug:
> 
> https://github.com/apache/royale-compiler/issues/28
> 
> but as well @import is something we should run away from [1]
> 
> "You shoud avoid the use of @import because it will defer the loading of
> the included resource until the file is fetched."
> 
> [1]
> https://stackoverflow.com/questions/14676613/how-to-import-google-web-font-in-css-file
> 
> 
> 2018-05-17 14:11 GMT+02:00 Harbs :
> 
>> More specifically, I believe including this in the css would negate the
>> need for an HTML template:
>> 
>> @import url('https://fonts.googleapis.com/css?family=Lato:400,700’);
>> 
>>> On May 17, 2018, at 3:04 PM, Harbs  wrote:
>>> 
>>> Why not just include the font in the CSS file?[1]
>>> 
>>> [1]https://css-tricks.com/snippets/css/using-font-face/ <
>> https://css-tricks.com/snippets/css/using-font-face/>
 On May 17, 2018, at 2:57 PM, Carlos Rovira > > wrote:
 
 One more thing, we have as in MDL the use of an html template:
 
 
 ${basedir}/target/javascript/bin/js-debug/jewel-example-
>> index-template.html
 
 
 but only to get the FONT:
 
 https://fonts.googleapis.com/css?family=Lato:400,700 <
>> https://fonts.googleapis.com/css?family=Lato:400,700>" rel=
 "stylesheet">
>>> 
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

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

[Carlos Rovira]

we have a bug:

https://github.com/apache/royale-compiler/issues/28

but as well @import is something we should run away from [1]

"You shoud avoid the use of @import because it will defer the loading of
the included resource until the file is fetched."

[1]
https://stackoverflow.com/questions/14676613/how-to-import-google-web-font-in-css-file


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

> More specifically, I believe including this in the css would negate the
> need for an HTML template:
>
> @import url('https://fonts.googleapis.com/css?family=Lato:400,700’);
>
> > On May 17, 2018, at 3:04 PM, Harbs  wrote:
> >
> > Why not just include the font in the CSS file?[1]
> >
> > [1]https://css-tricks.com/snippets/css/using-font-face/ <
> https://css-tricks.com/snippets/css/using-font-face/>
> >> On May 17, 2018, at 2:57 PM, Carlos Rovira  > wrote:
> >>
> >> One more thing, we have as in MDL the use of an html template:
> >>
> >> 
> >> ${basedir}/target/javascript/bin/js-debug/jewel-example-
> index-template.html
> >> 
> >>
> >> but only to get the FONT:
> >>
> >> https://fonts.googleapis.com/css?family=Lato:400,700 <
> https://fonts.googleapis.com/css?family=Lato:400,700>" rel=
> >> "stylesheet">
> >
>
>


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

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

[Harbs]

Thanks. FWIW, the compiler option seems to be “theme”.

If the full path needs to be specified, this is a problem. Is there any way to 
specify a theme by just the theme name? (Question for however might know the 
answer.)

Harbs

> On May 17, 2018, at 3:11 PM, Carlos Rovira  wrote:
> 
> I think it should be
> 
> theme_arg=-theme=
> 
> (not tested by be)
> 
> 2018-05-17 14:02 GMT+02:00 Harbs :
> 
>> What compiler option is used to specify a theme? (Assuming the command
>> line is being used — not Maven, ant or what-have-you.)
>> 
>>> On May 17, 2018, at 2:57 PM, Carlos Rovira 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> (renaming to this thread since is not related directly to the old one and
>>> is more a "doc" email)
>>> 
>>> To setup a theme in jewel, the best is look at JewelExample's pom.xml. I
>>> think Alex already make the ANT's files needed to this.
>>> IDE should have some way to achieve this like in Flex. I think this was
>>> made using -theme like in flex. Please look in the list for "-theme"
>> since
>>> I can recall this is how the compiler consume the styles.
>>> 
>>> About how I set up in MAVEN:
>>> 
>>> We have a "master" Theme:
>>> 
>>> 
>>> org.apache.royale.framework
>>> JewelTheme
>>> 0.9.4-SNAPSHOT
>>> swc
>>> theme
>>> js
>>> 
>>> 
>>> This theme is the one that can create all the combinations of other
>> themes,
>>> changing variables in *_themes.sass*
>>> 
>>> //Theme variables (Flat/No Flat - Dark/Light -
>> Primary/Secondary/Emphasized
>>> Color
>>> $flat: false
>>> $dark: false
>>> $primary-color: $blue
>>> $secondary-color: $topaz
>>> $emphasized-color: $emerald
>>> 
>>> So if you set flat to "true", you'll get the generated css flat, and if
>> you
>>> change $blue to $amethyst, should get sass calculate the right colors to
>>> get the final CSS, finaly $dark will make theme dark or light.
>>> 
>>> To avoid people need to use SASS, I decided to create all possible
>> compiled
>>> versions. Right now I just committed the half. I still have to create the
>>> other half themes.
>>> 
>>> So instead of use the above and generate the final css with SASS, people
>>> not using SASS, can change for :
>>> 
>>> 
>>> org.apache.royale.framework
>>> Jewel-Light-NoFlat-Primary-Blue-Theme
>>> 0.9.4-SNAPSHOT
>>> swc
>>> theme
>>> js
>>> 
>>> 
>>> org.apache.royale.framework
>>> Jewel-Light-NoFlat-Secondary-Topaz-Theme
>>> 0.9.4-SNAPSHOT
>>> swc
>>> theme
>>> js
>>> 
>>> 
>>> org.apache.royale.framework
>>> Jewel-Light-NoFlat-Emphasized-Emerald-Theme
>>> 0.9.4-SNAPSHOT
>>> swc
>>> theme
>>> 
>>> 
>>> and that will make you use the three pieces needed. Normaly people will
>> use
>>> in this three ones the same configuration of dark-flat, and you can then
>>> use the color combination you want between primary, secondary and
>>> emphasized.
>>> 
>>> Note that all this themes use JewelTheme code as a master theme to
>> generate
>>> the corresponding CSS
>>> 
>>> in the final app all this style rules will be merged into one thanks to
>> the
>>> royale compiler processing.
>>> 
>>> One more thing, we have as in MDL the use of an html template:
>>> 
>>> 
>>> ${basedir}/target/javascript/bin/js-debug/jewel-example-
>> index-template.html
>>> 
>>> 
>>> but only to get the FONT:
>>> 
>>> https://fonts.googleapis.com/css?family=Lato:400,700; rel=
>>> "stylesheet">
>>> 
>>> I expect at some time we can remove that need since we implement one of
>> the
>>> options Alex expose for the incorporation of different fonts, hopefully
>>> soon.
>>> 
>>> There's no more needs, hope this clear better how to use Jewel.
>>> 
>>> Thanks
>>> 
>>> Carlos
>>> 
>>> 
>>> 2018-05-17 13:33 GMT+02:00 Harbs :
>>> 
 I see the following in the pom:
   
 org.apache.royale.framework
 Jewel-Light-NoFlat-Primary-Blue-Theme
 0.9.4-SNAPSHOT
 swc
 theme
 js
   
 
 It looks like there’s no default theme for Jewel. Should that be fixed?
 
 How are themes specified to the compiler?
 
> On May 17, 2018, at 2:26 PM, Harbs  wrote:
> 
> Oh. I guess that’s why the styling did not work.
> 
> Carlos, what compiler options are needed for Jewel?
> 
> Harbs
> 
>> On May 17, 2018, at 2:23 PM, Piotr Zarzycki <
>> piotrzarzyck...@gmail.com>
 wrote:
>> 
>> This is another issue. You cannot build those examples using IDE. I
 think
>> we should raise on GitHub. I also cannot build those examples in
 Moonshine.
>> Something needs to be configured. Probably some additional args for
>> compiler related to theme etc.
>> 
>> 2018-05-17 13:18 GMT+02:00 Harbs :
>> 
>>> VSCode using asconfigc
>>> 
 On May 17, 2018, at 12:57 PM, Piotr Zarzycki <
 piotrzarzyck...@gmail.com>
>>> wrote:
 
 Harbs,
 
 How did you build the 

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

[Carlos Rovira]

Font should be easily configurable by the user and I think we have a
problem in the compiler to use that kind of css in that article, (I'm
recheck this)


2018-05-17 14:04 GMT+02:00 Harbs :

> Why not just include the font in the CSS file?[1]
>
> [1]https://css-tricks.com/snippets/css/using-font-face/ <
> https://css-tricks.com/snippets/css/using-font-face/>
> > On May 17, 2018, at 2:57 PM, Carlos Rovira 
> wrote:
> >
> > One more thing, we have as in MDL the use of an html template:
> >
> > 
> > ${basedir}/target/javascript/bin/js-debug/jewel-example-
> index-template.html
> > 
> >
> > but only to get the FONT:
> >
> > https://fonts.googleapis.com/css?family=Lato:400,700 <
> https://fonts.googleapis.com/css?family=Lato:400,700>" rel=
> > "stylesheet">
>
>


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

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

[Harbs]

More specifically, I believe including this in the css would negate the need 
for an HTML template:

@import url('https://fonts.googleapis.com/css?family=Lato:400,700’);

> On May 17, 2018, at 3:04 PM, Harbs  wrote:
> 
> Why not just include the font in the CSS file?[1]
> 
> [1]https://css-tricks.com/snippets/css/using-font-face/ 
> 
>> On May 17, 2018, at 2:57 PM, Carlos Rovira > > wrote:
>> 
>> One more thing, we have as in MDL the use of an html template:
>> 
>> 
>> ${basedir}/target/javascript/bin/js-debug/jewel-example-index-template.html
>> 
>> 
>> but only to get the FONT:
>> 
>> https://fonts.googleapis.com/css?family=Lato:400,700 
>> " rel=
>> "stylesheet">
> 

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

[Carlos Rovira]

I think it should be

theme_arg=-theme=

(not tested by be)

2018-05-17 14:02 GMT+02:00 Harbs :

> What compiler option is used to specify a theme? (Assuming the command
> line is being used — not Maven, ant or what-have-you.)
>
> > On May 17, 2018, at 2:57 PM, Carlos Rovira 
> wrote:
> >
> > Hi,
> >
> > (renaming to this thread since is not related directly to the old one and
> > is more a "doc" email)
> >
> > To setup a theme in jewel, the best is look at JewelExample's pom.xml. I
> > think Alex already make the ANT's files needed to this.
> > IDE should have some way to achieve this like in Flex. I think this was
> > made using -theme like in flex. Please look in the list for "-theme"
> since
> > I can recall this is how the compiler consume the styles.
> >
> > About how I set up in MAVEN:
> >
> > We have a "master" Theme:
> >
> > 
> > org.apache.royale.framework
> > JewelTheme
> > 0.9.4-SNAPSHOT
> > swc
> > theme
> > js
> > 
> >
> > This theme is the one that can create all the combinations of other
> themes,
> > changing variables in *_themes.sass*
> >
> > //Theme variables (Flat/No Flat - Dark/Light -
> Primary/Secondary/Emphasized
> > Color
> > $flat: false
> > $dark: false
> > $primary-color: $blue
> > $secondary-color: $topaz
> > $emphasized-color: $emerald
> >
> > So if you set flat to "true", you'll get the generated css flat, and if
> you
> > change $blue to $amethyst, should get sass calculate the right colors to
> > get the final CSS, finaly $dark will make theme dark or light.
> >
> > To avoid people need to use SASS, I decided to create all possible
> compiled
> > versions. Right now I just committed the half. I still have to create the
> > other half themes.
> >
> > So instead of use the above and generate the final css with SASS, people
> > not using SASS, can change for :
> >
> > 
> > org.apache.royale.framework
> > Jewel-Light-NoFlat-Primary-Blue-Theme
> > 0.9.4-SNAPSHOT
> > swc
> > theme
> > js
> > 
> > 
> > org.apache.royale.framework
> > Jewel-Light-NoFlat-Secondary-Topaz-Theme
> > 0.9.4-SNAPSHOT
> > swc
> > theme
> > js
> > 
> > 
> > org.apache.royale.framework
> > Jewel-Light-NoFlat-Emphasized-Emerald-Theme
> > 0.9.4-SNAPSHOT
> > swc
> > theme
> > 
> >
> > and that will make you use the three pieces needed. Normaly people will
> use
> > in this three ones the same configuration of dark-flat, and you can then
> > use the color combination you want between primary, secondary and
> > emphasized.
> >
> > Note that all this themes use JewelTheme code as a master theme to
> generate
> > the corresponding CSS
> >
> > in the final app all this style rules will be merged into one thanks to
> the
> > royale compiler processing.
> >
> > One more thing, we have as in MDL the use of an html template:
> >
> > 
> > ${basedir}/target/javascript/bin/js-debug/jewel-example-
> index-template.html
> > 
> >
> > but only to get the FONT:
> >
> > https://fonts.googleapis.com/css?family=Lato:400,700; rel=
> > "stylesheet">
> >
> > I expect at some time we can remove that need since we implement one of
> the
> > options Alex expose for the incorporation of different fonts, hopefully
> > soon.
> >
> > There's no more needs, hope this clear better how to use Jewel.
> >
> > Thanks
> >
> > Carlos
> >
> >
> > 2018-05-17 13:33 GMT+02:00 Harbs :
> >
> >> I see the following in the pom:
> >>
> >>  org.apache.royale.framework
> >>  Jewel-Light-NoFlat-Primary-Blue-Theme
> >>  0.9.4-SNAPSHOT
> >>  swc
> >>  theme
> >>  js
> >>
> >>
> >> It looks like there’s no default theme for Jewel. Should that be fixed?
> >>
> >> How are themes specified to the compiler?
> >>
> >>> On May 17, 2018, at 2:26 PM, Harbs  wrote:
> >>>
> >>> Oh. I guess that’s why the styling did not work.
> >>>
> >>> Carlos, what compiler options are needed for Jewel?
> >>>
> >>> Harbs
> >>>
>  On May 17, 2018, at 2:23 PM, Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
> >> wrote:
> 
>  This is another issue. You cannot build those examples using IDE. I
> >> think
>  we should raise on GitHub. I also cannot build those examples in
> >> Moonshine.
>  Something needs to be configured. Probably some additional args for
>  compiler related to theme etc.
> 
>  2018-05-17 13:18 GMT+02:00 Harbs :
> 
> > VSCode using asconfigc
> >
> >> On May 17, 2018, at 12:57 PM, Piotr Zarzycki <
> >> piotrzarzyck...@gmail.com>
> > wrote:
> >>
> >> Harbs,
> >>
> >> How did you build the examples? Using VSCode or script ant/maven ?
> >>
> >> Thanks,
> >> Piotr
> >>
> >> 2018-05-17 11:55 GMT+02:00 Harbs  harbs.li...@gmail.com>>:
> >>
> >>> FWIW, it looks to me like the only thing that will not work in the
> >> blog
> >>> post is  needs to be  and  needs to
> be
> >>> 
> >>>
> >>> Although 

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

[Harbs]

Why not just include the font in the CSS file?[1]

[1]https://css-tricks.com/snippets/css/using-font-face/ 

> On May 17, 2018, at 2:57 PM, Carlos Rovira  wrote:
> 
> One more thing, we have as in MDL the use of an html template:
> 
> 
> ${basedir}/target/javascript/bin/js-debug/jewel-example-index-template.html
> 
> 
> but only to get the FONT:
> 
> https://fonts.googleapis.com/css?family=Lato:400,700 
> " rel=
> "stylesheet">

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

[Harbs]

What compiler option is used to specify a theme? (Assuming the command line is 
being used — not Maven, ant or what-have-you.)

> On May 17, 2018, at 2:57 PM, Carlos Rovira  wrote:
> 
> Hi,
> 
> (renaming to this thread since is not related directly to the old one and
> is more a "doc" email)
> 
> To setup a theme in jewel, the best is look at JewelExample's pom.xml. I
> think Alex already make the ANT's files needed to this.
> IDE should have some way to achieve this like in Flex. I think this was
> made using -theme like in flex. Please look in the list for "-theme" since
> I can recall this is how the compiler consume the styles.
> 
> About how I set up in MAVEN:
> 
> We have a "master" Theme:
> 
> 
> org.apache.royale.framework
> JewelTheme
> 0.9.4-SNAPSHOT
> swc
> theme
> js
> 
> 
> This theme is the one that can create all the combinations of other themes,
> changing variables in *_themes.sass*
> 
> //Theme variables (Flat/No Flat - Dark/Light - Primary/Secondary/Emphasized
> Color
> $flat: false
> $dark: false
> $primary-color: $blue
> $secondary-color: $topaz
> $emphasized-color: $emerald
> 
> So if you set flat to "true", you'll get the generated css flat, and if you
> change $blue to $amethyst, should get sass calculate the right colors to
> get the final CSS, finaly $dark will make theme dark or light.
> 
> To avoid people need to use SASS, I decided to create all possible compiled
> versions. Right now I just committed the half. I still have to create the
> other half themes.
> 
> So instead of use the above and generate the final css with SASS, people
> not using SASS, can change for :
> 
> 
> org.apache.royale.framework
> Jewel-Light-NoFlat-Primary-Blue-Theme
> 0.9.4-SNAPSHOT
> swc
> theme
> js
> 
> 
> org.apache.royale.framework
> Jewel-Light-NoFlat-Secondary-Topaz-Theme
> 0.9.4-SNAPSHOT
> swc
> theme
> js
> 
> 
> org.apache.royale.framework
> Jewel-Light-NoFlat-Emphasized-Emerald-Theme
> 0.9.4-SNAPSHOT
> swc
> theme
> 
> 
> and that will make you use the three pieces needed. Normaly people will use
> in this three ones the same configuration of dark-flat, and you can then
> use the color combination you want between primary, secondary and
> emphasized.
> 
> Note that all this themes use JewelTheme code as a master theme to generate
> the corresponding CSS
> 
> in the final app all this style rules will be merged into one thanks to the
> royale compiler processing.
> 
> One more thing, we have as in MDL the use of an html template:
> 
> 
> ${basedir}/target/javascript/bin/js-debug/jewel-example-index-template.html
> 
> 
> but only to get the FONT:
> 
> https://fonts.googleapis.com/css?family=Lato:400,700; rel=
> "stylesheet">
> 
> I expect at some time we can remove that need since we implement one of the
> options Alex expose for the incorporation of different fonts, hopefully
> soon.
> 
> There's no more needs, hope this clear better how to use Jewel.
> 
> Thanks
> 
> Carlos
> 
> 
> 2018-05-17 13:33 GMT+02:00 Harbs :
> 
>> I see the following in the pom:
>>
>>  org.apache.royale.framework
>>  Jewel-Light-NoFlat-Primary-Blue-Theme
>>  0.9.4-SNAPSHOT
>>  swc
>>  theme
>>  js
>>
>> 
>> It looks like there’s no default theme for Jewel. Should that be fixed?
>> 
>> How are themes specified to the compiler?
>> 
>>> On May 17, 2018, at 2:26 PM, Harbs  wrote:
>>> 
>>> Oh. I guess that’s why the styling did not work.
>>> 
>>> Carlos, what compiler options are needed for Jewel?
>>> 
>>> Harbs
>>> 
 On May 17, 2018, at 2:23 PM, Piotr Zarzycki 
>> wrote:
 
 This is another issue. You cannot build those examples using IDE. I
>> think
 we should raise on GitHub. I also cannot build those examples in
>> Moonshine.
 Something needs to be configured. Probably some additional args for
 compiler related to theme etc.
 
 2018-05-17 13:18 GMT+02:00 Harbs :
 
> VSCode using asconfigc
> 
>> On May 17, 2018, at 12:57 PM, Piotr Zarzycki <
>> piotrzarzyck...@gmail.com>
> wrote:
>> 
>> Harbs,
>> 
>> How did you build the examples? Using VSCode or script ant/maven ?
>> 
>> Thanks,
>> Piotr
>> 
>> 2018-05-17 11:55 GMT+02:00 Harbs >:
>> 
>>> FWIW, it looks to me like the only thing that will not work in the
>> blog
>>> post is  needs to be  and  needs to be
>>> 
>>> 
>>> Although when I compile styles are definitely missing.
>>> 
>>> Yeah. Jewel is definitely missing important pieces… :-(
>>> 
>>> Harbs
>>> 
 On May 17, 2018, at 12:40 PM, Harbs  wrote:
 
 You are right. I missed this.
 
 What is the minimum change necessary to get this to work?
 
> On May 17, 2018, at 12:24 PM, Carlos Rovira <
>> 

Re: 0.9.3 Release

[Carlos Rovira]

Hi Harbs, just create a new thread from this. check it out! :)

2018-05-17 13:33 GMT+02:00 Harbs :

> I see the following in the pom:
> 
>   org.apache.royale.framework
>   Jewel-Light-NoFlat-Primary-Blue-Theme
>   0.9.4-SNAPSHOT
>   swc
>   theme
>   js
> 
>
> It looks like there’s no default theme for Jewel. Should that be fixed?
>
> How are themes specified to the compiler?
>
> > On May 17, 2018, at 2:26 PM, Harbs  wrote:
> >
> > Oh. I guess that’s why the styling did not work.
> >
> > Carlos, what compiler options are needed for Jewel?
> >
> > Harbs
> >
> >> On May 17, 2018, at 2:23 PM, Piotr Zarzycki 
> wrote:
> >>
> >> This is another issue. You cannot build those examples using IDE. I
> think
> >> we should raise on GitHub. I also cannot build those examples in
> Moonshine.
> >> Something needs to be configured. Probably some additional args for
> >> compiler related to theme etc.
> >>
> >> 2018-05-17 13:18 GMT+02:00 Harbs :
> >>
> >>> VSCode using asconfigc
> >>>
>  On May 17, 2018, at 12:57 PM, Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
> >>> wrote:
> 
>  Harbs,
> 
>  How did you build the examples? Using VSCode or script ant/maven ?
> 
>  Thanks,
>  Piotr
> 
>  2018-05-17 11:55 GMT+02:00 Harbs >> harbs.li...@gmail.com>>:
> 
> > FWIW, it looks to me like the only thing that will not work in the
> blog
> > post is  needs to be  and  needs to be
> > 
> >
> > Although when I compile styles are definitely missing.
> >
> > Yeah. Jewel is definitely missing important pieces… :-(
> >
> > Harbs
> >
> >> On May 17, 2018, at 12:40 PM, Harbs  wrote:
> >>
> >> You are right. I missed this.
> >>
> >> What is the minimum change necessary to get this to work?
> >>
> >>> On May 17, 2018, at 12:24 PM, Carlos Rovira <
> carlosrov...@apache.org
> > >>
> >>> wrote:
> >>>
> >>> I think you missed one important point I
> >>> posted in other email: All blog post samples posted that are using
> the
> >>> actual names, packages and namespaces. If you release 0.9.3 without
> >>> all
> >>> that, we can destroy out credibility since in all posts we have:
> >>>
> >>> "The example uses the new Jewel UI set that supports themes. Jewel
> >>> will
> > be
> >>> available in the forthcoming 0.9.3 release of Royale. In the
> meanwhile
> > you
> >>> can find it in the develop branch."
> >>>
> >>> and the code is tailored with the actual api.
> >>>
> >>> For that reason, I think is important to hold 0.9.3 until it can
> ship
> > with
> >>> all that we are promising in website and social networks for the
> >>> latest
> > 2
> >>> months. I think this is crucial.
> >>
> >
> >
> 
> 
>  --
> 
>  Piotr Zarzycki
> 
>  Patreon: *https://www.patreon.com/piotrzarzycki <
> >>> https://www.patreon.com/piotrzarzycki>
>   >>> piotrzarzycki>>*
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon: *https://www.patreon.com/piotrzarzycki
> >> *
> >
>
>


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

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

[Carlos Rovira]

Hi,

(renaming to this thread since is not related directly to the old one and
is more a "doc" email)

To setup a theme in jewel, the best is look at JewelExample's pom.xml. I
think Alex already make the ANT's files needed to this.
IDE should have some way to achieve this like in Flex. I think this was
made using -theme like in flex. Please look in the list for "-theme" since
I can recall this is how the compiler consume the styles.

About how I set up in MAVEN:

We have a "master" Theme:


org.apache.royale.framework
JewelTheme
0.9.4-SNAPSHOT
swc
theme
js


This theme is the one that can create all the combinations of other themes,
changing variables in *_themes.sass*

//Theme variables (Flat/No Flat - Dark/Light - Primary/Secondary/Emphasized
Color
$flat: false
$dark: false
$primary-color: $blue
$secondary-color: $topaz
$emphasized-color: $emerald

So if you set flat to "true", you'll get the generated css flat, and if you
change $blue to $amethyst, should get sass calculate the right colors to
get the final CSS, finaly $dark will make theme dark or light.

To avoid people need to use SASS, I decided to create all possible compiled
versions. Right now I just committed the half. I still have to create the
other half themes.

So instead of use the above and generate the final css with SASS, people
not using SASS, can change for :


org.apache.royale.framework
Jewel-Light-NoFlat-Primary-Blue-Theme
0.9.4-SNAPSHOT
swc
theme
js


org.apache.royale.framework
Jewel-Light-NoFlat-Secondary-Topaz-Theme
0.9.4-SNAPSHOT
swc
theme
js


org.apache.royale.framework
Jewel-Light-NoFlat-Emphasized-Emerald-Theme
0.9.4-SNAPSHOT
swc
theme


and that will make you use the three pieces needed. Normaly people will use
in this three ones the same configuration of dark-flat, and you can then
use the color combination you want between primary, secondary and
emphasized.

Note that all this themes use JewelTheme code as a master theme to generate
the corresponding CSS

in the final app all this style rules will be merged into one thanks to the
royale compiler processing.

One more thing, we have as in MDL the use of an html template:


${basedir}/target/javascript/bin/js-debug/jewel-example-index-template.html


but only to get the FONT:

https://fonts.googleapis.com/css?family=Lato:400,700; rel=
"stylesheet">

I expect at some time we can remove that need since we implement one of the
options Alex expose for the incorporation of different fonts, hopefully
soon.

There's no more needs, hope this clear better how to use Jewel.

Thanks

Carlos


2018-05-17 13:33 GMT+02:00 Harbs :

> I see the following in the pom:
> 
>   org.apache.royale.framework
>   Jewel-Light-NoFlat-Primary-Blue-Theme
>   0.9.4-SNAPSHOT
>   swc
>   theme
>   js
> 
>
> It looks like there’s no default theme for Jewel. Should that be fixed?
>
> How are themes specified to the compiler?
>
> > On May 17, 2018, at 2:26 PM, Harbs  wrote:
> >
> > Oh. I guess that’s why the styling did not work.
> >
> > Carlos, what compiler options are needed for Jewel?
> >
> > Harbs
> >
> >> On May 17, 2018, at 2:23 PM, Piotr Zarzycki 
> wrote:
> >>
> >> This is another issue. You cannot build those examples using IDE. I
> think
> >> we should raise on GitHub. I also cannot build those examples in
> Moonshine.
> >> Something needs to be configured. Probably some additional args for
> >> compiler related to theme etc.
> >>
> >> 2018-05-17 13:18 GMT+02:00 Harbs :
> >>
> >>> VSCode using asconfigc
> >>>
>  On May 17, 2018, at 12:57 PM, Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
> >>> wrote:
> 
>  Harbs,
> 
>  How did you build the examples? Using VSCode or script ant/maven ?
> 
>  Thanks,
>  Piotr
> 
>  2018-05-17 11:55 GMT+02:00 Harbs >> harbs.li...@gmail.com>>:
> 
> > FWIW, it looks to me like the only thing that will not work in the
> blog
> > post is  needs to be  and  needs to be
> > 
> >
> > Although when I compile styles are definitely missing.
> >
> > Yeah. Jewel is definitely missing important pieces… :-(
> >
> > Harbs
> >
> >> On May 17, 2018, at 12:40 PM, Harbs  wrote:
> >>
> >> You are right. I missed this.
> >>
> >> What is the minimum change necessary to get this to work?
> >>
> >>> On May 17, 2018, at 12:24 PM, Carlos Rovira <
> carlosrov...@apache.org
> > >>
> >>> wrote:
> >>>
> >>> I think you missed one important point I
> >>> posted in other email: All blog post samples posted that are using
> the
> >>> actual names, packages and namespaces. If you release 0.9.3 without
> >>> all
> >>> that, we can destroy out credibility since in all posts we have:
> >>>
> >>> "The example uses the new 

Re: 0.9.3 Release

[Harbs]

I see the following in the pom:

  org.apache.royale.framework
  Jewel-Light-NoFlat-Primary-Blue-Theme
  0.9.4-SNAPSHOT
  swc
  theme
  js


It looks like there’s no default theme for Jewel. Should that be fixed?

How are themes specified to the compiler?

> On May 17, 2018, at 2:26 PM, Harbs  wrote:
> 
> Oh. I guess that’s why the styling did not work.
> 
> Carlos, what compiler options are needed for Jewel?
> 
> Harbs
> 
>> On May 17, 2018, at 2:23 PM, Piotr Zarzycki  
>> wrote:
>> 
>> This is another issue. You cannot build those examples using IDE. I think
>> we should raise on GitHub. I also cannot build those examples in Moonshine.
>> Something needs to be configured. Probably some additional args for
>> compiler related to theme etc.
>> 
>> 2018-05-17 13:18 GMT+02:00 Harbs :
>> 
>>> VSCode using asconfigc
>>> 
 On May 17, 2018, at 12:57 PM, Piotr Zarzycki 
>>> wrote:
 
 Harbs,
 
 How did you build the examples? Using VSCode or script ant/maven ?
 
 Thanks,
 Piotr
 
 2018-05-17 11:55 GMT+02:00 Harbs > harbs.li...@gmail.com>>:
 
> FWIW, it looks to me like the only thing that will not work in the blog
> post is  needs to be  and  needs to be
> 
> 
> Although when I compile styles are definitely missing.
> 
> Yeah. Jewel is definitely missing important pieces… :-(
> 
> Harbs
> 
>> On May 17, 2018, at 12:40 PM, Harbs  wrote:
>> 
>> You are right. I missed this.
>> 
>> What is the minimum change necessary to get this to work?
>> 
>>> On May 17, 2018, at 12:24 PM, Carlos Rovira  >>
>>> wrote:
>>> 
>>> I think you missed one important point I
>>> posted in other email: All blog post samples posted that are using the
>>> actual names, packages and namespaces. If you release 0.9.3 without
>>> all
>>> that, we can destroy out credibility since in all posts we have:
>>> 
>>> "The example uses the new Jewel UI set that supports themes. Jewel
>>> will
> be
>>> available in the forthcoming 0.9.3 release of Royale. In the meanwhile
> you
>>> can find it in the develop branch."
>>> 
>>> and the code is tailored with the actual api.
>>> 
>>> For that reason, I think is important to hold 0.9.3 until it can ship
> with
>>> all that we are promising in website and social networks for the
>>> latest
> 2
>>> months. I think this is crucial.
>> 
> 
> 
 
 
 --
 
 Piotr Zarzycki
 
 Patreon: *https://www.patreon.com/piotrzarzycki <
>>> https://www.patreon.com/piotrzarzycki>
 >> piotrzarzycki>>*
>>> 
>>> 
>> 
>> 
>> -- 
>> 
>> Piotr Zarzycki
>> 
>> Patreon: *https://www.patreon.com/piotrzarzycki
>> *
> 

Re: 0.9.3 Release

[Harbs]

Oh. I guess that’s why the styling did not work.

Carlos, what compiler options are needed for Jewel?

Harbs

> On May 17, 2018, at 2:23 PM, Piotr Zarzycki  wrote:
> 
> This is another issue. You cannot build those examples using IDE. I think
> we should raise on GitHub. I also cannot build those examples in Moonshine.
> Something needs to be configured. Probably some additional args for
> compiler related to theme etc.
> 
> 2018-05-17 13:18 GMT+02:00 Harbs :
> 
>> VSCode using asconfigc
>> 
>>> On May 17, 2018, at 12:57 PM, Piotr Zarzycki 
>> wrote:
>>> 
>>> Harbs,
>>> 
>>> How did you build the examples? Using VSCode or script ant/maven ?
>>> 
>>> Thanks,
>>> Piotr
>>> 
>>> 2018-05-17 11:55 GMT+02:00 Harbs  harbs.li...@gmail.com>>:
>>> 
 FWIW, it looks to me like the only thing that will not work in the blog
 post is  needs to be  and  needs to be
 
 
 Although when I compile styles are definitely missing.
 
 Yeah. Jewel is definitely missing important pieces… :-(
 
 Harbs
 
> On May 17, 2018, at 12:40 PM, Harbs  wrote:
> 
> You are right. I missed this.
> 
> What is the minimum change necessary to get this to work?
> 
>> On May 17, 2018, at 12:24 PM, Carlos Rovira >>
>> wrote:
>> 
>> I think you missed one important point I
>> posted in other email: All blog post samples posted that are using the
>> actual names, packages and namespaces. If you release 0.9.3 without
>> all
>> that, we can destroy out credibility since in all posts we have:
>> 
>> "The example uses the new Jewel UI set that supports themes. Jewel
>> will
 be
>> available in the forthcoming 0.9.3 release of Royale. In the meanwhile
 you
>> can find it in the develop branch."
>> 
>> and the code is tailored with the actual api.
>> 
>> For that reason, I think is important to hold 0.9.3 until it can ship
 with
>> all that we are promising in website and social networks for the
>> latest
 2
>> months. I think this is crucial.
> 
 
 
>>> 
>>> 
>>> --
>>> 
>>> Piotr Zarzycki
>>> 
>>> Patreon: *https://www.patreon.com/piotrzarzycki <
>> https://www.patreon.com/piotrzarzycki>
>>> > piotrzarzycki>>*
>> 
>> 
> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> *

Re: 0.9.3 Release

[Piotr Zarzycki]

This is another issue. You cannot build those examples using IDE. I think
we should raise on GitHub. I also cannot build those examples in Moonshine.
Something needs to be configured. Probably some additional args for
compiler related to theme etc.

2018-05-17 13:18 GMT+02:00 Harbs :

> VSCode using asconfigc
>
> > On May 17, 2018, at 12:57 PM, Piotr Zarzycki 
> wrote:
> >
> > Harbs,
> >
> > How did you build the examples? Using VSCode or script ant/maven ?
> >
> > Thanks,
> > Piotr
> >
> > 2018-05-17 11:55 GMT+02:00 Harbs >:
> >
> >> FWIW, it looks to me like the only thing that will not work in the blog
> >> post is  needs to be  and  needs to be
> >> 
> >>
> >> Although when I compile styles are definitely missing.
> >>
> >> Yeah. Jewel is definitely missing important pieces… :-(
> >>
> >> Harbs
> >>
> >>> On May 17, 2018, at 12:40 PM, Harbs  wrote:
> >>>
> >>> You are right. I missed this.
> >>>
> >>> What is the minimum change necessary to get this to work?
> >>>
>  On May 17, 2018, at 12:24 PM, Carlos Rovira  >> >>
> wrote:
> 
>  I think you missed one important point I
>  posted in other email: All blog post samples posted that are using the
>  actual names, packages and namespaces. If you release 0.9.3 without
> all
>  that, we can destroy out credibility since in all posts we have:
> 
>  "The example uses the new Jewel UI set that supports themes. Jewel
> will
> >> be
>  available in the forthcoming 0.9.3 release of Royale. In the meanwhile
> >> you
>  can find it in the develop branch."
> 
>  and the code is tailored with the actual api.
> 
>  For that reason, I think is important to hold 0.9.3 until it can ship
> >> with
>  all that we are promising in website and social networks for the
> latest
> >> 2
>  months. I think this is crucial.
> >>>
> >>
> >>
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki <
> https://www.patreon.com/piotrzarzycki>
> >  piotrzarzycki>>*
>
>


-- 

Piotr Zarzycki

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

Re: 0.9.3 Release

[Harbs]

Please make the list and we’ll take the discussion from there.

> On May 17, 2018, at 2:01 PM, Carlos Rovira  wrote:
> 
> anyway, now that build is working for me is a matter of making the list of
> package name changes if you like

Re: 0.9.3 Release

[Harbs]

VSCode using asconfigc

> On May 17, 2018, at 12:57 PM, Piotr Zarzycki  
> wrote:
> 
> Harbs,
> 
> How did you build the examples? Using VSCode or script ant/maven ?
> 
> Thanks,
> Piotr
> 
> 2018-05-17 11:55 GMT+02:00 Harbs  >:
> 
>> FWIW, it looks to me like the only thing that will not work in the blog
>> post is  needs to be  and  needs to be
>> 
>> 
>> Although when I compile styles are definitely missing.
>> 
>> Yeah. Jewel is definitely missing important pieces… :-(
>> 
>> Harbs
>> 
>>> On May 17, 2018, at 12:40 PM, Harbs  wrote:
>>> 
>>> You are right. I missed this.
>>> 
>>> What is the minimum change necessary to get this to work?
>>> 
 On May 17, 2018, at 12:24 PM, Carlos Rovira > >> wrote:
 
 I think you missed one important point I
 posted in other email: All blog post samples posted that are using the
 actual names, packages and namespaces. If you release 0.9.3 without all
 that, we can destroy out credibility since in all posts we have:
 
 "The example uses the new Jewel UI set that supports themes. Jewel will
>> be
 available in the forthcoming 0.9.3 release of Royale. In the meanwhile
>> you
 can find it in the develop branch."
 
 and the code is tailored with the actual api.
 
 For that reason, I think is important to hold 0.9.3 until it can ship
>> with
 all that we are promising in website and social networks for the latest
>> 2
 months. I think this is crucial.
>>> 
>> 
>> 
> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki 
> 
>  >*

Re: 0.9.3 Release

[Carlos Rovira]

Hi,

jsonly build is finaly fixed.
Looking at the code fixed seems to me almost dead code and things very old
unused now.
as well I was not aware since is based on ANT and not maven, that I thought
all build process in Royale was based on Maven.

anyway, now that build is working for me is a matter of making the list of
package name changes if you like

thanks


2018-05-17 12:03 GMT+02:00 Carlos Rovira :

> Harbs,
> take into account that I don't use to setup ANT files, only Maven.
> ANT files needs to be done, I hope others can contribute that work.
>
> 2018-05-17 11:55 GMT+02:00 Harbs :
>
>> FWIW, it looks to me like the only thing that will not work in the blog
>> post is  needs to be  and  needs to be
>> 
>>
>> Although when I compile styles are definitely missing.
>>
>> Yeah. Jewel is definitely missing important pieces… :-(
>>
>> Harbs
>>
>> > On May 17, 2018, at 12:40 PM, Harbs  wrote:
>> >
>> > You are right. I missed this.
>> >
>> > What is the minimum change necessary to get this to work?
>> >
>> >> On May 17, 2018, at 12:24 PM, Carlos Rovira > > wrote:
>> >>
>> >>  I think you missed one important point I
>> >> posted in other email: All blog post samples posted that are using the
>> >> actual names, packages and namespaces. If you release 0.9.3 without all
>> >> that, we can destroy out credibility since in all posts we have:
>> >>
>> >> "The example uses the new Jewel UI set that supports themes. Jewel
>> will be
>> >> available in the forthcoming 0.9.3 release of Royale. In the meanwhile
>> you
>> >> can find it in the develop branch."
>> >>
>> >> and the code is tailored with the actual api.
>> >>
>> >> For that reason, I think is important to hold 0.9.3 until it can ship
>> with
>> >> all that we are promising in website and social networks for the
>> latest 2
>> >> months. I think this is crucial.
>> >
>>
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>


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

Re: 0.9.3 Release

[Carlos Rovira]

Harbs,
take into account that I don't use to setup ANT files, only Maven.
ANT files needs to be done, I hope others can contribute that work.

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

> FWIW, it looks to me like the only thing that will not work in the blog
> post is  needs to be  and  needs to be
> 
>
> Although when I compile styles are definitely missing.
>
> Yeah. Jewel is definitely missing important pieces… :-(
>
> Harbs
>
> > On May 17, 2018, at 12:40 PM, Harbs  wrote:
> >
> > You are right. I missed this.
> >
> > What is the minimum change necessary to get this to work?
> >
> >> On May 17, 2018, at 12:24 PM, Carlos Rovira  > wrote:
> >>
> >>  I think you missed one important point I
> >> posted in other email: All blog post samples posted that are using the
> >> actual names, packages and namespaces. If you release 0.9.3 without all
> >> that, we can destroy out credibility since in all posts we have:
> >>
> >> "The example uses the new Jewel UI set that supports themes. Jewel will
> be
> >> available in the forthcoming 0.9.3 release of Royale. In the meanwhile
> you
> >> can find it in the develop branch."
> >>
> >> and the code is tailored with the actual api.
> >>
> >> For that reason, I think is important to hold 0.9.3 until it can ship
> with
> >> all that we are promising in website and social networks for the latest
> 2
> >> months. I think this is crucial.
> >
>
>


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

Re: 0.9.3 Release

[Piotr Zarzycki]

Harbs,

How did you build the examples? Using VSCode or script ant/maven ?

Thanks,
Piotr

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

> FWIW, it looks to me like the only thing that will not work in the blog
> post is  needs to be  and  needs to be
> 
>
> Although when I compile styles are definitely missing.
>
> Yeah. Jewel is definitely missing important pieces… :-(
>
> Harbs
>
> > On May 17, 2018, at 12:40 PM, Harbs  wrote:
> >
> > You are right. I missed this.
> >
> > What is the minimum change necessary to get this to work?
> >
> >> On May 17, 2018, at 12:24 PM, Carlos Rovira  > wrote:
> >>
> >>  I think you missed one important point I
> >> posted in other email: All blog post samples posted that are using the
> >> actual names, packages and namespaces. If you release 0.9.3 without all
> >> that, we can destroy out credibility since in all posts we have:
> >>
> >> "The example uses the new Jewel UI set that supports themes. Jewel will
> be
> >> available in the forthcoming 0.9.3 release of Royale. In the meanwhile
> you
> >> can find it in the develop branch."
> >>
> >> and the code is tailored with the actual api.
> >>
> >> For that reason, I think is important to hold 0.9.3 until it can ship
> with
> >> all that we are promising in website and social networks for the latest
> 2
> >> months. I think this is crucial.
> >
>
>


-- 

Piotr Zarzycki

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

Re: 0.9.3 Release

[Harbs]

FWIW, it looks to me like the only thing that will not work in the blog post is 
 needs to be  and  needs to be 


Although when I compile styles are definitely missing.

Yeah. Jewel is definitely missing important pieces… :-(

Harbs

> On May 17, 2018, at 12:40 PM, Harbs  wrote:
> 
> You are right. I missed this.
> 
> What is the minimum change necessary to get this to work?
> 
>> On May 17, 2018, at 12:24 PM, Carlos Rovira > > wrote:
>> 
>>  I think you missed one important point I
>> posted in other email: All blog post samples posted that are using the
>> actual names, packages and namespaces. If you release 0.9.3 without all
>> that, we can destroy out credibility since in all posts we have:
>> 
>> "The example uses the new Jewel UI set that supports themes. Jewel will be
>> available in the forthcoming 0.9.3 release of Royale. In the meanwhile you
>> can find it in the develop branch."
>> 
>> and the code is tailored with the actual api.
>> 
>> For that reason, I think is important to hold 0.9.3 until it can ship with
>> all that we are promising in website and social networks for the latest 2
>> months. I think this is crucial.
> 

Re: 0.9.3 Release

[Harbs]

You are right. I missed this.

What is the minimum change necessary to get this to work?

> On May 17, 2018, at 12:24 PM, Carlos Rovira  wrote:
> 
>  I think you missed one important point I
> posted in other email: All blog post samples posted that are using the
> actual names, packages and namespaces. If you release 0.9.3 without all
> that, we can destroy out credibility since in all posts we have:
> 
> "The example uses the new Jewel UI set that supports themes. Jewel will be
> available in the forthcoming 0.9.3 release of Royale. In the meanwhile you
> can find it in the develop branch."
> 
> and the code is tailored with the actual api.
> 
> For that reason, I think is important to hold 0.9.3 until it can ship with
> all that we are promising in website and social networks for the latest 2
> months. I think this is crucial.

Re: 0.9.3 Release

[Carlos Rovira]

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

> Definitely a plan.
>

Good! :)


>
> My guess is that if we agree on changing package paths, there will likely
> be other classes that should be considered.
>

For sure I think a 1.0 version should not have "core" packages in "Basic"
SWC nor "html" packages in "Core" SWC. I'm pretty sure there's more other
cases that we need to structure, reorganize and clean.


> My preference would be to have this discussion after we finish the project
> refactor discussion because I think it’s going to be related to the outcome
> of that.
>

For me we can do that in parallel but if the rest think the same for me is
ok.


>
> Either way, I don’t think discussion should hold up the 0.9.3 release.
> We’re already past due for a release. We want to “release early and release
> often”… ;-)
>
>
As Piotr, I don't agree with this. I think you missed one important point I
posted in other email: All blog post samples posted that are using the
actual names, packages and namespaces. If you release 0.9.3 without all
that, we can destroy out credibility since in all posts we have:

"The example uses the new Jewel UI set that supports themes. Jewel will be
available in the forthcoming 0.9.3 release of Royale. In the meanwhile you
can find it in the develop branch."

and the code is tailored with the actual api.

For that reason, I think is important to hold 0.9.3 until it can ship with
all that we are promising in website and social networks for the latest 2
months. I think this is crucial.



> Thanks,
> Harbs
>
> > On May 17, 2018, at 12:07 PM, Carlos Rovira 
> wrote:
> >
> > Ok,
> >
> > what if:
> >
> > * I take the time to generate a list of classes with package name changes
> > * Make a thread with the list to expose it
> > * Let's see from there if people can live with it (We'll call people to
> > express about this changes and could see if are or not dramatic to them)
> >
> > Sounds this like a plan?
> >
> > Thanks
> >
> >
> >
> > 2018-05-17 10:58 GMT+02:00 Harbs :
> >
> >> Sure. Same here.
> >>
> >> But things are much more stable now. As we move closer to “1.0”, I think
> >> we should be more careful about breaking changes and documenting them
> when
> >> we decide they are necessary.
> >>
> >> As far as these specific changes go: We haven’t even come to a
> conclusion
> >> on what (if any) package names should change yet, and including those
> >> changes in a release is premature. If we do change package names, I’m of
> >> the opinion that they should be decided on and all happen at once to
> >> minimize impact on end-users.
> >>
> >> Does that help clarify things?
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On May 17, 2018, at 11:49 AM, Justin Mclean 
> >> wrote:
> >>>
> >>> Hi,
> >>>
>  We are at the point where people are using Royale in production. While
> >> we can make breaking changes if they are warranted, they should be kept
> to
> >> an absolute minimum and be carefully considered and well documented if
> we
> >> do.
> >>>
> >>> There has been many previous breaking changes that broke the
> application
> >> I was working on and some more major than this and cost me a lot of
> time to
> >> fix. Until you make it version 1.0 I think people will expect that some
> >> things may break with a new version. So why should this be an exception
> to
> >> what has happened before? Saying that however, what would be good to
> see is
> >> to provide guidance to what users need to change so their app works with
> >> any changes / backward compatibility issues.
> >>>
> >>> Thanks,
> >>> Justin
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

Re: 0.9.3 Release

[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 related to the outcome of 
that.

Either way, I don’t think discussion should hold up the 0.9.3 release. We’re 
already past due for a release. We want to “release early and release often”… 
;-)

Thanks,
Harbs

> On May 17, 2018, at 12:07 PM, Carlos Rovira  wrote:
> 
> Ok,
> 
> what if:
> 
> * I take the time to generate a list of classes with package name changes
> * Make a thread with the list to expose it
> * Let's see from there if people can live with it (We'll call people to
> express about this changes and could see if are or not dramatic to them)
> 
> Sounds this like a plan?
> 
> Thanks
> 
> 
> 
> 2018-05-17 10:58 GMT+02:00 Harbs :
> 
>> Sure. Same here.
>> 
>> But things are much more stable now. As we move closer to “1.0”, I think
>> we should be more careful about breaking changes and documenting them when
>> we decide they are necessary.
>> 
>> As far as these specific changes go: We haven’t even come to a conclusion
>> on what (if any) package names should change yet, and including those
>> changes in a release is premature. If we do change package names, I’m of
>> the opinion that they should be decided on and all happen at once to
>> minimize impact on end-users.
>> 
>> Does that help clarify things?
>> 
>> Thanks,
>> Harbs
>> 
>>> On May 17, 2018, at 11:49 AM, Justin Mclean 
>> wrote:
>>> 
>>> Hi,
>>> 
 We are at the point where people are using Royale in production. While
>> we can make breaking changes if they are warranted, they should be kept to
>> an absolute minimum and be carefully considered and well documented if we
>> do.
>>> 
>>> There has been many previous breaking changes that broke the application
>> I was working on and some more major than this and cost me a lot of time to
>> fix. Until you make it version 1.0 I think people will expect that some
>> things may break with a new version. So why should this be an exception to
>> what has happened before? Saying that however, what would be good to see is
>> to provide guidance to what users need to change so their app works with
>> any changes / backward compatibility issues.
>>> 
>>> Thanks,
>>> Justin
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: 0.9.3 Release

[Piotr Zarzycki]

I think better focus on discussion and have proper solution. Than make the
release.

2018-05-17 11:07 GMT+02:00 Carlos Rovira :

> Ok,
>
> what if:
>
> * I take the time to generate a list of classes with package name changes
> * Make a thread with the list to expose it
> * Let's see from there if people can live with it (We'll call people to
> express about this changes and could see if are or not dramatic to them)
>
> Sounds this like a plan?
>
> Thanks
>
>
>
> 2018-05-17 10:58 GMT+02:00 Harbs :
>
> > Sure. Same here.
> >
> > But things are much more stable now. As we move closer to “1.0”, I think
> > we should be more careful about breaking changes and documenting them
> when
> > we decide they are necessary.
> >
> > As far as these specific changes go: We haven’t even come to a conclusion
> > on what (if any) package names should change yet, and including those
> > changes in a release is premature. If we do change package names, I’m of
> > the opinion that they should be decided on and all happen at once to
> > minimize impact on end-users.
> >
> > Does that help clarify things?
> >
> > Thanks,
> > Harbs
> >
> > > On May 17, 2018, at 11:49 AM, Justin Mclean 
> > wrote:
> > >
> > > Hi,
> > >
> > >> We are at the point where people are using Royale in production. While
> > we can make breaking changes if they are warranted, they should be kept
> to
> > an absolute minimum and be carefully considered and well documented if we
> > do.
> > >
> > > There has been many previous breaking changes that broke the
> application
> > I was working on and some more major than this and cost me a lot of time
> to
> > fix. Until you make it version 1.0 I think people will expect that some
> > things may break with a new version. So why should this be an exception
> to
> > what has happened before? Saying that however, what would be good to see
> is
> > to provide guidance to what users need to change so their app works with
> > any changes / backward compatibility issues.
> > >
> > > Thanks,
> > > Justin
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

Re: 0.9.3 Release

[Harbs]

Sure. Same here.

But things are much more stable now. As we move closer to “1.0”, I think we 
should be more careful about breaking changes and documenting them when we 
decide they are necessary.

As far as these specific changes go: We haven’t even come to a conclusion on 
what (if any) package names should change yet, and including those changes in a 
release is premature. If we do change package names, I’m of the opinion that 
they should be decided on and all happen at once to minimize impact on 
end-users.

Does that help clarify things?

Thanks,
Harbs

> On May 17, 2018, at 11:49 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> We are at the point where people are using Royale in production. While we 
>> can make breaking changes if they are warranted, they should be kept to an 
>> absolute minimum and be carefully considered and well documented if we do.
> 
> There has been many previous breaking changes that broke the application I 
> was working on and some more major than this and cost me a lot of time to 
> fix. Until you make it version 1.0 I think people will expect that some 
> things may break with a new version. So why should this be an exception to 
> what has happened before? Saying that however, what would be good to see is 
> to provide guidance to what users need to change so their app works with any 
> changes / backward compatibility issues.
> 
> Thanks,
> Justin

Re: 0.9.3 Release

[Harbs]

Yes. It definitely makes sense to me.

Let’s get the 0.9.3 release out without breaking changes. If we decide to keep 
Carlos’ changes and/or modify them, there’s no reason it cannot go into 0.9.4.

Thanks,
Harbs

> On May 17, 2018, at 11:30 AM, Piotr Zarzycki  
> wrote:
> 
> Carlos,
> 
> Those changes were not properly discussed. Let's wait till the end of the
> discussion and proper fix. I personally prefer wait even another month than
> release something what can change significantly.
> 
> Is that make sense to others ?
> 
> Thanks, Piotr
> 
> 2018-05-17 10:26 GMT+02:00 Carlos Rovira :
> 
>> Hi,
>> 
>> just find the imports with problems, fix them and committed. If there's no
>> others this should fix the release.
>> 
>> If you see the commit, the changes are easy, and no more of some secs to do
>> for our users, in case they use this core classes.
>> 
>> Let's see what Jenkins reports in the following build
>> 
>> 
>> 2018-05-17 10:16 GMT+02:00 Carlos Rovira :
>> 
>>> Hi Piotr,
>>> 
>>> I think we are getting sufficient progress I the discussion thread to
>>> still think about a revert. I'm most for change things from this point,
>>> that should be the normal way from 0.9.2 to 1.0. We can as well hold a
>> bit
>>> the release until we have cleared all this. As I said, if we revert, and
>>> release 0.9.3 with old code, blog examples will not work at all, and that
>>> will suppose lots of people in the internet trying us and failing.
>>> 
>>> Think that:
>>> 
>>> 1) There's no breaking changes at all about functionality
>>> 2) The change was only:
>>> a) move things from Basic to Core
>>> b) rename packages on some of that 2.a) things
>>> 
>>> 
>>> So the real problem now for me is 2.b) and that's the reason why jsonly
>>> build is failing, since we have things in framework with not examples
>>> referencing it, and since SWCs does not validate CSS beads, when used
>> that
>>> CSS in final app that fails. I think that's for me a major problem, and
>>> will prefer to focus in find that code and fixing it.
>>> 
>>> I'm trying to focus this morning on doing this, and hope to fix on that
>>> way jsonly
>>> 
>>> 
>>> 2018-05-17 10:08 GMT+02:00 Piotr Zarzycki :
>>> 
 It's not about the minor changes in his app in my opinion. In the result
 of
 the discussion it may end up that you will revert everything and
>> solution
 will be completely different. What will be the experience of the created
 app on the user sight ?
 
 2018-05-17 10:05 GMT+02:00 Carlos Rovira :
 
> Hi Harbs,
> 
> that was returned to the old way, actually we have the same than
>> before
> refactor:
> 
> import org.apache.royale.html.Group;
> 
> public class NodeElementBase extends Group
> 
> Maybe the problem is that we don't have any example of ButtonBar in
> examples? and thus I was not aware of that concrete component?
> 
> I'll try to see that and if we need, I'll create and example now for
 that.
> 
> The change to solve this in your code base is really easy and direct:
> 
> search all "import org.apache.royale.html.supportClasses.DataGroup;"
 and
> replace with "import org.apache.royale.core.DataGroup;"
> 
> (for me is clear that DataGroup is a Core piece, that will be used not
 as
> Basic or Jewel implementation, but as a "core" piece used for the rest
 of
> UI sets)
> 
> I'll be looking at it right now
> 
> Thanks for exposing it! :)
> 
> Carlos
> 
> 
> 
> 2018-05-17 8:49 GMT+02:00 Harbs :
> 
>> Having trouble getting this email to “take”. Trying a paste link
> instead...
>> 
>> It looks like it does have issues.
>> 
>> I just pulled the 0.9.3 branch.
>> 
>> I get a lot of these warnings when I compile the framework:
>> https://paste.apache.org/Wy9t 
>> 
>> I used it to compile my app, and I get runtime errors due to missing
>> components. This seems to be due to HTML not subclassing Group.
>> 
>> Here’s an example of elements which go AWAL:
>> https://paste.apache.org/s9og 
>> 
>> Everything below “ul" is missing.
>> 
>> Harbs
>> 
>>> On May 16, 2018, at 10:45 PM, Alex Harui > > wrote:
>>> 
>>> I'm pretty sure the branches were cut before the changes in
 question.
>> You can pull down the branches and build them to verify.  Or look at
> their
>> history on GitHub.
>>> 
>>> Om, did you see a date for when Maven SCM would be released?  The
 only
>> response I got from the Maven folks was to build Maven SCM from
 sources.
>> If it is going to be more 

Re: 0.9.3 Release

[Harbs]

> I only what to said at this regard, that I expect, as we have alll things
> working and think about release 1.0, that before that release, is very
> normal to change packages and names right?

No. I disagree with this.

We are at the point where people are using Royale in production. While we can 
make breaking changes if they are warranted, they should be kept to an absolute 
minimum and be carefully considered and well documented if we do.

My $0.02,
Harbs

> On May 17, 2018, at 11:32 AM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> ok, as I said, package names are not something crucial. It's only something
> we can put back to their old names.
> I only what to said at this regard, that I expect, as we have alll things
> working and think about release 1.0, that before that release, is very
> normal to change packages and names right? (maybe our most near examples
> where Flex releases from beta codenames to final i.e: Jumbo to Flex 4.0,
> many changes where done by Adobe that broke existing applications, but that
> was nothing people will think was bad, since they prefer a better names and
> organization for the major release and to follow in the future)
> 
> If you finally, with all that said, want me to change packages to all way,
> I can do that. As I stated, this is not crucial, only library place is
> (Basic to Core).
> 
> thanks
> 
> 
> 
> 2018-05-17 10:10 GMT+02:00 Harbs :
> 
>> Hi Carlos,
>> 
>> The problem is that any existing applications which subclass or import
>> DataGroup (for example) will break by upgrading to 0.9.3. We don’t want
>> release breaking changes unless we decide that breaking changes are
>> necessary.
>> 
>> We are still discussing that whole topic and this release will likely
>> happen before that discussion is finished.
>> 
>> IMO, it’s better to release less features than release breaking changes
>> which might be reverted.
>> 
>> Thanks,
>> Harbs
>> 
>>> On May 17, 2018, at 11:05 AM, Carlos Rovira 
>> wrote:
>>> 
>>> Hi Harbs,
>>> 
>>> that was returned to the old way, actually we have the same than before
>>> refactor:
>>> 
>>> import org.apache.royale.html.Group;
>>> 
>>> public class NodeElementBase extends Group
>>> 
>>> Maybe the problem is that we don't have any example of ButtonBar in
>>> examples? and thus I was not aware of that concrete component?
>>> 
>>> I'll try to see that and if we need, I'll create and example now for
>> that.
>>> 
>>> The change to solve this in your code base is really easy and direct:
>>> 
>>> search all "import org.apache.royale.html.supportClasses.DataGroup;" and
>>> replace with "import org.apache.royale.core.DataGroup;"
>>> 
>>> (for me is clear that DataGroup is a Core piece, that will be used not as
>>> Basic or Jewel implementation, but as a "core" piece used for the rest of
>>> UI sets)
>>> 
>>> I'll be looking at it right now
>>> 
>>> Thanks for exposing it! :)
>>> 
>>> Carlos
>>> 
>>> 
>>> 
>>> 2018-05-17 8:49 GMT+02:00 Harbs :
>>> 
 Having trouble getting this email to “take”. Trying a paste link
>> instead...
 
 It looks like it does have issues.
 
 I just pulled the 0.9.3 branch.
 
 I get a lot of these warnings when I compile the framework:
 https://paste.apache.org/Wy9t 
 
 I used it to compile my app, and I get runtime errors due to missing
 components. This seems to be due to HTML not subclassing Group.
 
 Here’s an example of elements which go AWAL:
 https://paste.apache.org/s9og 
 
 Everything below “ul" is missing.
 
 Harbs
 
> On May 16, 2018, at 10:45 PM, Alex Harui > wrote:
> 
> I'm pretty sure the branches were cut before the changes in question.
 You can pull down the branches and build them to verify.  Or look at
>> their
 history on GitHub.
> 
> Om, did you see a date for when Maven SCM would be released?  The only
 response I got from the Maven folks was to build Maven SCM from sources.
 If it is going to be more than a week, I might actually try that.
> 
> -Alex
> 
 
 
>>> 
>>> 
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: 0.9.3 Release

[Carlos Rovira]

for me that's ok Piotr too

thanks

2018-05-17 10:30 GMT+02:00 Piotr Zarzycki :

> Carlos,
>
> Those changes were not properly discussed. Let's wait till the end of the
> discussion and proper fix. I personally prefer wait even another month than
> release something what can change significantly.
>
> Is that make sense to others ?
>
> Thanks, Piotr
>
> 2018-05-17 10:26 GMT+02:00 Carlos Rovira :
>
> > Hi,
> >
> > just find the imports with problems, fix them and committed. If there's
> no
> > others this should fix the release.
> >
> > If you see the commit, the changes are easy, and no more of some secs to
> do
> > for our users, in case they use this core classes.
> >
> > Let's see what Jenkins reports in the following build
> >
> >
> > 2018-05-17 10:16 GMT+02:00 Carlos Rovira :
> >
> > > Hi Piotr,
> > >
> > > I think we are getting sufficient progress I the discussion thread to
> > > still think about a revert. I'm most for change things from this point,
> > > that should be the normal way from 0.9.2 to 1.0. We can as well hold a
> > bit
> > > the release until we have cleared all this. As I said, if we revert,
> and
> > > release 0.9.3 with old code, blog examples will not work at all, and
> that
> > > will suppose lots of people in the internet trying us and failing.
> > >
> > > Think that:
> > >
> > > 1) There's no breaking changes at all about functionality
> > > 2) The change was only:
> > >  a) move things from Basic to Core
> > >  b) rename packages on some of that 2.a) things
> > >
> > >
> > > So the real problem now for me is 2.b) and that's the reason why jsonly
> > > build is failing, since we have things in framework with not examples
> > > referencing it, and since SWCs does not validate CSS beads, when used
> > that
> > > CSS in final app that fails. I think that's for me a major problem, and
> > > will prefer to focus in find that code and fixing it.
> > >
> > > I'm trying to focus this morning on doing this, and hope to fix on that
> > > way jsonly
> > >
> > >
> > > 2018-05-17 10:08 GMT+02:00 Piotr Zarzycki :
> > >
> > >> It's not about the minor changes in his app in my opinion. In the
> result
> > >> of
> > >> the discussion it may end up that you will revert everything and
> > solution
> > >> will be completely different. What will be the experience of the
> created
> > >> app on the user sight ?
> > >>
> > >> 2018-05-17 10:05 GMT+02:00 Carlos Rovira :
> > >>
> > >> > Hi Harbs,
> > >> >
> > >> > that was returned to the old way, actually we have the same than
> > before
> > >> > refactor:
> > >> >
> > >> > import org.apache.royale.html.Group;
> > >> >
> > >> > public class NodeElementBase extends Group
> > >> >
> > >> > Maybe the problem is that we don't have any example of ButtonBar in
> > >> > examples? and thus I was not aware of that concrete component?
> > >> >
> > >> > I'll try to see that and if we need, I'll create and example now for
> > >> that.
> > >> >
> > >> > The change to solve this in your code base is really easy and
> direct:
> > >> >
> > >> > search all "import org.apache.royale.html.
> supportClasses.DataGroup;"
> > >> and
> > >> > replace with "import org.apache.royale.core.DataGroup;"
> > >> >
> > >> > (for me is clear that DataGroup is a Core piece, that will be used
> not
> > >> as
> > >> > Basic or Jewel implementation, but as a "core" piece used for the
> rest
> > >> of
> > >> > UI sets)
> > >> >
> > >> > I'll be looking at it right now
> > >> >
> > >> > Thanks for exposing it! :)
> > >> >
> > >> > Carlos
> > >> >
> > >> >
> > >> >
> > >> > 2018-05-17 8:49 GMT+02:00 Harbs :
> > >> >
> > >> > > Having trouble getting this email to “take”. Trying a paste link
> > >> > instead...
> > >> > >
> > >> > > It looks like it does have issues.
> > >> > >
> > >> > > I just pulled the 0.9.3 branch.
> > >> > >
> > >> > > I get a lot of these warnings when I compile the framework:
> > >> > > https://paste.apache.org/Wy9t 
> > >> > >
> > >> > > I used it to compile my app, and I get runtime errors due to
> missing
> > >> > > components. This seems to be due to HTML not subclassing Group.
> > >> > >
> > >> > > Here’s an example of elements which go AWAL:
> > >> > > https://paste.apache.org/s9og 
> > >> > >
> > >> > > Everything below “ul" is missing.
> > >> > >
> > >> > > Harbs
> > >> > >
> > >> > > > On May 16, 2018, at 10:45 PM, Alex Harui
>  > >> > > > wrote:
> > >> > > >
> > >> > > > I'm pretty sure the branches were cut before the changes in
> > >> question.
> > >> > > You can pull down the branches and build them to verify.  Or look
> at
> > >> > their
> > >> > > history on GitHub.
> > >> > > >
> > >> > > > Om, did you see a date for when Maven SCM would be released?
> The
> > >> only
> > >> > 

Re: 0.9.3 Release

[Carlos Rovira]

Hi Harbs,

ok, as I said, package names are not something crucial. It's only something
we can put back to their old names.
I only what to said at this regard, that I expect, as we have alll things
working and think about release 1.0, that before that release, is very
normal to change packages and names right? (maybe our most near examples
where Flex releases from beta codenames to final i.e: Jumbo to Flex 4.0,
many changes where done by Adobe that broke existing applications, but that
was nothing people will think was bad, since they prefer a better names and
organization for the major release and to follow in the future)

If you finally, with all that said, want me to change packages to all way,
I can do that. As I stated, this is not crucial, only library place is
(Basic to Core).

thanks



2018-05-17 10:10 GMT+02:00 Harbs :

> Hi Carlos,
>
> The problem is that any existing applications which subclass or import
> DataGroup (for example) will break by upgrading to 0.9.3. We don’t want
> release breaking changes unless we decide that breaking changes are
> necessary.
>
> We are still discussing that whole topic and this release will likely
> happen before that discussion is finished.
>
> IMO, it’s better to release less features than release breaking changes
> which might be reverted.
>
> Thanks,
> Harbs
>
> > On May 17, 2018, at 11:05 AM, Carlos Rovira 
> wrote:
> >
> > Hi Harbs,
> >
> > that was returned to the old way, actually we have the same than before
> > refactor:
> >
> > import org.apache.royale.html.Group;
> >
> > public class NodeElementBase extends Group
> >
> > Maybe the problem is that we don't have any example of ButtonBar in
> > examples? and thus I was not aware of that concrete component?
> >
> > I'll try to see that and if we need, I'll create and example now for
> that.
> >
> > The change to solve this in your code base is really easy and direct:
> >
> > search all "import org.apache.royale.html.supportClasses.DataGroup;" and
> > replace with "import org.apache.royale.core.DataGroup;"
> >
> > (for me is clear that DataGroup is a Core piece, that will be used not as
> > Basic or Jewel implementation, but as a "core" piece used for the rest of
> > UI sets)
> >
> > I'll be looking at it right now
> >
> > Thanks for exposing it! :)
> >
> > Carlos
> >
> >
> >
> > 2018-05-17 8:49 GMT+02:00 Harbs :
> >
> >> Having trouble getting this email to “take”. Trying a paste link
> instead...
> >>
> >> It looks like it does have issues.
> >>
> >> I just pulled the 0.9.3 branch.
> >>
> >> I get a lot of these warnings when I compile the framework:
> >> https://paste.apache.org/Wy9t 
> >>
> >> I used it to compile my app, and I get runtime errors due to missing
> >> components. This seems to be due to HTML not subclassing Group.
> >>
> >> Here’s an example of elements which go AWAL:
> >> https://paste.apache.org/s9og 
> >>
> >> Everything below “ul" is missing.
> >>
> >> Harbs
> >>
> >>> On May 16, 2018, at 10:45 PM, Alex Harui  >> > wrote:
> >>>
> >>> I'm pretty sure the branches were cut before the changes in question.
> >> You can pull down the branches and build them to verify.  Or look at
> their
> >> history on GitHub.
> >>>
> >>> Om, did you see a date for when Maven SCM would be released?  The only
> >> response I got from the Maven folks was to build Maven SCM from sources.
> >> If it is going to be more than a week, I might actually try that.
> >>>
> >>> -Alex
> >>>
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

Re: 0.9.3 Release

[Carlos Rovira]

Hi,

just find the imports with problems, fix them and committed. If there's no
others this should fix the release.

If you see the commit, the changes are easy, and no more of some secs to do
for our users, in case they use this core classes.

Let's see what Jenkins reports in the following build


2018-05-17 10:16 GMT+02:00 Carlos Rovira :

> Hi Piotr,
>
> I think we are getting sufficient progress I the discussion thread to
> still think about a revert. I'm most for change things from this point,
> that should be the normal way from 0.9.2 to 1.0. We can as well hold a bit
> the release until we have cleared all this. As I said, if we revert, and
> release 0.9.3 with old code, blog examples will not work at all, and that
> will suppose lots of people in the internet trying us and failing.
>
> Think that:
>
> 1) There's no breaking changes at all about functionality
> 2) The change was only:
>  a) move things from Basic to Core
>  b) rename packages on some of that 2.a) things
>
>
> So the real problem now for me is 2.b) and that's the reason why jsonly
> build is failing, since we have things in framework with not examples
> referencing it, and since SWCs does not validate CSS beads, when used that
> CSS in final app that fails. I think that's for me a major problem, and
> will prefer to focus in find that code and fixing it.
>
> I'm trying to focus this morning on doing this, and hope to fix on that
> way jsonly
>
>
> 2018-05-17 10:08 GMT+02:00 Piotr Zarzycki :
>
>> It's not about the minor changes in his app in my opinion. In the result
>> of
>> the discussion it may end up that you will revert everything and solution
>> will be completely different. What will be the experience of the created
>> app on the user sight ?
>>
>> 2018-05-17 10:05 GMT+02:00 Carlos Rovira :
>>
>> > Hi Harbs,
>> >
>> > that was returned to the old way, actually we have the same than before
>> > refactor:
>> >
>> > import org.apache.royale.html.Group;
>> >
>> > public class NodeElementBase extends Group
>> >
>> > Maybe the problem is that we don't have any example of ButtonBar in
>> > examples? and thus I was not aware of that concrete component?
>> >
>> > I'll try to see that and if we need, I'll create and example now for
>> that.
>> >
>> > The change to solve this in your code base is really easy and direct:
>> >
>> > search all "import org.apache.royale.html.supportClasses.DataGroup;"
>> and
>> > replace with "import org.apache.royale.core.DataGroup;"
>> >
>> > (for me is clear that DataGroup is a Core piece, that will be used not
>> as
>> > Basic or Jewel implementation, but as a "core" piece used for the rest
>> of
>> > UI sets)
>> >
>> > I'll be looking at it right now
>> >
>> > Thanks for exposing it! :)
>> >
>> > Carlos
>> >
>> >
>> >
>> > 2018-05-17 8:49 GMT+02:00 Harbs :
>> >
>> > > Having trouble getting this email to “take”. Trying a paste link
>> > instead...
>> > >
>> > > It looks like it does have issues.
>> > >
>> > > I just pulled the 0.9.3 branch.
>> > >
>> > > I get a lot of these warnings when I compile the framework:
>> > > https://paste.apache.org/Wy9t 
>> > >
>> > > I used it to compile my app, and I get runtime errors due to missing
>> > > components. This seems to be due to HTML not subclassing Group.
>> > >
>> > > Here’s an example of elements which go AWAL:
>> > > https://paste.apache.org/s9og 
>> > >
>> > > Everything below “ul" is missing.
>> > >
>> > > Harbs
>> > >
>> > > > On May 16, 2018, at 10:45 PM, Alex Harui > > > > wrote:
>> > > >
>> > > > I'm pretty sure the branches were cut before the changes in
>> question.
>> > > You can pull down the branches and build them to verify.  Or look at
>> > their
>> > > history on GitHub.
>> > > >
>> > > > Om, did you see a date for when Maven SCM would be released?  The
>> only
>> > > response I got from the Maven folks was to build Maven SCM from
>> sources.
>> > > If it is going to be more than a week, I might actually try that.
>> > > >
>> > > > -Alex
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> > Carlos Rovira
>> > http://about.me/carlosrovira
>> >
>>
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>> Patreon: *https://www.patreon.com/piotrzarzycki
>> *
>>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>


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

Re: 0.9.3 Release

[Carlos Rovira]

Hi Piotr,

I think we are getting sufficient progress I the discussion thread to still
think about a revert. I'm most for change things from this point, that
should be the normal way from 0.9.2 to 1.0. We can as well hold a bit the
release until we have cleared all this. As I said, if we revert, and
release 0.9.3 with old code, blog examples will not work at all, and that
will suppose lots of people in the internet trying us and failing.

Think that:

1) There's no breaking changes at all about functionality
2) The change was only:
 a) move things from Basic to Core
 b) rename packages on some of that 2.a) things


So the real problem now for me is 2.b) and that's the reason why jsonly
build is failing, since we have things in framework with not examples
referencing it, and since SWCs does not validate CSS beads, when used that
CSS in final app that fails. I think that's for me a major problem, and
will prefer to focus in find that code and fixing it.

I'm trying to focus this morning on doing this, and hope to fix on that way
jsonly


2018-05-17 10:08 GMT+02:00 Piotr Zarzycki :

> It's not about the minor changes in his app in my opinion. In the result of
> the discussion it may end up that you will revert everything and solution
> will be completely different. What will be the experience of the created
> app on the user sight ?
>
> 2018-05-17 10:05 GMT+02:00 Carlos Rovira :
>
> > Hi Harbs,
> >
> > that was returned to the old way, actually we have the same than before
> > refactor:
> >
> > import org.apache.royale.html.Group;
> >
> > public class NodeElementBase extends Group
> >
> > Maybe the problem is that we don't have any example of ButtonBar in
> > examples? and thus I was not aware of that concrete component?
> >
> > I'll try to see that and if we need, I'll create and example now for
> that.
> >
> > The change to solve this in your code base is really easy and direct:
> >
> > search all "import org.apache.royale.html.supportClasses.DataGroup;" and
> > replace with "import org.apache.royale.core.DataGroup;"
> >
> > (for me is clear that DataGroup is a Core piece, that will be used not as
> > Basic or Jewel implementation, but as a "core" piece used for the rest of
> > UI sets)
> >
> > I'll be looking at it right now
> >
> > Thanks for exposing it! :)
> >
> > Carlos
> >
> >
> >
> > 2018-05-17 8:49 GMT+02:00 Harbs :
> >
> > > Having trouble getting this email to “take”. Trying a paste link
> > instead...
> > >
> > > It looks like it does have issues.
> > >
> > > I just pulled the 0.9.3 branch.
> > >
> > > I get a lot of these warnings when I compile the framework:
> > > https://paste.apache.org/Wy9t 
> > >
> > > I used it to compile my app, and I get runtime errors due to missing
> > > components. This seems to be due to HTML not subclassing Group.
> > >
> > > Here’s an example of elements which go AWAL:
> > > https://paste.apache.org/s9og 
> > >
> > > Everything below “ul" is missing.
> > >
> > > Harbs
> > >
> > > > On May 16, 2018, at 10:45 PM, Alex Harui  > > > wrote:
> > > >
> > > > I'm pretty sure the branches were cut before the changes in question.
> > > You can pull down the branches and build them to verify.  Or look at
> > their
> > > history on GitHub.
> > > >
> > > > Om, did you see a date for when Maven SCM would be released?  The
> only
> > > response I got from the Maven folks was to build Maven SCM from
> sources.
> > > If it is going to be more than a week, I might actually try that.
> > > >
> > > > -Alex
> > > >
> > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>



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