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]

ainless 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 can see the benefits. The benefits
> are
> > exposed now!, you don't have to try anything more to see that is a good
> > way. You only need to examine final code in JewelExample, or any other
> > example code that uses Jewel and not uses Basic (all blog examples, or
> > remote object example), and you'll see that is the proof that the way
> works
> > better. You didn't see nothing about things like less definitions or
> other
> > points that I put on the table. And you stick with a way of thinking
> that I
> > still don't see arguments that make me think that I should use link
> Basic,
> > and If you want me to link Basic, I understand that you want me to extend
> > things in Basic or if is not the case, why you want me to link Basic in
> > Jewel ?
> >
> >
> >>
> >>>
> >>>> 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.
> >>
> >> What problems do you envision that are stopping the 0.9.3 release? Can
> we
> >> get things working for the release and then take it from there?
> >>
> >
> > I think we are stopping the release because of this discussion, since all
> > is working right. The only problem is the change of classes to other
> > packages that will make users to take that into account. But 0.9.3 can be
> > made some weeks ago as jsonly was fixed right?
> >
> >
> >>
> >> I’m working on getting rid of all the class selectors which are bringing
> >> Basic pieces into Jewel. Please give me a chance to finish this work.
> >>
> >>
> > I think this can be done independent of the discussion about link Basic
> or
> > not. We should not mix things and keep the problems clearly
> differentiated
> >
> > Harbs,
> >
> > I want to propose a way that respect both ways. You can do your work on
> > refactoring class selectors while I continue my work on Jewel. But to do
> > this I need to create an intermediate library. I can do that with
> temporal
> > name "Foundation" and then put there the beads I'll need (as I needed).
> As
> > well I can return things from Core to Foundation and Basic (the same
> > temporal copy on both sides). This will make you and me try to proof our
> > concepts, and not only proof yours is the only one that is right. What do
> > you think?
> >
> > Thanks
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


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

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

[Harbs]

hared 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 can see the benefits. The benefits are
> exposed now!, you don't have to try anything more to see that is a good
> way. You only need to examine final code in JewelExample, or any other
> example code that uses Jewel and not uses Basic (all blog examples, or
> remote object example), and you'll see that is the proof that the way works
> better. You didn't see nothing about things like less definitions or other
> points that I put on the table. And you stick with a way of thinking that I
> still don't see arguments that make me think that I should use link Basic,
> and If you want me to link Basic, I understand that you want me to extend
> things in Basic or if is not the case, why you want me to link Basic in
> Jewel ?
> 
> 
>> 
>>> 
>>>> 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.
>> 
>> What problems do you envision that are stopping the 0.9.3 release? Can we
>> get things working for the release and then take it from there?
>> 
> 
> I think we are stopping the release because of this discussion, since all
> is working right. The only problem is the change of classes to other
> packages that will make users to take that into account. But 0.9.3 can be
> made some weeks ago as jsonly was fixed right?
> 
> 
>> 
>> I’m working on getting rid of all the class selectors which are bringing
>> Basic pieces into Jewel. Please give me a chance to finish this work.
>> 
>> 
> I think this can be done independent of the discussion about link Basic or
> not. We should not mix things and keep the problems clearly differentiated
> 
> Harbs,
> 
> I want to propose a way that respect both ways. You can do your work on
> refactoring class selectors while I continue my work on Jewel. But to do
> this I need to create an intermediate library. I can do that with temporal
> name "Foundation" and then put there the beads I'll need (as I needed). As
> well I can return things from Core to Foundation and Basic (the same
> temporal copy on both sides). This will make you and me try to proof our
> concepts, and not only proof yours is the only one that is right. What do
> you think?
> 
> Thanks
> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

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

[Carlos Rovira]

, 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 can see the benefits. The benefits are
exposed now!, you don't have to try anything more to see that is a good
way. You only need to examine final code in JewelExample, or any other
example code that uses Jewel and not uses Basic (all blog examples, or
remote object example), and you'll see that is the proof that the way works
better. You didn't see nothing about things like less definitions or other
points that I put on the table. And you stick with a way of thinking that I
still don't see arguments that make me think that I should use link Basic,
and If you want me to link Basic, I understand that you want me to extend
things in Basic or if is not the case, why you want me to link Basic in
Jewel ?


>
> >
> >> 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.
>
> What problems do you envision that are stopping the 0.9.3 release? Can we
> get things working for the release and then take it from there?
>

I think we are stopping the release because of this discussion, since all
is working right. The only problem is the change of classes to other
packages that will make users to take that into account. But 0.9.3 can be
made some weeks ago as jsonly was fixed right?


>
> I’m working on getting rid of all the class selectors which are bringing
> Basic pieces into Jewel. Please give me a chance to finish this work.
>
>
I think this can be done independent of the discussion about link Basic or
not. We should not mix things and keep the problems clearly differentiated

Harbs,

I want to propose a way that respect both ways. You can do your work on
refactoring class selectors while I continue my work on Jewel. But to do
this I need to create an intermediate library. I can do that with temporal
name "Foundation" and then put there the beads I'll need (as I needed). As
well I can return things from Core to Foundation and Basic (the same
temporal copy on both sides). This will make you and me try to proof our
concepts, and not only proof yours is the only one that is right. What do
you think?

Thanks



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

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

[Harbs]

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

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

What problems do you envision that are stopping the 0.9.3 release? Can we get 
things working for the release and then take it from there?

I’m working on getting rid of all the class selectors which are bringing Basic 
pieces into Jewel. Please give me a chance to finish this work.

Thanks,
Harbs

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]

ra" 
 wrote:

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

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

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]

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

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

[Harbs]

, 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
>>>>> 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/
&g

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

[Harbs]

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

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 <bigosma...@gmail.com>:

> 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 <carlosrov...@apache.org>
> 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 <aha...@adobe.com.invalid>:
> >
> > > 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" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org>
> > > 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 <harbs.li...@gmail.com>:
> > >
> > > > 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 <aha...@adobe.com.invalid>:

> 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" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org>
> 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 <harbs.li...@gmail.com>:
>
> > 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" 
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> 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 <harbs.li...@gmail.com>:

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

n/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
> > &g

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

[Carlos Rovira]

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

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

[Alex Harui]

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

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

[Carlos Rovira]

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 <harbs.li...@gmail.com>:
> > >
> > >> 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 <
> > carlosrov...@apache.org>
> > >> 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
> > >>> * Le

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

[Alex Harui]

yale/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 <harbs.li...@gmail.com>:
> >
> >> 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 <
> carlosrov...@apache.org>
> >> 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?
> >>>
>

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

[Carlos Rovira]

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

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]

/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 <harbs.li...@gmail.com>:
> 
>> 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 <carlosrov...@apache.org>
>> 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 <harbs.li...@gmail.com>:
>>> 
>>>> 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.
  

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]

(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 <harbs.li...@gmail.com>:
> 
>> 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 <carlosrov...@apache.org>
>> 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 <harbs.li...@gmail.com>:
>>> 
>>>> 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 dec

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]

ter 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 <carlosrov...@apache.org>
> 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 <harbs.li...@gmail.com>:
> >
> >> 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 <jus...@classsoftware.com>
> >> 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: 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]

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 <harbs.li...@gmail.com> 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 <harbs.li...@gmail.com>:
>>>>>> 
>>>>>>> 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 >>>>>> 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 <harbs.li...@gmail.com>
>> 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
>>>>>>>>> <mailto:carlosrov...@apache.org <mailto: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>
>>>>>>>> <https://www.patreon.com/piotrzarzycki <https://www.patreon.com/
>>>>>>> piotrzarzycki>>*
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> 
>>>>>> Piotr Zarzycki
>>>>>> 
>>>>>> Patreon: *https://www.patreon.com/piotrzarzycki
>>>>>> <https://www.patreon.com/piotrzarzycki>*
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> 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)

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

;
> 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 <harbs.li...@gmail.com>:
> >>>>
> >>>>> 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  >>>>> 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 <harbs.li...@gmail.com>
> 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
> >>>>>>> <mailto:carlosrov...@apache.org <mailto: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>
> >>>>>> <https://www.patreon.com/piotrzarzycki <https://www.patreon.com/
> >>>>> piotrzarzycki>>*
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Piotr Zarzycki
> >>>>
> >>>> Patreon: *https://www.patreon.com/piotrzarzycki
> >>>> <https://www.patreon.com/piotrzarzycki>*
> >>>
> >>
> >>
> >
> >
> > --
> > 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]

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]

>>>>>> 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 >>>> 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 <harbs.li...@gmail.com> 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
>>>>>>> <mailto:carlosrov...@apache.org <mailto: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>
>>>>>> <https://www.patreon.com/piotrzarzycki <https://www.patreon.com/
>>>>> piotrzarzycki>>*
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> 
>>>> Piotr Zarzycki
>>>> 
>>>> Patreon: *https://www.patreon.com/piotrzarzycki
>>>> <https://www.patreon.com/piotrzarzycki>*
>>> 
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

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 <harbs.li...@gmail.com>:

> 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 <harbs.li...@gmail.com> 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 <harbs.li...@gmail.com>:
> >>
> >>> 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  >>> 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 <harbs.li...@gmail.com> 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
> >>>>> <mailto:carlosrov...@apache.org <mailto: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>
> >>>> <https://www.patreon.com/piotrzarzycki <https://www.patreon.com/
> >>> piotrzarzycki>>*
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon: *https://www.patreon.com/piotrzarzycki
> >> <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]

bs <harbs.li...@gmail.com> 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
> >>>>> <mailto:carlosrov...@apache.org <mailto: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>
> >>>> <https://www.patreon.com/piotrzarzycki <https://www.patreon.com/
> >>> piotrzarzycki>>*
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon: *https://www.patreon.com/piotrzarzycki
> >> <https://www.patreon.com/piotrzarzycki>*
> >
>
>


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

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 <harbs.li...@gmail.com> 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 <harbs.li...@gmail.com>:
>> 
>>> 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 >> 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 <harbs.li...@gmail.com> 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
>>>>> <mailto:carlosrov...@apache.org <mailto: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>
>>>> <https://www.patreon.com/piotrzarzycki <https://www.patreon.com/
>>> piotrzarzycki>>*
>>> 
>>> 
>> 
>> 
>> -- 
>> 
>> Piotr Zarzycki
>> 
>> Patreon: *https://www.patreon.com/piotrzarzycki
>> <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 <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 <harbs.li...@gmail.com>:
> 
>> 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 > 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 <harbs.li...@gmail.com> 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
>>>> <mailto:carlosrov...@apache.org <mailto: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>
>>> <https://www.patreon.com/piotrzarzycki <https://www.patreon.com/
>> piotrzarzycki>>*
>> 
>> 
> 
> 
> -- 
> 
> Piotr Zarzycki
> 
> Patreon: *https://www.patreon.com/piotrzarzycki
> <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 <harbs.li...@gmail.com>:

> 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  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 <harbs.li...@gmail.com> 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
> >> <mailto:carlosrov...@apache.org <mailto: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>
> > <https://www.patreon.com/piotrzarzycki <https://www.patreon.com/
> piotrzarzycki>>*
>
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<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 <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 
> <mailto: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 <harbs.li...@gmail.com> 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
>> <mailto:carlosrov...@apache.org <mailto: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>
> <https://www.patreon.com/piotrzarzycki 
> <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 <carlosrov...@apache.org>:

> 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 <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 <harbs.li...@gmail.com> 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
>> <mailto: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
> 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 <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 <harbs.li...@gmail.com> 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
> <mailto: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
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 <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 <harbs.li...@gmail.com> 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
> <mailto: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>*

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 <harbs.li...@gmail.com> 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 
>> <mailto: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.
> 

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

Re: 0.9.3 Release

[Carlos Rovira]

2018-05-17 11:16 GMT+02:00 Harbs <harbs.li...@gmail.com>:

> 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 <carlosrov...@apache.org>
> 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 <harbs.li...@gmail.com>:
> >
> >> 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 <jus...@classsoftware.com>
> >> 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 <carlosrov...@apache.org> 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 <harbs.li...@gmail.com>:
> 
>> 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 <jus...@classsoftware.com>
>> 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 <piotrzarzyck...@gmail.com> 
> 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 <carlosrov...@apache.org>:
> 
>> 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 <carlosrov...@apache.org>:
>> 
>>> 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 <piotrzarzyck...@gmail.com>:
>>> 
>>>> 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 <carlosrov...@apache.org>:
>>>> 
>>>>> 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 <harbs.li...@gmail.com>:
>>>>> 
>>>>>> Having trouble getting this email to “take”. Trying a paste link
>>>>> instead.

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